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

[[e-mail]]

Hi Greg,

Thanks for your review and thoughtful comments.
Please see inline with [XM]>>>.

Original


From: GregMirsky <[e-mail]>
To: Tarek Saad <[e-mail]>;
Cc: [e-mail] <[e-mail]>;MPLS Working Chairs <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年08月09日 08:40
Subject: Re: [mpls] 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 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?
[XM]>>> For MPLS Path Segment Identifier defined in RFC 9545, the egress LSR needs to create a state, please refer to Figure 3, 4, 5, and 6 of draft-ietf-pce-sr-path-segment.




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?
[XM]>>> No, that's not the case. The egress LSR uses the PSID FEC sub-TLV to perform validation, before that, the egress LSR is aware of the context of the received PSID. The intention of the validation is to ensure that the ingress LSR and the egress LSR have the same understanding.




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?
[XM]>>> Please refer to draft-ietf-pce-sr-path-segment.

This step appears underdeveloped, which may cause interoperability issues between implementations.
[XM]>>> Note that draft-ietf-pce-sr-path-segment is not a normative reference. RFC 9545 and RFC 9256 provide the necessary context on the relationship between PSID and SR Policy.




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?
[XM]>>> As said above, the endpoint has a state of the PSID. It knows the mapping between the PSID and the headend.


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). 
[XM]>>> Good catch. After thinking about it, I believe the new sub-TLVs can also be carried in TLVs 16 and 21 of echo reply when the echo reply carries PSID. In this case, considering the PSID FEC validation is almost the same to what's specified in Section 4, I propose to add some clarification text to Section 4 stating that the PSID FEC validation also applies to TLVs 16 and 21 of echo reply, does that make sense?



Cheers,
Xiao Min


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