[mpls] Re: Working Group Last Call for draft-ietf-mpls-spring-lsp-ping-path-sid (was Re: Working Group Last Call on draft-xp-mpls-spring-lsp-ping-path-sid)

[Ketan Talaulikar <[e-mail]>]

Hi Greg/All,

SR Policy as defined by RFC9256 does not require instantiation of
state at the segment waypoints or the tailend (endpoint). Path Segment
(RFC9545) introduced an extension that introduced a state on the
tailend (endpoint) for the PSID. The expectation is that PSID is not
something that is generically and commonly used or applicable for all
SR Policies but for specific use-cases (some of them described in
RFC9545).

The PSID label belongs to the endpoint and is used in the SL by the
headend. The PCEP spec (draft-ietf-pce-sr-path-segment) covers how the
PSID is allocated/instantiated on the endpoint PCC, how it is learnt
by the PCE, and then how it is programmed on the headend PCC. BGP is a
little different in nature than PCEP. The BGP SR Policy SAFI
(draft-ietf-idr-sr-policy-path-segment) does the southbound from
controller to the headend while BGP-LS SR Policy
(draft-ietf-idr-bgp-ls-sr-policy-path-segment) does the northbound
from the headend to the controller. For bidirectional SR Policies,
these mechanisms can be used to signal the PSID from the tailend to
the headed.

I hope that clarifies. I don't see the disconnect, but it is possible
that I am missing something.

Thanks,
Ketan

On Fri, Aug 30, 2024 at 5:36 AM Greg Mirsky <[e-mail]> wrote:
>
> Dear All,
> I think that the discussion of the SPRING WG mailing list is quite relevant to the WG LC on draft-ietf-mpls-spring-lsp-ping-path-sid.
> In the Shepherd review of draft-ietf-spring-bfd Ketan Talaulikar expressed his view on the distribution of SR Policy state information:
>
> < major > SR Policy scale is generally expected to be higher than RSVP-TE
>
> tunnels since the state is only present on the headend.
>
>
> On the other hand, draft-ietf-mpls-spring-lsp-ping-path-sid depends on the SR Policy state being maintained on the endpoint of the respective SR Policy. As I understand it, draft-ietf-pce-sr-path-segment ensures that both the headend and endpoint have the same information about the SR Policy state and its components. But, for the case of BGP as the originator of the SR Policy (draft-ietf-idr-sr-policy-safi), there appears that the mechanism of distributing the SR Policy ensures that only the headend of the SR Policy receives the relevant information.
> Is there some inconsistency, disconnect between expected scope of SR Policy state distribution from the point of view of experts in MPLS and SPRING WG. Also, if indeed, only the headend of the SR Policy is required to maintain the state of the SR Policy, could the PCE mechanism be simplified? And furthermore, if the endpoint of the SR Policy doesn't maintain the SR Policy state, how can the LSP Ping validate consistency between the data plane and control/management plane view of the SR Policy?
>
> Regards,
> Greg
>
> On Wed, Aug 21, 2024 at 6:14 AM Tarek Saad <[e-mail]> wrote:
>>
>> Hi WG,
>>
>>
>>
>> This WG last call is now closed. Thanks to all who provided their responses. There was some support to progress the document. However, there were comments raised during this poll, and we expect the authors to work with the reviewers to address those comments before we can progress the document further.
>>
>>
>>
>> Regards,
>>
>> Tarek (for the MPLS WG chairs)
>>
>>
>>
>> From: Tarek Saad <[e-mail]>
>> Date: Tuesday, August 6, 2024 at 1:12 PM
>> To: [e-mail] <[e-mail]>
>> Cc: MPLS Working Chairs <[e-mail]>, [e-mail] <[e-mail]>
>> Subject: Working Group Last Call for draft-ietf-mpls-spring-lsp-ping-path-sid (was Re: Working Group Last Call on draft-xp-mpls-spring-lsp-ping-path-sid)
>>
>> Hi WG,
>>
>>
>>
>> I am correcting a mistake to reference to the WG adopted draft (as opposed to the individual draft for the same document). Sorry for the confusion.
>>
>>
>>
>> Regards,
>>
>> Tarek
>>
>>
>>
>> From: Tarek Saad <[e-mail]>
>> Date: Tuesday, August 6, 2024 at 9:53 AM
>> To: [e-mail] <[e-mail]>
>> Cc: MPLS Working Chairs <[e-mail]>, [e-mail] <[e-mail]>
>> Subject: Working Group Last Call on draft-xp-mpls-spring-lsp-ping-path-sid
>>
>> Dear WG,
>>
>>
>>
>> This email starts a two-week working group last call for draft-ietf-mpls-spring-lsp-ping-path-sid.
>>
>>
>>
>> Please indicate your support or concern for this draft. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version, and it is ready for publication in your opinion. As always, review comments and nits are most welcome.
>>
>>
>>
>> Please send your comments to the mpls wg mailing list ([e-mail])
>>
>> If necessary, comments may be sent unidirectional to the WG chairs.
>>
>>
>>
>> Note, currently there are no IPR disclosures against this document.
>>
>>
>>
>> This poll runs until August 20, 2024.
>>
>>
>>
>> Thank you,
>>
>> Tarek (for the MPLS WG co-chairs)
>>
>>
>>
>> _______________________________________________
>> mpls mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]