Re: [mpls] Rtgdir early review of draft-ietf-mpls-sr-epe-oam-08

[Shraddha Hegde <[e-mail]>]

Hi Matthew,

Thank you for careful review and comments.
Pls see inline for replies..

I have posted -09 version with updates.
Let me know any further comments.

Rgds
Shraddha


Juniper Business Use Only
-----Original Message-----
From: Matthew Bocci via Datatracker <[e-mail]>
Sent: Tuesday, August 8, 2023 7:29 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Rtgdir early review of draft-ietf-mpls-sr-epe-oam-08

[External Email. Be cautious of content]


Reviewer: Matthew Bocci
Review result: Has Nits

RtgDir Early review: draft-ietf-mpls-sr-epe-oam-08.txt

Hello

I have been selected to do a routing directorate “early” review of this draft. https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-foo-name/__;!!NEt6yMaO-gk!DHrhtn6R3nI56afrsFP8kYO_p0FvEFYRLjw5YylcakWYc2q5QCytHRyn7o9cVE0zOhb0wtzKi3uIZ-rn$

The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached.

As this document is in working group last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments.

For more information about the Routing Directorate, please see https://urldefense.com/v3/__https://wiki.ietf.org/en/group/rtg/RtgDir__;!!NEt6yMaO-gk!DHrhtn6R3nI56afrsFP8kYO_p0FvEFYRLjw5YylcakWYc2q5QCytHRyn7o9cVE0zOhb0wtzKix3GFrlE$

Document: draft-ietf-mpls-sr-epe-oam-08.txt
Reviewer: Matthew Bocci
Review Date: 8th August 2023
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.

Comments:

The draft is generally very readable - thanks! There are one or two paragraphs, particularly in the introduction where the definite article (the/a, etc) is missing or not used correctly. I have tried to capture some examples in my list of 'nits' below.

In general, I don't have an issue with the mechanism described in the draft.
However, it does rely on the head end of the SR Policy / SR-TE LSP knowing the types of the SIDs along the path. This is a challenge if the segment list is just specified as a raw sequence of MPLS labels, for example in a PCEP S-ERO.
Although the draft mentions in Section 2 that this is out of scope, I think it should be much more up-front about this limitation and provide an informational reference to mitigating mechanisms such as the use of the NIL FEC, as an example.

Other Comments:

1.  Introduction

   Egress Peer Engineering (EPE) as defined in [RFC9087] is an effective
   mechanism to select the egress peer link based on different criteria.
   The EPE-SIDs provide means to represent egress peer links.  Many
                                                  ^^^^^^^^^^
MB>                                    ...and nodes and sets of nodes
<SH> ok. Will fix it.

   network deployments have built their networks consisting of multiple
   Autonomous Systems either for ease of operations or as a result of
   network mergers and acquisitons.  The inter-AS links connecting any
   two Autonomous Systems could be traffic engineered using EPE-SIDs in
   this case as well.  It is important to be able to validate the
             ^^^^^^^
MB>      As well as what?
<SH> > Egress Peer Engineering (EPE) as defined in
 <xref target ='RFC9087'/> is
an effective mechanism to select the egress peer link based on different criteria.
In this scenario, egress peers may belong to a completely different administration.
The EPE-SIDs provide means to represent egress peer nodes, links set of links and set of nodes.

 Many network
deployments have built their networks consisting of multiple Autonomous
Systems, either for the ease of operations or as a result of network mergers and acquisitons.
The inter-AS links connecting any two Autonomous Systems could be traffic
engineered using EPE-SIDs in this case, where there is single ownership but different AS
numbers.

   control plane to forwarding plane synchronization for these SIDs so
   that any anomaly can be detected easily by the operator.

[...]

Introduction, second paragraph:
"When there is a multi-hop EBGP session between the ASBRs, PeerNode SID is
   advertised and traffic would be load-balanced between the interfaces
   connecting the two nodes. "

MB> That really depends on local policy. I suggest replacing "...would
MB> be
load-balanced" with "..MAY be load balanced"

[...]
<SH> ack

Section 2. Theory of operation. Second Paragraph.
"The procedures to operate EBGP sessions in a scenario with
   unnumbered interfaces is not very well defined in [RFC9086] and hence
   out of scope for this document."

MB> This is quite a subjective statement. Perhaps you could rephrase as:
"[RFC9086] does not define the detailed procedures to operate EBGP sessions in a scenario with
   unnumbered interfaces. Therefore, these scenarios are
   out of scope for this document."
<SH> ack

Nits:

- Introduction, Second paragraph is missing the definite article in some sentences. Please go through and double check the grammar.
<SH> Ack

- Section 4.1, last paragraph:
s/optional descriptors and use them /optional descriptors and using them

- Section 4.2. This refers to the Downstream Detailed Mapping TLV as "DDMT".
However, I believe RFC8029 abbreviates this to "DDMAP TLV", and indeed that is how I think it is more commonly referred to in the industry. I suggest replacing "DDMT" with "DDMAP TLV" throughout.
<SH> Ack

- Section 5.1. "Set the Best-return-code to 10, "Mapping for this FEC is not the
   given label at stack-depth if any below conditions fail:. The text in the
   draft is missing closing quotation marks.
<sH> ack