Ahmed, Thanks for including the examples and modifying where needed.
I have comments on a few of your comments, shown below with [CB]. Thanks, Chris On Sat, Oct 27, 2018 at 5:04 PM Ahmed Bashandy <[email protected]> wrote: > 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 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 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 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 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 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 > > ------------- [CB] I suggest the following text to clarify the ordering of administrative distance in section 2.5.1. o Dynamic SID assignment: o For all FEC types except for SR policy, the FEC types are ordered using the default administrative distance ordering defined by the implementation. o The Binding SID [RFC8402 <https://tools.ietf.org/html/rfc8402>] assigned using SR Policy always has a higher administrative distance than any other FEC type. -------------- > > ========= > 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 > ------ [CB] The new paragraph on page 8 addresses this well. ------ > > ======== > Example incoming label conflict for label=1010 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 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 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 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 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 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 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 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 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 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 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" > ----------- [CB] The ambiguity is with the placement of SR Algorithm in the ordering. In the first list, algorithm appears _before_ the routing instance and the topology. In the second list, algorithm appears _after_ the routing instance and the topology. ----------- > > ========= > Example incoming label conflict for label=1016 on node A > > FEC1) > ISIS prefix sid advertisement from node B for 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 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 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 > This mapping server advertisment generates 100 mappings, one of which > maps 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 > > ------- [CB] OK. Since example 6 already covers the case of using address family to break the tie, we can do not need to fix this example, and can omit it instead. ------- > > ========= > 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 > -------- [CB] The example above using label=1019 was an attempt to construct an example to exercise the "next-hop" as the tie-breaker. Since this example is not valid, I think the text needs an example that illustrates how "next-hop" should be used as a tie-breaker. Can you add such an example to the text? Similarly, the text needs an example of how "outgoing interface" should be used as a tie-breaker. -------- > ========= > 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 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 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. > > Node A will generally also install an ingress MPLS forwarding entry > corresponding to FEC1 for > incoming prefix=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). > ======== > > 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 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). > > > #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 > ---------- [CB] I added some text to the example to use the commonly understood case of recursive next-hop resolution for BGP VPN routes. Please use this modified example. Illustration of the effect of incoming label collision resolution on outgoing label programming on node A FEC1: o SR Policy advertisement from controller to node A o Endpoint address=192.0.2.80, color=100, SID-List=<S1, S2> o Binding-SID label=1023 FEC2: o SR Policy advertisement from controller to node A o Endpoint address=192.0.2.81, color=100, SID-List=<S3, S4> o 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. In this example, we assume that node A receives two BGP/VPN routes: R1 with VPN label=V1, BGP next-hop = 192.0.2.80 <http://192.0.2.80/32>, and color=100, R2 with VPN label=V2, BGP next-hop = 192.0.2.81 <http://192.0.2.80/32>, and color=100, We also assume that A has a BGP policy which matches on color=100 that allows that its usage as SLA steering information. In this case, node A will install a VPN route with label stack = <S1,S2,V1> (corresponding to FEC1). The rule described in section 2.6 means that node A MUST NOT install a VPN route with label stack = <S3,S4,V1> (corresponding to FEC2.) ---------- > > ======== > > 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 protected]> wrote: > >> 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. >> >> >> _______________________________________________ >> spring mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring >> >> > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
