Subject: Re: [mpls] Comments on draft-nainar-mpls-spring-lsp-ping-sr-generic-sid

From: Tarek Saad <[email-masked]>
Date: Mon, 18 Nov 2019 02:19:41 +0000

Hi authors,

Resending some comments from last time and adding one more:
Can you comment on what validation checks are possible with this approach in case there’s an incoming label collision for multiple SR FECs (as described in in draft-ietf-spring-segment-routing-mpls section 2.5)?

Regards,
Tarek

From: Tarek Saad <[email-masked]>
Date: Monday, July 22, 2019 at 9:17 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Comments on draft-nainar-mpls-spring-lsp-ping-sr-generic-sid

Hi authors,

I read through this draft and need some clarification.
      *  Else:

         +  Set the Best-return-code to 10 when the index derived from
            the label at Label-stack-depth is not advertised by LSP End
            Point.

The procedure above seems to hint that a transit node (e.g. for a traced node SID) will have to derive the SR index from the SRGL SID (as absolute label) so it can do further local validation? If my understanding is correct,

1.      How does the node know deterministically that the SRGL SID is for a remote prefix SID -- so it can do this derivation?

2.      I presume there is an assumption that R8’s SRGB is known to all transit SR nodes along the path so index can be derived? I’m not sure the condition will always be true -- e.g. what about inter-area case? Also, what about BGP prefix SIDs?

3.      What happens if R8 is non SR capable (e.g. runs LDP) and SRMS is advertising the prefix SID on its behalf – i.e R8 never advertises an SRGB?

As comparison, RFC8287 suggests to carry the (i.e. node/prefix of R8) in the prefix SID Target FEC Stack and any transit node can easily do local validation in the respective protocol DB (e.g. IGP or BGP).

Regards,
Tarek