Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13

From: <[email-masked]>
Date: Mon, 15 Oct 2018 16:12:01 +0000

Authors, Ahmed,

Could you progress on this document?

Thread is: https://mailarchive.ietf.org/arch/browse/spring/?q=subject%3Adraft-ietf-spring-segment-routing-mpls

Comments still to be addressed/resolved are the following:
https://mailarchive.ietf.org/arch/msg/spring/xx-t5v5IW2P_8rZykeJrvl9qDIE   (from myself since 2018-05-24)
https://mailarchive.ietf.org/arch/msg/spring/CRi96MnH4Bsu-tqlz5u26Man9xw (from Chris Bowers since 2018-06-08)
https://mailarchive.ietf.org/arch/msg/spring/yIwUvKddrcR-gxPQZSMjbynTX74 (from PK since 2018-06-09)
https://mailarchive.ietf.org/arch/msg/spring/5PHhLlMIxLgoFdoRC1Wqz6xCBnI  (from PK since 2018-06-09)

https://mailarchive.ietf.org/arch/msg/spring/w0ZmOAcDf_TUUWLkeFk_E6jzQm4 (from Ruediger 2018-06-13)
https://mailarchive.ietf.org/arch/msg/spring/gKA5sqkuk3SnOMAz4nSSCxFQHtQ (from Shraddha 2018-07-20 & +1 from Sasha)
https://mailarchive.ietf.org/arch/msg/spring/c7Pb8paTt1UibOw_O0yfPW4fgOk (from Sasha & Stéphane discussion 2018-08-06)

Authors, Ahmed,
Thank you for engaging the authors of those comments and update the draft.

Thank you,
--Bruno

From: DECRAENE Bruno IMT/OLN
Sent: Thursday, June 07, 2018 6:52 PM
To: SPRING WG List
Cc: [email-masked]
Subject: RE: WG Last Call for draft-ietf-spring-segment-routing-mpls-13

Hi all,

A quick update on the status of this WGLC:

- All the authors have responded about IPR (thank you!). Still missing replies from some contributors (Wim, Edward, Igor, Saku). I've sent them a reminder this Monday.
- Two people (Zafar, Adrian) have responded supporting publication.
- No opposition.
- Two persons have sent comments (Adrian, myself). Thanks Adrian.
- Authors have not replied to any comment so far.
- The WGLC period was scheduled to end tomorrow.

I wish we had more support, reviews, and authors' involvement to reply to reviews.

The WGLC is extended by a week. Please review the document and send your comments to the list, no later than *June 15*

Thank you,
--Bruno

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 24, 2018 7:14 PM
To: SPRING WG List
Cc: [email-masked]
Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-13

Hello Working Group,

This email starts a Working Group Last Call on draft-ietf-spring-segment-routing-mpls-13 [1] which is considered mature and ready for a final working group review.

Please read this document if you haven't read the most recent version yet, and send your comments to the list, no later than *June 08*.

As a reminder, this document had already passed a WGLC more than a year ago on version -06 [2], had been sent to the AD but then returned to the WG.

Since then, the document has significantly changed, so please read it again. In particular, it now includes the resolution in case of incoming label collision. Hence it killed draft-ietf-spring-conflict-resolution.

Both co-chairs co-author this document, hence:

- Shraddha has agreed to be the document shepherd. Thank you Shraddha.

- Martin, our AD, has agreed to evaluate the WG consensus.

Thank you,

Bruno, Rob

[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13

[2] https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ahmed Bashandy <[email-masked]>
Date: Mon, 22 Oct 2018 12:06:24 -0700

I uploaded version 15 to address the comments below since today is the 
deadline before the upcoming IETF

I will explaining how version 15 addresses each of the comments before 
the start of the IETF next week

Thanks a lot for all the help and the feedback

Ahmed

On 10/15/18 9:12 AM, [email-masked] wrote:
> Thread is: 
> https://mailarchive.ietf.org/arch/browse/spring/?q=subject%3Adraft-ietf-spring-segment-routing-mpls
>
> https://mailarchive.ietf.org/arch/msg/spring/gKA5sqkuk3SnOMAz4nSSCxFQHtQ 
> (from Shraddha 2018-07-20 & +1 from Sasha)
>
> https://mailarchive.ietf.org/arch/msg/spring/c7Pb8paTt1UibOw_O0yfPW4fgOk 
> (from Sasha & Stéphane discussion 2018-08-06)
>
> Authors, Ahmed,
>
> *From:*DECRAENE Bruno IMT/OLN
> *Sent:* Thursday, June 07, 2018 6:52 PM
> *To:* SPRING WG List
> *Cc:* [email-masked]
> *Subject:* RE: WG Last Call for draft-ietf-spring-segment-routing-mpls-13
>
> Hi all,
>
> - All the authors have responded about IPR (thank you!). Still missing 
> replies from some contributors (Wim, Edward, Igor, Saku). I’ve sent 
> them a reminder this Monday.
>
> I wish we had more support, reviews, and authors’ involvement to reply 
> to reviews.
>
> The WGLC is extended by a week. Please review the document and send 
> your comments to the list, no later than **June 15**
>
> Thank you,
>
> --Bruno
>
> *From:[email-masked] [mailto:[email-masked]]
> *Sent:* Thursday, May 24, 2018 7:14 PM
> *To:* SPRING WG List
> *Cc:* [email-masked]
> *Subject:* WG Last Call for draft-ietf-spring-segment-routing-mpls-13
>
> Hello Working Group,
> This email starts a Working Group Last Call on 
> draft-ietf-spring-segment-routing-mpls-13 [1] which is considered 
> mature and ready for a final working group review.
> Please read this document if you haven't read the most recent version 
> yet, and send your comments to the list, no later than *June 08*.
> As a reminder, this document had already passed a WGLC more than a 
> year ago on version -06 [2], had been sent to the AD but then returned 
> to the WG.
> Since then, the document has significantly changed, so please read it 
> again. In particular, it now includes the resolution in case of 
> incoming label collision. Hence it killed 
> draft-ietf-spring-conflict-resolution.
> [2] 
> https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y

---

From: Ahmed Bashandy <[email-masked]>
Date: Sat, 27 Oct 2018 14:32:49 -0700

I uploaded version 15 on Oct/23 to address comments.

Thanks a lot for the comments

See my reply "#Ahmed"

On 5/24/18 10:40 AM, [email-masked] wrote:
>
> Hi authors,
>
> I’ve reviewed the document.
>
> It looks good, thanks for your effort.
>
> Please find below some comments, nothing major.
>
> Thanks for considering them as part of the WG LC.
>
> Thanks,
>
> Regards,
>
> Bruno
>
> ---
>
> Somewhere in Abstract/1. Introduction/2. MPLS Instantiation of Segment 
> Routing
>
> MPLS Instantiation of Segment Routing is sometimes referred to with 
> two different names: MPLS-SR or SR-MPLS which seems sub-optimal.
>
> [I.D.-ietf-spring-segment-routing] uses the term SR-MPLS. May this 
> term should also be used at least once in this document.
>
> ---
>
> §2.2
>
> "using the SRGB of the node"
>
> Please expand SRGB on first used. (in -13, this term is expand on §2.3 
> which is after)
>
#Ahmed: Done
>
> ---
>
> §2.3
>
> OLD: Just like SRGB, the SRLB need not be a single
>
>    contiguous range of label, except the SRGB MUST only be used to
>
>    instantiate global SIDs into the MPLS forwarding plane.
>
> NEW:
>
> Just like SRGB, the SRLB need not be a single
>
>    contiguous range of label.
>
> (simplify the sentence. The rule is already stated before in this section)
>
#Ahmed: I used a more general (and IMO more precise) wording
>
> ---
>
> [SRLB]
>
> "Hence it is
>
>    specified the same way and follows the same rules SRGB is specified
>
>    above in this sub-section."
>
> Sentence is not crystal clear and could probably be rephrased.
>
> More importantly, the sentence is incorrect: the SRLB does not follow 
> the last SRGB rules ( "The list of label ranges MUST only be used to 
> instantiate global SIDs into the MPLS forwarding plane")
>
#Ahmed: I used a more general (and IMO more precise) wording
>
> ------
>
> §2.4
>
> "0 =< I < size."
>
> "size = Lh(1)- Ll(1) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1"
>
> Algorithm looks good to me. Yet starting the index at 0 for SID index, 
> and 1 for SRGB sub-blocks may be slightly misleading. "Lh(1)- Ll(1)" 
> seems only defined in this document so an option would be to start 
> with "Lh(0)- Ll(0)" (this would impact the algo: :s/j = 1/ j = 0)
>
> Up to you.
>
#Ahmed: I left it as it is :)
>
> ------
>
> §2.5
>
> OLD: MPLS Incoming Label MAP
>
> NEW: MPLS Incoming Label Map
>
#Ahmed: Corrected
>
> (as per https://tools.ietf.org/html/rfc3031#section-3.11 )
>
> --
>
> OLD: o  (Endpoint, Color) representing an SR policy [I.D. 
> filsfils-spring-segment-routing-policy]
>
> NEW: o  an SR policy [I.D.-ietf-spring-segment-routing]
>
> (Otherwise, this would likely require a _Normative_ reference to I.D. 
> filsfils-spring-segment-routing-policy which would significantly delay 
> the RFC publication of this document. While 
> [I.D.-ietf-spring-segment-routing is already in the RFC editor queue 
> and does define a SR policy. )
>
#Ahmed: This has become rfc8402. I overlooked this one and I will make 
it refer to rfc8402 in version 16
>
> --
>
> OLD:
>
>    o  (Prefix, Routing Instance, Topology, Algorithm), where a topology
>
>       is identified by a set of links with metrics. For the purpose of
>
>       incoming label collision resolution, the same numerical value
>
>       SHOULD be used on all routers to identify the same set of links
>
>       with metrics.
>
> (It's not crystal clear what "numerical value" refers to, given the 
> list (Prefix, Routing Instance, Topology, Algorithm))
>
> NEW1:
>
>    o  (Prefix, Routing Instance, Topology, Algorithm), where a topology
>
>       is identified by a set of links with metrics. For the purpose of
>
>       incoming label collision resolution, the same Topology numerical 
> value
>
>       SHOULD be used on all routers to identify the same set of links
>
>       with metrics.
>
#Ahmed: I used this wording (thanks)
>
> NEW2:
>
>    o  (Prefix, Routing Instance, Topology, Algorithm). A Topology
>
>       identifies a set of links with metrics. For the purpose of
>
>       incoming label collision resolution, the same Topology numerical 
> value
>
>       SHOULD be used on all routers to identify the same set of links
>
>       with metrics.
>
> -----
>
> §2.5.1
>
> "       o All addresses are represented in 128 bits as follows
>
>             . IPv6 address is encoded natively
>
>             . IPv4 address is encoded in the most significant bits and
>
>                the remaining bits are set to zero
>
>        o All prefixes are represented by 128.
>
>             . A prefix is encoded in the most significant bits and the
>
>                remaining bits are set to zero.
>
>             . The prefix length is encoded before the prefix"
>
> "All prefixes are represented by 128."
>
> 128 what? Could be bits, but this does not fit with the addition of 
> the prefix length.
>
> "The prefix length is encoded before the prefix"
>
> using a field of what size?
>
#Ahmed: I corrected this to be (128+8)
>
> Do we (really) need 2 different encodings for prefix and address? 
> Especially since the rest of the algorithm does not make the difference:
>
>    "o  Encode the remaining set of FECs as follows
>
>        o Prefix, Routing Instance, Topology, Algorithm: (Prefix Length,
>
>          Prefix, SR Algorithm, routing_instance_id, Topology)"
>
#Ahmed: It is just that conceptually an address and a prefix are 
different and they are usually handled quite differently by routing 
protocols
>
> ---
>
> §2.5.2. Redistribution between Routing Protocol Instances
>
> "   o  If the receiving instance's SRGB is the same as the SRGB of origin
>
>       instance, THEN
>
>        o the index is redistributed with the route
>
>    o  Else
>
>        o the index is not redistributed and if needed it is the duty of
>
>          the receiving instance to allocate a fresh index relative to
>
>          its own SRGB"
>
> With a strict interpretation of this rule, when one increases the size 
> of the SRGB, all indexes from redistributed prefixes will be withdrawn 
> because it's unlikely that we can guaranty that the change of both 
> SRGB be atomic.
>
> Could this be accommodated? e.g. by only using the SRBG below the 
> index ? i.e SRGB [0;index] or just the mapped label in both SRGB?
>
#Ahmed: I think this is a very fine corner case. But I am open to any 
suggestion
>
> ---
>
> §2.6
>
> OLD:
>
> In the general case, the ingress node may not have exactly have the
>
>    same data of the receiving node, so the result may be different.
>
> NEW:
>
> In the general case, the ingress node may not have exactly the
>
>    same data of the receiving node, so the result may be different.
>
#Ahmed: I used that wording
>
> ----
>
> §2.10
>
> OLD
>
>    This document covers the calculation of outgoing label for the top
>
>    label only. The case where outgoing label is not the top label and is
>
>    part of a stack of labels that instantiates a routing policy or a
>
>    traffic engineering tunnel is covered in other documents such as
>
> [I.D.filsfils-spring-segment-routing-policy].
>
> This may be understood as requiring a _normative_ reference for 
> [I.D.filsfils-spring-segment-routing-policy], which would 
> significantly delay the RFC publication of this document.
>
> Proposed NEW1:
>
>    This document covers the calculation of outgoing label for the top
>
>    label only. Other cases are out of scope of this document.
>
> Or NEW2:
>
>   This document covers the calculation of outgoing label for the top
>
>    label only. The case where outgoing label is not the top label and is
>
>    part of a stack of labels that instantiates a routing policy or a
>
>    traffic engineering tunnel is out of scope of this document.
>
#Ahmed: I changed the wording a little bit such that 
[I.D.filsfils-spring-segment-routing-policy] is an example
>
> -- 
>
> §2.10.1
>
> "   Suppose an MCC on a router "R0" determines that PUSH or CONTINUE
>
>    operation is to be applied to an incoming packet whose active SID is
>
>    the global SID "Si" ..."
>
>  My undertanding is that "whose" in "whose active SID" refers to the 
> the "incoming packet". This seems to imply that the incoming packet is 
> (already) labeled.
>
> - This does not match the example used in the following paregraph, 
> where the incoming packet is IP.
>
>  "An example of a method to determine the SID
>
>    "Si" for PUSH operation is the case where IS-IS [I-D.ietf-isis-
>
>    segment-routing-extensions] receives the prefix-SID "Si" sub-TLV
>
>    advertised with prefix "P/m" in TLV 135 and the destination address
>
>    of the incoming IPv4 packet is covered by the prefix "P/m"."
>
>  - Also, you can't simply perform a PUSH on a received label packet. 
> You first need to POP or SWAP the incoming label.
>
> May be proposed NEW:
>
>    Suppose an MCC on a router "R0" determines that a PUSH or CONTINUE
>
>    operation is to be applied to an incoming packet, related to the 
> global SID "Si" ...
>
#Ahmed: Modified the text as suggested
>
> -----
>
> §2.10.1
>
> OLD: If the neighbor "N" does not support SR or "I" does not satisfy
>
>       the inequality specified in Section 2.4 for the SRGB of the
>
>       neighbor "N"
>
> May be a more generic sentence:
>
> NEW   If the neighbor "N" does not support SR or advertises a SRGB 
> invalid or too small,
>
#Ahmed: Modified as suggested
>
>  -----
>
> §2.10.1
>
> OLD:
>
>        o If it is possible to send the packet towards the neighbor "N"
>
>           using standard MPLS forwarding behavior as specified in
>
>           {RFC3031] and [RFC3032], then forward the packet. The method
>
>           by which a router decides whether it is possible to send the
>
>           packet to "N" or not is beyond the scope of this document. For
>
>           example, the router "R0" can use the downstream label
>
>           determined by another MCC, such as LDP [RFC5036], to send the
>
>           packet.
>
> The fall back to LDP seems like a mandated behavior. If so, the 
> behavior seems under-specified. In particular "out of scope of this 
> document" does not seem like a valid argument.
>
#Ahmed: In general LDP is not mandated. The statement says use MPLS. How 
and what protocol is used to determine what to do with the incoming 
label(s) (if any) and what is (are) the outgoing label(s) is totally 
outside the scope of this document.
>
> Possible NEW:
>
> "       o If this neighbor "N" advertises a valid label for the same 
> FEC via another MCC (e.g. LDP [RFC5036]), then forward the packet to 
> N, using the label advertised by this MCC.
>
> ----
>
> 2.11.2. Forwarding Behavior Corresponding to CONTINUE Operation for 
> Local SIDs
>
>   "A local SID on a router "R0" corresponds to a local label such as an
>
>    IGP adj-SID. In such scenario, the outgoing label towards a next-hop
>
>    "N" is determined by the MCC running on the router "R0"and the
>
>    forwarding behavior for CONTINUE operation is identical to swap
>
>    operation [RFC3032] on an MPLS label"
>
> I'm not seeing a case where an IGP adj-SID would have "CONTINUE" as a 
> forwarding behavior.
>
> And the SR architecture requires a NEXT operation:
>
> "      When a node binds an Adj-SID to a local data-link L, the node MUST
>
>        install the following FIB entry:
>
>       Incoming Active Segment: V
>
>       Ingress Operation: NEXT
>
>       Egress Interface: L"
>
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#section-3.4
>
> A solution would be to simply remove "such as an IGP adj-SID"
>
#Ahmed: I agree and I removed adj-SID
>
> ---
>
> §3 IGP Segment examples
>
> This section, also useful, is quite long and not normative for this 
> STD track doc. An option may be to move it to appendix.
>
> Up to you.
>
#Ahmed: Agreed and moved to appendix
>
> ---
>
> §3.1
>
> "R2 is the next-hop along the shortest path towards R8. By applying
>
>    the steps in Section 2.8 the local label downloaded to R1's FIB
>
>    corresponding to the global SID index 8 is 1008 because the SRGB of
>
>    R2 is [1000,5000] as shown in Figure 2."
>
>  may be
>
> OLD:  local label downloaded to R1's FIB
>
> NEW:  local outgoing label downloaded to R1's FIB
>
>  (because I would assume that by default, label downloaded in the FIB 
> is probably the incomig label one)
>
#Ahmed Changed "local" to "outgoing"
>
>  --
>
> OLD: owned by the R8
>
> NEW1: OLD: owned by R8
>
> NEW2: OLD: owned by the node R8
>
#Ahmed: Done
>
> --
>
> "The packet arrives at router R2. Because the top label 1008
>
>    corresponds to the IGP SID "8", which is the prefix-SID attached to
>
>    the prefix 192.0.2.8/32 owned by the R8, then the instruction
>
>    associated with the SID is "forward the packet using all ECMP/UCMP
>
>    interfaces and all ECMP/UCMP next-hop(s) along the shortest path
>
>    towards R8". "
>
> IGP prefix-SID are typically forwarded along the ECMP shortest path. 
> I'm not sure where "UCMP" is coming from. Also "along the shortest 
> path" seems to be incompatible with UCMP.
>
#Ahmed: I changed the wording to "shortest/useable"
>
> --
>
> "Because R3
>
>    is the penultimate hop, R3 applies NEXT operation then sends the
>
>    packet to R8."
>
>    "penultimate hop" is a required but not sufficient reason. You are 
> assuming that R8 asked for PHP, but I'm not seeing this assumption 
> stated in the text.
>
#Ahmed:
I changed to wording to use  "assume"
>
> ---
>
> "The NEXT operation results in popping the outer label
>
>    and sending the packet as a pure IPv4 packet to R8. The
>
>    In conclusion, "
>
> OLD: The
>
> NEW:
>
#Ahmed: In many places, I refer to each operation using "the".
>
> ---
>
> §3.2 & §3.3 & §3.4 & §3.5
>
> " Using the
>
>    calculation techniques specified in Section 2.10 and 2.11 the
>
>    resulting label stack starting from the topmost label is <1002, 9001,
>
>    1008>."
>
> Actually section 2.10 only defines the calculation technique for the 
> top label:
>
>    "This document covers the calculation of outgoing label for the top
>
>    label only. The case where outgoing label is not the top label and is
>
>    part of a stack of labels that instantiates a routing policy or a
>
>    traffic engineering tunnel is covered in other documents such as
>
> [I.D.filsfils-spring-segment-routing-policy]."
>
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13#section-2.10
>
>    Hence this document does not define the behavior for this example 
> 2. You would need to either extend this doc to cover the push of a 
> stack of label/SID or remove these examples 2, 3, 4, 5
>
#Ahmed Done
>
> ----
>
> [RFC8174] to be added to normative references.
>
#Ahmed: Done

---

From: Ahmed Bashandy <[email-masked]>
Date: Sat, 27 Oct 2018 15:04:06 -0700

Thanks a lot for the examples.

Version 15 of the document incorporates all of the examples in the 
appendix (all examples have been moved to appendix), except the examples 
where
- Incoming label=1009
- Incoming label=1018
- Incoming label=1019
- Binding-SID label=1023

See my comments at "#Ahmed" under each of these 4 examples

I have a response for your comment right after the examples that use  
"Incoming label=1008" and "Incoming label=1015"

Ahmed

On 6/8/18 11:14 AM, Chris Bowers wrote:
> SPRING WG,
>
> I generally support publication of
> draft-ietf-spring-segment-routing-mpls. However, I think
> that the text in sections 2.5 and 2.6 (on incoming label collisions)
> needs some work before publication. This text was added to
> the draft a few months ago, and has not gotten much review
> from the WG as a whole. The review and proposed text below
> focuses on these sections.
>
> As I understand the current text of the draft, the general
> approach to resolving incoming label collisions seems
> well-reasoned and complete.  However, it is possible that
> my interpretation of these tie-breaking rules is
> not what the authors intended.
>
> I'd like to propose the examples below to be included
> in the draft to help clarify the tie-breaking rules
> for incoming label collisions described in section 2.5.
> I have highlighted several cases in these examples,
> where I think the rules in section 2.5 need
> to be clarified in order to unambiguously determine
> the winning FEC in an example.
>
> It may also be the case that the authors or other
> WG participants will disagree with the interpretation of the
> rules used to choose a winning FEC in some of these
> examples.  In that case, we should discuss
> what is the correct interpretation, and clarify the
> text in the draft to make the correct interpretation
> clear.
>
>
> Incoming label collision examples
> =========
>
> Node A
> OSPF default admin distance for implementation=50
> ISIS default admin distance for implementation=60
>
> =========
> Example incoming label conflict for label=1005 on node A
>
> FEC1)
> OSPF prefix sid advertisement from node B for 198.51.100.5/32 
> <http://198.51.100.5/32> with index=5
> OSPF SRGB on node A = [1000,1999]
> Incoming label=1005
>
> FEC2)
> ISIS prefix sid advertisement from node C for 203.0.113.105/32 
> <http://203.0.113.105/32> with index=5
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1005
>
> FEC1 and FEC2 both use dynamic SID assignment.  Since neither of
> the FEC types is SR Policy, we use the default admin distances of 50
> and 60 to break the tie.  So FEC1 wins.
>
> =========
> Example incoming label conflict for label=1006 on node A
>
> FEC1)
> OSPF prefix sid advertisement from node B for 198.51.100.6/32 
> <http://198.51.100.6/32> with index=6
> OSPF SRGB on node A = [1000,1999]
> Incoming label=1006
>
> FEC2)
> ISIS adjacency sid advertisement from node A with label=1006
> Incoming label=1006
> Node A allocates this adjacency SID dynamically,
> and it may differ across router reboots.
>
> FEC1 and FEC2 both use dynamic SID assignment.  Since neither of
> the FEC types is SR Policy, we use the default admin distances of 50
> and 60 to break the tie.  So FEC1 wins.
>
> =========
> Example incoming label conflict for label=1007 on node A
>
> FEC1)
> OSPF prefix sid advertisement from node B for 198.51.100.7/32 
> <http://198.51.100.7/32> with index=7
> OSPF SRGB on node A = [1000,1999]
> Incoming label=1007
>
> FEC2)
> ISIS adjacency sid advertisement from node A with label=1007
> Incoming label=1007
> Node A assigns this adjacency SID explicitly via configuration,
> so the adjacency SID survives router reboots.
>
> FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID
> assignment. So FEC2 wins.
>
> =========
> Example incoming label conflict for label=1008 on node A
>
> FEC1)
> OSPF prefix sid advertisement from node B for 198.51.100.8/32 
> <http://198.51.100.8/32> with index=8
> OSPF SRGB on node A = [1000,1999]
> Incoming label=1008
>
> FEC2)
> SR Policy advertisement from controller to node A
> Endpoint = 192.0.2.208, color = 100, SID-List = <S1, S2>
> Binding-SID label = 1008
>
> FEC1 and FEC2 both use dynamic SID assignment.
> Since one of the FEC types is SR Policy, default admin
> distance is not used to break the tie.
> /* The text in Section 2.5.1 needs to be clarified to specify
> whether SR Policy always loses or always wins in this case. */
#Ahmed:
Section 2.5.1 in page 9 clearly says
      The default FEC administrative distance order starting from the
      lowest value SHOULD be
and then lists the FECs
Hence the list specifies the default admin distance starting from the
"lowest"
The Binding SID appears in the 2nd sub-bullet of the second
bullet. Hence the binding SID of a policy receives the maximal default
admin distance. Hence FEC1 should win
I adapted this example so that it shows the the default admin distance
of a binding SID is always higher than the default admin distances of
other FECs

>
> =========
> Example incoming label conflict for label=1009 on node A
>
> FEC1)
> OSPF adjacency sid advertisement by node A with label=1009
> Incoming label=1009
> Node A assigns this adjacency SID explicitly via configuration,
> so the adjacency SID survives router reboots.
>
> FEC2)
> ISIS adjacency sid advertisement by node A with label=1009
> Incoming label=1009
> Node A assigns this adjacency SID explicitly via configuration,
> so the adjacency SID survives router reboots.
>
> FEC1 and FEC2 both use explicit SID assignment.  This kind of
> incoming label collision should never occur, since an
> implement of explicit SID assignment MUST guarantee
> collision freeness on the same router.
#Ahmed
The example is not clear. If the adjacency SIDs for ISIS and OSPF are
out of the same interface towards the same neighbor, then there is no
collision
If they are out of different interfaces and/or towards different
neighbors, then this is an example of a faulty
implementation. Implementation must not allow multiple MCCs on the
same box to assign the same local label to two different FECs

Although assigning the same label to more than one FEC is a problem from 
the MPLS point of view, in version 15,  I added a  paragraph in page 8 
to prohibit that for completeness
>
> ========
> Example incoming label conflict for label=1010 on node A
>
> FEC1)
> ISIS prefix sid advertisement from node B for 203.0.113.110/32 
> <http://203.0.113.110/32> with index=10
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1010
>
> FEC2)
> ISIS adjacency sid advertisement by node A with label=1010
> Incoming label=1010
> Node A allocates this adjacency SID dynamically,
> and it may differ across router reboots.
>
> FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
> are from the same MCC, they have the same default admin distance.
> So we compare FEC type code-point.  FEC1 has FEC type
> code-point=120, while FEC2 has FEC type code-point=130.
> Therefore, FEC1 wins.
>
> =========
> Example incoming label conflict for label=1011 on node A
>
> FEC1)
> ISIS prefix sid advertisement from node B for 203.0.113.111/32 
> <http://203.0.113.111/32> with index=11
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1011
>
> FEC2)
> ISIS prefix sid advertisement from node C for 2001:DB8:1000::11/128 
> with index=11
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1011
>
> FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
> are from the same MCC, they have the same default admin distance.
> So we compare FEC type code-point.  Both FECs have FEC type
> code-point=120. So we compare address family.  Since IPv4 is
> preferred over IPv6, FEC1 wins.
>
> =========
> Example incoming label conflict for label=1012 on node A
>
> FEC1)
> ISIS prefix sid advertisement from node B for 203.0.113.112/32 
> <http://203.0.113.112/32> with index=12
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1012
>
> FEC2)
> ISIS prefix sid advertisement from node C for 203.0.113.128/30 
> <http://203.0.113.128/30> with index=12
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1012
>
> FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
> are from the same MCC, they have the same default admin distance.
> So we compare FEC type code-point.  Both FECs have FEC type
> code-point=120. So we compare address family.  Both are IPv4 address
> family, so we compare prefix length.  FEC1 has prefix length=32,
> and FEC2 has prefix length=30, so FEC2 wins.
>
> =========
> Example incoming label conflict for label=1013 on node A
>
> FEC1)
> ISIS prefix sid advertisement from node B for 203.0.113.113/32 
> <http://203.0.113.113/32> with index=13
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1013
>
> FEC2)
> ISIS prefix sid advertisement from node C for 203.0.113.213/32 
> <http://203.0.113.213/32> with index=13
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1013
>
> FEC1 and FEC2 both use dynamic SID assignment. Since both FECs
> are from the same MCC, they have the same default admin distance.
> So we compare FEC type code-point.  Both FECs have FEC type
> code-point=120. So we compare address family.  Both are IPv4 address
> family, so we compare prefix length.  Prefix lengths are the same,
> so we compare prefix.  FEC1 has the lower prefix, so FEC1 wins.
>
> =========
> Example incoming label conflict for label=1014 on node A
>
> FEC1)
> ISIS prefix sid advertisement from node B for 203.0.113.114/32 
> <http://203.0.113.114/32> with index=14
> Routing Instance ID = 1000
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1014
>
> FEC2)
> ISIS prefix sid advertisement from node C for 203.0.113.114/32 
> <http://203.0.113.114/32> with index=14
> Routing Instance ID = 2000
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1014
>
> These two FECs match all the way through the prefix length and prefix.
> So Routing Instance ID breaks the tie, with FEC1 winning.
>
> =========
> Example incoming label conflict for label=1015 on node A
>
> FEC1)
> ISIS prefix sid advertisement from node B for 203.0.113.115/32 
> <http://203.0.113.115/32> with index=15
> Routing Instance ID = 1000
> ISIS Multi-topology ID = 50
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1015
>
> FEC2)
> ISIS prefix sid advertisement from node C for 203.0.113.115/32 
> <http://203.0.113.115/32> with index=15
> Routing Instance ID = 1000
> ISIS Multi-topology ID = 40
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1015
>
> These two FECs match all the way through the prefix length, prefix, and
> Routing Instance ID.  We compare ISIS Multi-topology ID, so FEC2 wins.
>
> /* There appears to be a typo in section 2.5.1, with two different
> orderings shown for a prefix-based FEC:
> Prefix, Routing Instance, Topology, Algorithm
> and
> (Prefix Length, Prefix, SR Algorithm, routing_instance_id, Topology)
> This needs to be corrected. */
#Ahmed:
This is not a mistake. This bullet illustrates how to encode a
prefix and hence it separates the prefix into  its two components:
"prefix length" and "prefix"
>
> =========
> Example incoming label conflict for label=1016 on node A
>
> FEC1)
> ISIS prefix sid advertisement from node B for 203.0.113.116/32 
> <http://203.0.113.116/32> with index=16
> Routing Instance ID = 1000
> ISIS Multi-topology ID = 50
> SR algorithm = 0
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1016
>
> FEC2)
> ISIS prefix sid advertisement from node C for 203.0.113.116/32 
> <http://203.0.113.116/32> with index=16
> Routing Instance ID = 1000
> ISIS Multi-topology ID = 50
> SR algorithm = 22
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1016
>
> These two FECs match all the way through the prefix length, prefix, and
> Routing Instance ID, and Multi-topology ID. We compare SR algorithm ID, so
> FEC1 wins.
>
> =========
> Example incoming label conflict for label=1017 on node A
>
> FEC1)
> ISIS prefix sid advertisement from node B for 203.0.113.117/32 
> <http://203.0.113.117/32> with index=17
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1017
>
> FEC2)
> ISIS mapping server advertisement (SID/Label Binding TLV) from node D:
> Range=100, Prefix = 203.0.113.1/32 <http://203.0.113.1/32>
> This mapping server advertisment generates 100 mappings, one of which
> maps 203.0.113.17/32 <http://203.0.113.17/32> to index=17.
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1017
>
> The fact that FEC1 comes from a normal prefix sid advertisement and
> FEC2 is generated from a mapping server advertisement is not
> used as a tie-breaking parameter. Both FECs use dynamic SID assignment,
> are from the same MCC, have the same FEC type code-point=120. Their prefix
> lengths are the same as well.  FEC2 wins based on lower numerical 
> prefix value,
> since 203.0.113.17 is less than 203.0.113.117.
>
> =========
> Example incoming label conflict for label=1018 on node A
>
> FEC1)
> ISIS IPv4 adjacency sid advertisement from node A with label=1018
> corresponding to next-hop interface address=192.0.2.100, outgoing 
> interface ID=5
> Incoming label=1018
> Node A allocates this adjacency SID dynamically,
> and it may differ across router reboots.
>
> FEC2)
> ISIS IPv6 adjacency sid advertisement from node A with label=1018
> corresponding to 2001:DB8:2000::100/128, outgoing interface ID=6.
> Incoming label=1018
> Node A allocates this adjacency SID dynamically,
> and it may differ across router reboots.
>
> Both FECs use dynamic SID assignment, are from the same MCC,
> and have the same FEC type code-point=130.  FEC1 wins
> because IPv4 address family is preferred over IPv6.

#Ahmed:
This is another example of a faulty implementation because the
implementation of ISIS must not allow allocating the same local label
to two different adj-SIDs on the same node A

>
> =========
> Example incoming label conflict for label=1019 on node A
>
> FEC1)
> ISIS IPv4 adjacency sid advertisement from node A with label=1019
> corresponding to next-hop interface address=192.0.2.220, outgoing 
> interface ID=7
> Incoming label=1019
> Node A allocates this adjacency SID dynamically,
> and it may differ across router reboots.
>
> FEC2)
> ISIS IPv4 adjacency sid advertisement from node A with label=1019
> corresponding to next-hop interface address=192.0.2.230, outgoing 
> interface ID=8
> Incoming label=1019
> Node A allocates this adjacency SID dynamically,
> and it may differ across router reboots.
>
> Both FECs use dynamic SID assignment, are from the same MCC,
> and have the same FEC type code-point=130. Both FECs have to
> same address family.  FEC1 wins based on having the lowest next-hop
> interface address.
>
> /* It is not clear how to construct an example that
> would result in using the outgoing interface ID as a tie-breaker.
> It would be useful to understand why this is and clarify
> it in the text. */
#Ahmed:
This is a third example of a faulty implementation because the
implementation of ISIS must not allow allocating the same local label
to two different adj-SIDs on the same box
> =========
> Example incoming label conflict for label=1020 on node A
>
> FEC1)
> SR Policy advertisement from controller to node A
> Endpoint address=2001:DB8:3000::100, color=100, SID-List=<S1, S2>
> Binding-SID label=1020
>
> FEC2)
> SR Policy advertisement from controller to node A
> Endpoint address=192.0.2.60, color=100, SID-List=<S3, S4>
> Binding-SID label=1020
>
> The FECs match through the tie-breaks up to and including
> having the same FEC type code-point=140.
> FEC2 wins based on IPv4 address family being preferred
> over IPv6.
>
> =========
> Example incoming label conflict for label=1021 on node A
>
> FEC1)
> SR Policy advertisement from controller to node A
> Endpoint address=192.0.2.70, color=100, SID-List=<S1, S2>
> Binding-SID label=1021
>
> FEC2)
> SR Policy advertisement from controller to node A
> Endpoint address=192.0.2.71, color=100, SID-List=<S3, S4>
> Binding-SID label=1021
>
> The FECs match through the tie-breaks up to and including
> having the same address family. FEC1 wins by having the
> lower numerical endpoint address value.
>
> =========
>
> I'd like to propose the examples below to be included
> in the draft to help clarify section 2.6
> (currently entitled "Outgoing Label Collision").
>
>
> Examples of the Effect Incoming Label Collision on Outgoing Label 
> Programming
> ====================================
>
> Example of effect of incoming label collision for label=1022
> on outgoing label programming on node A
>
> FEC1)
> ISIS prefix sid advertisement from node B for 203.0.113.122/32 
> <http://203.0.113.122/32> with index=22
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1022
>
> FEC2)
> ISIS prefix sid advertisement from node C for 203.0.113.222/32 
> <http://203.0.113.222/32> with index=22
> ISIS SRGB on node A = [1000,1999]
> Incoming label=1022
>
> FEC1 wins based on lowest numerical prefix value.  This means that node A
> installs a transit MPLS forwarding entry to SWAP incoming label=1022, 
> with outgoing label N,
> and use outgoing interace I. N is determined by the index associated 
> with FEC1 (index=22) and
> the SRGB advertised by the next-hop node on the shortest path to reach
> 203.0.113.122/32 <http://203.0.113.122/32>.
>
> Node A will generally also install an ingress MPLS forwarding entry 
> corresponding to FEC1 for
> incoming prefix=203.0.113.122/32 <http://203.0.113.122/32> pushing 
> outgoing label N, and using outgoing interace I.
>
> The rule in section 2.6 means that node A MUST NOT install an ingress 
> MPLS forwarding entry
> corresponding to FEC2 ( which would be for incoming 
> prefix=203.0.113.222/32 <http://203.0.113.222/32>).
> ========
>
> Example of effect of incoming label collision for label=1023
> on outgoing label programming on node A
>
> FEC1)
> SR Policy advertisement from controller to node A
> Endpoint address=192.0.2.80, color=100, SID-List=<S1, S2>
> Binding-SID label=1023
>
> FEC2)
> SR Policy advertisement from controller to node A
> Endpoint address=192.0.2.81, color=100, SID-List=<S3, S4>
> Binding-SID label=1023
>
> FEC1 wins by having the lower numerical endpoint address value. This 
> means that node A
> installs a transit MPLS forwarding entry to SWAP incoming label=1023, 
> with outgoing labels
> and outgoing interface determined by the SID-List for FEC1.
> Node A will generally also install an ingress MPLS forwarding entry 
> corresponding to FEC1 for
> incoming prefix=192.0.2.80/32 <http://192.0.2.80/32> pushing outgoing 
> labels and using the outgoing interface
> determined by the SID-List for FEC1.
>
> The rule in section 2.6 means that node A MUST NOT install an ingress 
> MPLS forwarding entry
> corresponding to FEC2 ( which would be for incoming 
> prefix=192.0.2.81/32 <http://192.0.2.81/32>).
#Ahmed
It seems like there is a misunderstanding here. A policy is identified 
by a color and an IP address. What gets installed in the FIB is the MPLS 
label representing the binding SID. A packet arriving with the top label 
equal to the binding SID gets forwarded into the policy. The endpoint 
and color are unique identifier of the policy on the box
The IP address is the address of an endpoint, NOT a prefix. So the 
instantiation or advertisement of a policy does not result in installing 
any prefixes in FIB
>
> ========
>
> General comment:
>
> section 2.6 title:
> existing:
> Outgoing Label Collision:
> proposed:
> Effect of Incoming Label Collision on Outgoing Label Programming :
> --------------------------------------
>
>
> Thanks,
> Chris
>
>
> On Thu, May 24, 2018 at 12:14 PM, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello Working Group,
>
>     Please read this document if you haven't read the most recent
>     version yet, and send your comments to the list, no later than
>     *June 08*.
>
>     year ago on version -06 [2], had been sent to the AD but then
>     returned to the WG.
>
>     Since then, the document has significantly changed, so please read
>     it again. In particular, it now includes the resolution in case of
>     - Shraddha has agreed to be the document shepherd.. Thank you
>     Shraddha.
>
>     [1]
>     https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13
>     <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13>
>
>     [2]
>     <https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y>
>
>     _______________________________________________
>     spring mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/spring
>     <https://www.ietf.org/mailman/listinfo/spring>
>
>

---

From: Ahmed Bashandy <[email-masked]>
Date: Sat, 27 Oct 2018 15:24:23 -0700

Thanks a for the comments

Version 15 of the draft addresses your comments. See my comments below 
"#Ahmed"

On 6/9/18 12:01 AM, Przemyslaw Krol wrote:
> Greetings,
>
> Few minor, cosmetic/editorial suggestions:
>
> 2.5. Incoming Label Collision
> [...]
> *(Endpoint, Color)* representing an SR policy [I.D. 
> (Color, Endpoint) is the ordering used by the policy draft. If the 
> decision is to correct it, there is few references in the draft
>
#Ahmed: It does not matter from the point of view of label collision
> 2.5.1. Tie-breaking Rules
> [...]
>        o The Color ID is encoded using *16 bits*
> *
> *
> should be 32 bits
> (https://tools.ietf.org/html/rfc5512#section-4.3.1 && 
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-00#section-2.1)
>
>
> 2.6. Outgoing Label Collision
> [...]
> In the general case, the ingress node may not have exactly *have* the 
> same data of the receiving node
#Ahmed
Corrected
>
> 2.7. PUSH, CONTINUE, and NEXT
> PUSH, NEXT, and CONTINUE are operations applied by the forwarding plan*e*.
> [...]
>
#Ahmed:
Corrected
> 2.8. MPLS Label downloaded to FIB corresponding to Global and Local SIDs
> [...]
> an IGP with SR extensions *[*I-D.ietf-isis-segment-routing-extensions, 
> I-D.ietf-ospf-segment-routing-extensions]
>
> ^^^ missing '[' or alternatively both references should be enclosed in 
> their own []
#Ahmed:
Corrected
>
>
> thanks,
> pk
>
> On Fri, Jun 8, 2018 at 11:14 AM Chris Bowers 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     SPRING WG,
>
>     OSPF prefix sid advertisement from node B for 198.51.100..8/32
>     ISIS prefix sid advertisement from node C for
>     2001:DB8:1000::11/128 with index=11
>     ISIS prefix sid advertisement from node C for 203.0.113..213/32
>     so we compare prefix.  FEC1 has the lower prefix, so FEC1 wins..
>
>     =========
>     ISIS prefix sid advertisement from node C for 203..0.113.116/32
>     installs a transit MPLS forwarding entry to SWAP incoming
>     label=1022, with outgoing label N,
>     and use outgoing interace I. N is determined by the index
>     associated with FEC1 (index=22) and
>     Node A will generally also install an ingress MPLS forwarding
>     entry corresponding to FEC1 for
>     The rule in section 2.6 means that node A MUST NOT install an
>     ingress MPLS forwarding entry
>     FEC1 wins by having the lower numerical endpoint address value.
>     This means that node A
>     installs a transit MPLS forwarding entry to SWAP incoming
>     label=1023, with outgoing labels
>     Node A will generally also install an ingress MPLS forwarding
>     entry corresponding to FEC1 for
>     incoming prefix=192.0.2.80/32 <http://192.0.2.80/32> pushing
>     outgoing labels and using the outgoing interface
>     The rule in section 2.6 means that node A MUST NOT install an
>     ingress MPLS forwarding entry
>     On Thu, May 24, 2018 at 12:14 PM, <[email-masked]
>         draft-ietf-spring-segment-routing-mpls-13 [1] which is
>         considered mature and ready for a final working group review.
>
>         As a reminder, this document had already passed a WGLC more
>         than a year ago on version -06 [2], had been sent to the AD
>         but then returned to the WG.
>
>         Since then, the document has significantly changed, so please
>         read it again. In particular, it now includes the resolution
>         in case of incoming label collision. Hence it killed
>         - Shraddha has agreed to be the document shepherd... Thank you
>         Shraddha.
>
> Przemyslaw "PK" Krol | 	 Strategic Network Engineer 	ing 
> [email-masked] <mailto:[email-masked]> 	
>

---

From: Ahmed Bashandy <[email-masked]>
Date: Sat, 27 Oct 2018 15:34:21 -0700

#Ahmed:
The setting of the P and "E" flags translate to just one of the 3
operations: "continue", "push", or  "next". So there is really no need to
cover this particular setting/clearing of flags since the
setting/clearing of protocol flags are strictly control layer 
functionalities

On 6/9/18 12:29 PM, Przemyslaw Krol wrote:
> Greetings,
>
> In terms of UHP, draft-ietf-isis-segment-routing-extensions-16 
> <https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-16#section-2.1.1> describes 
> 2 cases:
>  - P set, E unset
>  - P set, E set
>
> However it looks that draft-ietf-spring-segment-routing-15 
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#section-3.1.2> doesn't 
> make that distinction and doesn't seem to cover the latter case:
>
>    o  A remote node M MUST maintain the following FIB entry for any
>       learned Prefix-SID SID-R attached to IP prefix R:
>
>      Incoming Active Segment: SID-R
>      Ingress Operation:
>         If the next-hop of R is the originator of R
>         and instructed to remove the active segment: NEXT
> *        Else: CONTINUE*
>      Egress interface: the interface towards the next-hop along the
>                        path computed using the algorithm advertised with
>                        the SID toward prefix R.
>
>
> Would it make sense to also describe the 2nd option (E+P) given ISIS 
> draft brings this up as a use case?
>
> thanks,
> pk
>
>
>
> On Sat, Jun 9, 2018 at 12:01 AM Przemyslaw Krol <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Greetings,
>
>     In the general case, the ingress node may not have exactly
>     *have* the same data of the receiving node
>
>     an IGP with SR extensions
>     *[*I-D.ietf-isis-segment-routing-extensions,
>     ^^^ missing '[' or alternatively both references should be
>     enclosed in their own []
>
>
>     thanks,
>     pk
>
>         203.0.113..213/32 <http://203.0.113.213/32> with index=13
>         203..0.113.116/32 <http://203.0.113.116/32> with index=16
>         lengths are the same as well.  FEC2 wins based on lower
>         numerical prefix value,
>         corresponding to next-hop interface address=192.0.2.100,
>         outgoing interface ID=5
>         Incoming label=1018
>         corresponding to next-hop interface address=192.0.2.220,
>         outgoing interface ID=7
>         Incoming label=1019
>         corresponding to next-hop interface address=192.0.2.230,
>         outgoing interface ID=8
>         Incoming label=1019
>         Examples of the Effect Incoming Label Collision on Outgoing
>         Label Programming
>         incoming prefix=203.0.113.122/32 <http://203.0.113.122/32>
>         pushing outgoing label N, and using outgoing interace I.
>
>         FEC1 wins by having the lower numerical endpoint address
>         value. This means that node A
>             Please read this document if you haven't read the most
>             recent version yet, and send your comments to the list, no
>             later than *June 08*.
>
>             As a reminder, this document had already passed a WGLC
>             more than a year ago on version -06 [2], had been sent to
>             the AD but then returned to the WG.
>
>             Since then, the document has significantly changed, so
>             please read it again. In particular, it now includes the
>             resolution in case of incoming label collision. Hence it
>             killed draft-ietf-spring-conflict-resolution.
>
>             - Shraddha has agreed to be the document shepherd... Thank
>             you Shraddha.
>

---

From: <[email-masked]>
Date: Tue, 30 Oct 2018 10:54:18 +0000

Thanks Ahmed.
This addresses my comments.

--Bruno

From: Ahmed Bashandy [mailto:[email-masked]]
Sent: Saturday, October 27, 2018 11:33 PM
To: DECRAENE Bruno TGI/OLN; [email-masked]
Cc: SPRING WG List
Subject: Re: WG Last Call for draft-ietf-spring-segment-routing-mpls-13

See my reply "#Ahmed"

On 5/24/18 10:40 AM, [email-masked]<mailto:[email-masked]> wrote:
Hi authors,

I've reviewed the document.
It looks good, thanks for your effort.

Thanks,
Regards,
Bruno

---
Somewhere in Abstract/1. Introduction/2. MPLS Instantiation of Segment Routing

MPLS Instantiation of Segment Routing is sometimes referred to with two different names: MPLS-SR or SR-MPLS which seems sub-optimal.
[I.D.-ietf-spring-segment-routing] uses the term SR-MPLS. May this term should also be used at least once in this document.

---
§2.2
"using the SRGB of the node"
Please expand SRGB on first used. (in -13, this term is expand on §2.3 which is after)

#Ahmed: Done

---
§2.3

NEW:

---
[SRLB]
"Hence it is

Sentence is not crystal clear and could probably be rephrased.
More importantly, the sentence is incorrect: the SRLB does not follow the last SRGB rules ( "The list of label ranges MUST only be used to instantiate global SIDs into the MPLS forwarding plane")
#Ahmed: I used a more general (and IMO more precise) wording

------
§2.4

"0 =< I < size."

Algorithm looks good to me. Yet starting the index at 0 for SID index, and 1 for SRGB sub-blocks may be slightly misleading. "Lh(1)- Ll(1)" seems only defined in this document so an option would be to start with "Lh(0)- Ll(0)" (this would impact the algo: :s/j = 1/ j = 0)
Up to you.
#Ahmed: I left it as it is :)

------
§2.5

(as per https://tools.ietf.org/html/rfc3031#section-3.11 )
--
OLD: o  (Endpoint, Color) representing an SR policy [I.D. filsfils-spring-segment-routing-policy]
NEW: o  an SR policy [I.D.-ietf-spring-segment-routing]

(Otherwise, this would likely require a _Normative_ reference to I.D. filsfils-spring-segment-routing-policy which would significantly delay the RFC publication of this document. While [I.D.-ietf-spring-segment-routing is already in the RFC editor queue and does define a SR policy. )
#Ahmed: This has become rfc8402. I overlooked this one and I will make it refer to rfc8402 in version 16

--
OLD:

(It's not crystal clear what "numerical value" refers to, given the list (Prefix, Routing Instance, Topology, Algorithm))

NEW1:
      incoming label collision resolution, the same Topology numerical value

NEW2:
   o  (Prefix, Routing Instance, Topology, Algorithm). A Topology
      identifies a set of links with metrics. For the purpose of
      incoming label collision resolution, the same Topology numerical value
      SHOULD be used on all routers to identify the same set of links
      with metrics.

-----
§2.5.1

"All prefixes are represented by 128."
128 what? Could be bits, but this does not fit with the addition of the prefix length.

Do we (really) need 2 different encodings for prefix and address? Especially since the rest of the algorithm does not make the difference:
   "o  Encode the remaining set of FECs as follows

       o Prefix, Routing Instance, Topology, Algorithm: (Prefix Length,
         Prefix, SR Algorithm, routing_instance_id, Topology)"
#Ahmed: It is just that conceptually an address and a prefix are different and they are usually handled quite differently by routing protocols

---

   o  Else

With a strict interpretation of this rule, when one increases the size of the SRGB, all indexes from redistributed prefixes will be withdrawn because it's unlikely that we can guaranty that the change of both SRGB be atomic.
Could this be accommodated? e.g. by only using the SRBG below the index ? i.e SRGB [0;index] or just the mapped label in both SRGB?
#Ahmed: I think this is a very fine corner case. But I am open to any suggestion

---
§2.6
OLD:

NEW:

----
§2.10

OLD

This may be understood as requiring a _normative_ reference for [I.D.filsfils-spring-segment-routing-policy], which would significantly delay the RFC publication of this document.

Proposed NEW1:

Or NEW2:
#Ahmed: I changed the wording a little bit such that [I.D.filsfils-spring-segment-routing-policy] is an example
--
§2.10.1

 My undertanding is that "whose" in "whose active SID" refers to the the "incoming packet". This seems to imply that the incoming packet is (already) labeled.
- This does not match the example used in the following paregraph, where the incoming packet is IP.
 "An example of a method to determine the SID
   "Si" for PUSH operation is the case where IS-IS [I-D.ietf-isis-
   segment-routing-extensions] receives the prefix-SID "Si" sub-TLV
   advertised with prefix "P/m" in TLV 135 and the destination address
   of the incoming IPv4 packet is covered by the prefix "P/m"."
 - Also, you can't simply perform a PUSH on a received label packet. You first need to POP or SWAP the incoming label.

May be proposed NEW:
   Suppose an MCC on a router "R0" determines that a PUSH or CONTINUE
   operation is to be applied to an incoming packet, related to the global SID "Si" ...
#Ahmed: Modified the text as suggested

-----
§2.10.1

NEW   If the neighbor "N" does not support SR or advertises a SRGB invalid or too small,
#Ahmed: Modified as suggested

 -----
§2.10.1

OLD:

The fall back to LDP seems like a mandated behavior. If so, the behavior seems under-specified. In particular "out of scope of this document" does not seem like a valid argument.
#Ahmed: In general LDP is not mandated. The statement says use MPLS. How and what protocol is used to determine what to do with the incoming label(s) (if any) and what is (are) the outgoing label(s) is totally outside the scope of this document.

Possible NEW:
"       o If this neighbor "N" advertises a valid label for the same FEC via another MCC (e.g. LDP [RFC5036]), then forward the packet to N, using the label advertised by this MCC.

----
2.11.2. Forwarding Behavior Corresponding to CONTINUE Operation for Local SIDs

I'm not seeing a case where an IGP adj-SID would have "CONTINUE" as a forwarding behavior.
And the SR architecture requires a NEXT operation:
"      When a node binds an Adj-SID to a local data-link L, the node MUST
       install the following FIB entry:

---
§3 IGP Segment examples

This section, also useful, is quite long and not normative for this STD track doc. An option may be to move it to appendix.
Up to you.
#Ahmed: Agreed and moved to appendix

---
§3.1

 may be
OLD:  local label downloaded to R1's FIB
NEW:  local outgoing label downloaded to R1's FIB
 (because I would assume that by default, label downloaded in the FIB is probably the incomig label one)
#Ahmed Changed "local" to "outgoing"

IGP prefix-SID are typically forwarded along the ECMP shortest path. I'm not sure where "UCMP" is coming from. Also "along the shortest path" seems to be incompatible with UCMP.
#Ahmed: I changed the wording to "shortest/useable"

   "penultimate hop" is a required but not sufficient reason. You are assuming that R8 asked for PHP, but I'm not seeing this assumption stated in the text.
#Ahmed:
I changed to wording to use  "assume"

---

   In conclusion, "

OLD: The
NEW:

---

Actually section 2.10 only defines the calculation technique for the top label:

   Hence this document does not define the behavior for this example 2. You would need to either extend this doc to cover the push of a stack of label/SID or remove these examples 2, 3, 4, 5
#Ahmed Done

----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, May 24, 2018 7:14 PM
To: SPRING WG List
Cc: [email-masked]<mailto:[email-masked]>
Subject: WG Last Call for draft-ietf-spring-segment-routing-mpls-13

Hello Working Group,

Thank you,

Bruno, Rob

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Tue, 30 Oct 2018 11:04:58 +0000

Thanks Ahmed.

Next steps are :
- shepherd write up (Shraddha)
- 2 weeks to allow WG to comment on the changes, especially from Chris, PK, Ruediger, Sasha, Shraddha.
- WG chairs go ahead (delegated to Martin (AD) as both chairs co-author)

Thank you,
--Bruno

From: Ahmed Bashandy [mailto:[email-masked]]
Sent: Monday, October 22, 2018 9:06 PM
To: DECRAENE Bruno TGI/OLN; [email-masked]
Cc: SPRING WG List
Subject: Re: WG Last Call for draft-ietf-spring-segment-routing-mpls-13

I uploaded version 15 to address the comments below since today is the deadline before the upcoming IETF

I will explaining how version 15 addresses each of the comments before the start of the IETF next week

Ahmed

On 10/15/18 9:12 AM, [email-masked]<mailto:[email-masked]> wrote:
Authors, Ahmed,

Authors, Ahmed,

Thank you,
--Bruno

Hi all,

Thank you,
--Bruno

Hello Working Group,

Thank you,

Bruno, Rob

Thank you.

Thank you.