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

[Chris Bowers <[e-mail]>]

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 <[e-mail]>
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, <[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
>>
>>
>
>