Re: [RTG-DIR] RtgDir Early/Last Call Review of draft-ietf-mpls-egress-tlv-for-nil-fec-08

[Shraddha Hegde <[e-mail]>]

Hi Alexander,

Version -09 addresses your comments.
Thanks again for careful review of the draft.

Rgds
Shraddha



Juniper Business Use Only
From: Alexander Vainshtein <[e-mail]>
Sent: Thursday, December 7, 2023 8:00 PM
To: mpls <[e-mail]>; [e-mail]
Cc: [e-mail]; Stewart Bryant <[e-mail]>; Greg Mirsky <[e-mail]>
Subject: RtgDir Early/Last Call Review of draft-ietf-mpls-egress-tlv-for-nil-fec-08

[External Email. Be cautious of content]

Hello,

I have been selected to do a routing directorate “early” review of this draft: draft-ietf-mpls-egress-tlv-for-nil-fec-08<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-mpls-egress-tlv-for-nil-fec-08__;!!NEt6yMaO-gk!CBhe_dPPZyEX-To0sgWAF0zKSvvASnWlmP0rk1mhR-7ynMJLHu-aTdyncCLtcAHHWNHczEVpdmxBFAVifzxg618XSEg$>.

Actually, the request I have received on 22-Nov-23 has been for review of the -07 version, but at that moment this version has been already replaced by the -08 version.
In addition, this document has been adopted by the working group for more than 2 years but is not in the WG LC yet.
Therefore, my review is a mix of an “early” and Last Call. Specifically, my focus for the review was to determine whether the document is ready to be published.



Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive (if/when it happens) and strive to resolve them through discussion or by updating the draft.



For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir<https://urldefense.com/v3/__https:/wiki.ietf.org/en/group/rtg/RtgDir__;!!NEt6yMaO-gk!CBhe_dPPZyEX-To0sgWAF0zKSvvASnWlmP0rk1mhR-7ynMJLHu-aTdyncCLtcAHHWNHczEVpdmxBFAVifzxgK3lZxQE$>.

Document: draft-ietf-mpls-egress-tlv-for-nil-fec-08<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-mpls-egress-tlv-for-nil-fec-08__;!!NEt6yMaO-gk!CBhe_dPPZyEX-To0sgWAF0zKSvvASnWlmP0rk1mhR-7ynMJLHu-aTdyncCLtcAHHWNHczEVpdmxBFAVifzxg618XSEg$>

Reviewer: Alexander (”Sasha”) Vainshtein  ([e-mail]<mailto:[e-mail]>)

Review Date: 07-Nov-23

IETF LC End Date: N/A

Intended Status: Standards Track



Summary: I have some minor concerns about this document that I think should be resolved before publication.



Comments:

The draft is well written and easy to read. It addresses a gap in the existing specification of performing LSP Ping of LSPs for which the egress LER receives labeled packets with multiple Explicit Null labels at the top of the label stack.



As already mentioned, the original request was for review of the -07 version, but this version has been already replaced by the -08 one. The only difference between the -07 and -08 versions is the change in early allocation of the Type value for the Egress TLV defined in this draft. This change was necessary because the new TLV is OPTIONAL, while the original value was allocated from the range reserved for MANDATORY types.



I have looked up an early review of the -06 version by Stewart<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/review-ietf-mpls-egress-tlv-for-nil-fec-06-rtgdir-early-bryant-2023-06-15/__;!!NEt6yMaO-gk!CBhe_dPPZyEX-To0sgWAF0zKSvvASnWlmP0rk1mhR-7ynMJLHu-aTdyncCLtcAHHWNHczEVpdmxBFAVifzxgD-kJir0$>. I see that his comments about the Security Considerations section and about consistency in using NIL/Nil have been addressed.

Not being a native English speaker, I cannot say whether his suggestion about “little light polish of the English in places” has been adequately addressed.



I defer to the MPLS WG Chairs and Routing Ads to decide how Stewart’s suggestion to send this draft for review to an expert in MPLS OAM should be addressed.



Major Issues: None found



Minor Issues:  I think that it would be useful if the following were explicitly specified in the text about usage of Egress TLV defined in the draft

  1.  This TLV can only be used in LSP Ping requests generated by the head-end node of a SR policy for which verification is performed
  2.  If this TLV is included in the LSP Ping Request, it does not affect validation if the Target FEC Stack sub-TLV at FEC-stack-depth is different of Nil FEC
  3.  If the endpoint of a SR-TE Policy is 0 (this happens in the case of color-only policies), the prefix in the Egress TLV is defined as following:

     *   If the last SID in the policy is an Adj-SID, it represents the node at the remote end of the corresponding adjacency
     *   If the last SID in the policy is a Binding SID, it represents the last note of the path represented by the Binding SID.

(There is no need to clarify how the prefix in the Egress TLV is defined if the last SID in the policy is a Prefix SID😊).


Nits: I did not perform the nits check, and I have not found any nits myself.

I have privately presented my comments to the authors of the draft and received their clarifications. I would like to thank them , and, especially, Shraddha for cooperation and responsiveness.

Hopefully, these notes will be useful.

Regards,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.