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

Dear All,

I paused to arrange my concerns about the draft and put them in front of
you more clearly. Below is what it came to:

   - The purpose of Target FEC Stack TLV in LSP echo request, as I
   understand it, is to verify consistency between the data plane and the
   control plane view of the data plane. That is why the sender of an echo
   request with Target FEC Stack TLV includes a sub-TLV that, from the
   sender's perspective, sufficiently represents the control plane information
   associated with the verifiable label.
   - If the above is correct, I move to the next point. All sub-TLVs in the
   Target FEC Stack TLV must be validated. The validation process is
   sub-TLV-specific. This draft defines the validation process, using PCEP as
   an example, as follows:

*  Validate that the signaled headend, color, end-point,

originator ASN, originator address, and discriminator

defined in [I-D.ietf-pce-segment-routing-policy-cp]

and [I-D.ietf-pce-sr-path-segment], for the PSID,

matches with the corresponding fields in the received

SR Candidate Path's PSID sub-TLV.

Now, my question: What is meant as validation of Headend?

   - The reason for my question above is that I cannot find that the
   identity of the Headend is included in PCEP constructs defined for the
   configuration of an SR Policy. Am I missing something in PCE-related
   specifications, or must they be enhanced to convey the identity of the SR
   Policy's Headend?
   - There's a possible way to use information already available in the
   IP-encapsulated echo request message and source IP address. Personally, I
   would consider such a check a security measure rather than validation, but
   how would validation work if no IP/UDP encapsulation of the echo request is
   used?

I hope that I made my concern more evident now. I welcome your comments and
questions.


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]
>