Early Review of draft-ietf-mpls-egress-tlv-for-nil-fec-08
review-ietf-mpls-egress-tlv-for-nil-fec-08-rtgdir-early-vainshtein-2023-12-11-00

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://datatracker.ietf.org/doc/html/draft-ietf-mpls-egress-tlv-for-nil-fec-08>.

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.

Document:
draft-ietf-mpls-egress-tlv-for-nil-fec-08<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-egress-tlv-for-nil-fec-08>

Reviewer: Alexander (”Sasha”) Vainshtein 
(Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>)

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://datatracker.ietf.org/doc/review-ietf-mpls-egress-tlv-for-nil-fec-06-rtgdir-early-bryant-2023-06-15/>.
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.