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

[Ahmed Bashandy <[e-mail]>]

#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 <[e-mail] 
> <mailto:[e-mail]>> 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
>
>     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
>
>     2.7. PUSH, CONTINUE, and NEXT
>     PUSH, NEXT, and CONTINUE are operations applied by the forwarding
>     plan*e*.
>     [...]
>
>     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 []
>
>
>     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]> 	
>
>
>
> -- 
> Przemyslaw "PK" Krol | 	 Strategic Network Engineer 	ing 
> |[e-mail] <mailto:[e-mail]> 	
>