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

[Przemyslaw Krol <[e-mail]>]

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]