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

Thank you for the continued discussion.
Please see inline.

Original


From: GregMirsky <[e-mail]>
To: 肖敏10093570;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年08月14日 00:00
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 Xiao Min,I've reviewed the new version. My conclusions of the discussion and updates:
I believe that a protocol specification (or enhancement of a protocol) must enable an implementor to develop operational and interoperable product. I don't see that the current version of the draft reaches to that level in many instances that I pointed out in my review. 
[XM]>>> It seems to me that your major concern is that unless the referenced control protocol extensions for path segment, such as PCEP and BGP extensions, are all published, this document can't be progressed. I've argued that's not necessary and explained the reason. RFCs 9545 and 9256 have provided all the information needed to encode the new sub-TLVs defined in this document.


I find that the update regarding the applicability of SR Policy's PSID, SR Candidate Path's PSID, and SR Segment List's PSID sub-TLVs:




When a sub-TLV defined in this document is carried in Reverse-Path Target FEC Stack TLV (Type 16) or Reply Path TLV (Type 21), it MUST be sent by an endpoint in an echo reply. The headend MUST perform validity checks as described above without setting the return code. If any of the validations fail, then the headend MUST drop the echo reply and SHOULD log and/or report an error.


introduces a new issue. I believe that RFC 7110 defines Return Path TLV to be used by the sender of an MPLS LSP echo request, not by the sender of echo reply as suggested in the new text.
[XM]>>> In Section 5.3 of RFC 7110, it says "When sending the echo reply, a Reply Path TLV that identifies the return path MUST be carried".

In summary, my concerns are not addressed and new issues introduced by the latest update. I don't support progressing the draft in its current form.
[XM]>>> Before progressing this document, we could wait for the publications of documents describing all kinds of control protocol extensions for path segment. But I don't see much value for that wait.

Cheers,
Xiao Min

Regards,
Greg




On Mon, Aug 12, 2024 at 8:27 PM <[e-mail]> wrote:


Hi Greg,

I've posted a new version of this draft, attempting to address your comments. Link as below.
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-spring-lsp-ping-path-sid-02
Please see inline with [XM-2]>>>.

Original

From: GregMirsky <[e-mail]>
To: 肖敏10093570;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年08月13日 06:18
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 Xiao Min,thank you for your response. Please find my follow-up notes below tagged GIM>>. 

Regards,
Greg




On Mon, Aug 12, 2024 at 2:21 AM <[e-mail]> wrote:


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.











GIM>> Thank you for clarifying the case when PSID is distributed using PCEP. What is the case with the BGP SR Policy?
[XM-2]>>> Please refer to draft-ietf-idr-sr-policy-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.











GIM>> That is not how the validation of the new sub-TLV is described in Section 4. If the SR Policy's, SR Candidate Path's, and SR Segment List's PSIDs are all unique, then the egress must verify that the received PSID label and the new sub-TLV are in sync with the view in the egress' control plane.
[XM-2]>>> Sorry but I don't catch your point. It seems to me Section 4 describes the needed PSID FEC validation procedures.









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.











GIM>> I don't think that is how the document can be published. The document must clearly describe the source of information used to validate new sub-TLV.
[XM-2]>>> I believe this document has done its job by referencing the source of information.









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.











GIM>> If that is the case, please map fields in this sub-TLV to RFC 9545 and 9256. Otherwise, make draft-ietf-pce-sr-path-segment Normative (as well as all documents referenced in Section 4 as essential to the validation processing) and map these fields to IEs defined in draft-ietf-pce-sr-path-segment.
[XM-2]>>> IMHO it's appropriate to have RFC 9545 and RFC 9256 as normative references and have other specific control protocol extensions as informative references, because the specific encodings of control protocols won't affect this document.











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.











GIM>> AFAICS, draft-ietf-pce-segment-routing-policy-cp does not identify Headend but only Endpoint. Similarly, SR Policy defined in BGP doesn't identify the Headend. (Note that I-D.ietf-idr-segment-routing-te-policy is outdated and the draft has been replaced).
[XM-2]>>> Please refer to draft-ietf-pce-sr-path-segment and draft-ietf-idr-sr-policy-path-segment.











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?











GIM>> I believe the WG must discuss this because it could impact TLVs 16 and 21. 
[XM-2]>>> I checked draft-ietf-mpls-sr-epe-oam which is in RFC editor's queue, and I didn't find any text clarifying how to apply the new sub-TLVs to TLVs 16 and 21. However, I believe it's helpful to the reader/implementer if some clarification text can be added, so a new paragraph was added to the end of Section 4 of this document.

Best Regards,
Xiao Min










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]