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

[Przemyslaw Krol <[e-mail]>]

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]> 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]>
> 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
>> <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 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
>> <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 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. */
>>
>> =========
>> 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
>> <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 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.
>>
>> =========
>> 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 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).
>>
>>
>> ========
>>
>> 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]
>> <[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]
>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>>>
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>>
>
>
> --
> Przemyslaw "PK" Krol |  Strategic Network Engineer ing | [e-mail]
>


-- 
Przemyslaw "PK" Krol |  Strategic Network Engineer ing | [e-mail]