Early Review of draft-ietf-mpls-sr-epe-oam-08
review-ietf-mpls-sr-epe-oam-08-rtgdir-early-bocci-2023-08-08-00

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://datatracker.ietf.org/doc/draft-foo-name/

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://wiki.ietf.org/en/group/rtg/RtgDir

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

   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?

   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 be
load-balanced" with "..MAY be load balanced"

[...]

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."

Nits:

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

- 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.

- 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.