[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)

[Greg Mirsky <[e-mail]>]

Hi Tarek,

I read the current version of the draft, and I have a number of questions
for the authors and the WG. Please kindly consider my notes below as WG LC
comments:

   - LSP Ping is intended to verify consistency between the data and
   control planes at the destination node. Unlike IP/MPLS, SR-MPLS doesn't
   create a state related to an SR Policy on the egress LSR. If so, what
   problem can be solved using the extensions proposed in this draft to the
   Target FEC Stack TLV?
   - From reading Section 4, it appears that the context of PSID is derived
   from the sub-TLV's. Does that mean the same PSID value may be used as SR
   Policy's PSID, Candidate Path's PSID, and Segment List's PSID? If that is
   not the case, should the egress LSR be aware of the context of the received
   PSID without the assistance of the PSID FEC sub-TLV?
   - SR Policy's PSID sub-TLV validation is described as follows:

+  Validate that the signaled or provisioned headend, color

and end-point for the PSID, matches with the

corresponding fields in the received SR Policy's PSID

sub-TLV.

   -
      - Can you give an example of signaled SR Policy PSID's Headend,
      Color, and Endpoint values? Which document defines such a signaling
      mechanism?
      - This step appears underdeveloped, which may cause interoperability
      issues between implementations.
   - Can you clarify how the endpoint of the SR Policy validates the
   Headend if the value of the Protocol-Origin field is either PCE or BGP SR
   Policy?
   - The new sub-TLVs are attributed to the "Sub-TLVs for TLV Types 1, 16,
   and 21" registry in the IANA Consideration section. However, the document
   specifies using new sub-TLVs only for TLV Type 1 (Target FEC Stack). It
   appears that the new sub-TLVs are left underspecified for TLVs 16
   (Reverse-path Target FEC Stack) and 21 (Reply Path).



Although LSP Ping is developed by the MPLS WG, the proposed new
enhancements are clearly related to SR-MPLS. I cannot recall this proposal
being vetted by the SPRING WG. It seems that in the spirit of cooperation of
the Routing Area, comments from the experts in the SPRING WG would be
welcomed.


Regards,

Greg

On Tue, Aug 6, 2024 at 10:13 AM Tarek Saad <[e-mail]> wrote:

> 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
> <https://datatracker.ietf.org/doc/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
> <https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-xp-mpls-spring-lsp-ping-path-sid>
> 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]
>