Re: [RTG-DIR] Rtgdir last call review of draft-ietf-mpls-sr-epe-oam-12

["Pengshuping (Peng Shuping)" <[e-mail]>]

Hi Shraddha, 

It is great that you find them useful. Your changes are good to me. 

Cheers! 

Best Regards, 
Shuping 


-----Original Message-----
From: Shraddha Hegde 
Sent: Wednesday, March 20, 2024 9:32 AM
To: Pengshuping (Peng Shuping) ; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: Rtgdir last call review of draft-ietf-mpls-sr-epe-oam-12

Hi Shuping,


Thank you for careful review and comments.
Pls see inline for replies.
Will post -13 with changes.


Rgds
Shraddha


Juniper Business Use Only
-----Original Message-----
From: Shuping Peng via Datatracker <[e-mail]>
Sent: Tuesday, February 6, 2024 1:25 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Rtgdir last call review of draft-ietf-mpls-sr-epe-oam-12

[External Email. Be cautious of content]


Reviewer: Shuping Peng
Review result: Has Nits

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see ​https://urldefense.com/v3/__http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir__;!!NEt6yMaO-gk!HEMlP6f8j3Xn-tyYxx7H4Rf1LFHtbNotumM2dgWsmn4xJeI1MT0oV6L1xPUWSCSyQ9WWpPqN71X2ARY9$

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, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-mpls-sr-epe-oam
Reviewer: Shuping Peng
Review Date: 2024-2-6
IETF LC End Date: 2024-2-14
Intended Status: Standards

Summary:
This document is basically ready for publication but has nits that should be considered prior to publication.

Major Issues:
 "No major issues found."

Minor Issues:
1. 4.1, the following sentence has shown twice but with the same issue to be clarified. "Link Local IPV6 addresses are for further study." This "Link Local
IPv6 addresses" will not be further studied in this draft, right? Shall we make this more clear?
<SH> Yes. Updated that link local address is not in the scope of this document

2. Section 5.1
"4a. Segment Routing IGP-Prefix, IGP-Adjacency SID and EPE-SID Validation :"
What is "4a." in this sentence?
<SH> Removed 4a and updated the section beginning as below "The below section augments the section 7.4 point 4a of RFC 8287"

3. Section 5.1
The algorithm procedures could be better formatted throughout this section.
<SH> ok

Nits:
1. Section 1
s/peer nodes, links set of links/peer nodes, links, set of links

2. Section 4
s/IPV4/IPv4
s/IPV6/IPv6

3. Section 4.1
s/length will be 24./length will be 24 octets.
s/length will be 48./length will be 48 octets.

s/Length excludes the length of Type and Length field  /Length excludes the length of Type and Length fields

4. Section 4.1, 4.2, 4.3
s/4 octet unsigned integer of the advertising node representing the BGP
   Identifier as defined in [RFC4271] and [RFC6286].
 /4 octet unsigned integer representing the BGP Identifier of the advertising  node as defined in [RFC4271] and [RFC6286].

5. Section 4.2
s/Length : 16/Length : 16 octets

6. Section 4.3
s/inside the Confederation.[RFC5065]./inside the Confederation [RFC5065].

7. Section 5
s/Peer Node SID/PeerNode SID

s/9 + no.of elements/9 + No. of elements

8. Section 5.1, the following sentence has shown twice but with the same issue s/"Mapping for this FEC is not the given label at stack-depth if any below conditions fail: /"Mapping for this FEC is not the given label at stack-depth"
if any below conditions fail:
<SH> The validation criteria is for PeerNode SID and PeerAdj SID is same if remote interface-id is zero.
If it's not set to zero then PeerAdj SID has additional validation. It was done this way based on WG review.
People want to have flexibility of not sending remote interface id.

9. Section 6
s/IANA is requested to allocated/IANA is requested to allocate

10. Section 7
s/When EPE-SIDs which are created for egress TE links where the neighbor AS is an independent entity, /When EPE-SIDs are created for egress TE links where the neighbor AS is an independent entity,


<SH> closed all nits. Thanks for pointing out.