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

[Ahmed Bashandy <[e-mail]>]

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. 
> filsfils-spring-segment-routing-policy]
>
> (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)
#Ahmed: Modified as suggested
>
>
> 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 
> <[e-mail] <mailto:[e-mail]>> 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. */
>
>     =========
>     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.
>
>     ========
>     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. */
>
>     =========
>     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.
>
>     =========
>     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. */
>     =========
>     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>).
>
>     ========
>
>     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, <[e-mail]
>     <mailto:[e-mail]>> 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
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/spring
>
>
>     _______________________________________________
>     spring mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/spring
>
>
>
> -- 
> Przemyslaw "PK" Krol | 	 Strategic Network Engineer 	ing 
> |[e-mail] <mailto:[e-mail]> 	
>