[RTG-DIR] Rtgdir early review of draft-ietf-idr-entropy-label-13

[Mach Chen via Datatracker <[e-mail]>]

Reviewer: Mach Chen
Review result: Has Nits

Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-idr-entropy-label-13/

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-idr-entropy-label-13
Reviewer: Mach Chen
Review Date: 10 Dec 2023
Intended Status: Standards Track

Summary
I think that this document is basically ready for publication, but there are a
few points below that I would like to discuss for clarification. I also found a
few nits that should be fixed at some point before publication.

Comments and Questions
In Section 1
It says:
"An NHC carried in a given BGP UPDATE message conveys information that relates
to all Network Layer Reachability Information (NLRI)..." Does the NLRI include
the MP_REACH_NLRI case? If so, how? If not, it's better to clarify this in the
document.

Please expand ELCv3 when first use.

In Section 2.1, the last paragraph
Given the a BGP speaker "MUST" elect to be prepared to consume capabilities in
any order, I am not sure it's necessary to require that the sender "MUST" place
the Capablity TLVs in increasing oder. Maybe it's better to use some other
relax requirement.  For example, "It recommends that..."

In Section 2.2,

s/some other BGP speaker/some other BGP speakers
s/S need/S needs to

In Section 2.3
OLD:
When a BGP speaker receives a BGP route that includes the NHC, it MUST compare
the address given in the header portion of the NHC and illustrated in Figure 1
to the next hop of the BGP route. NEW: When a BGP speaker receives a BGP route
that includes a NHC, it MUST compare the next hop address given in the header
portion of the NHC illustrated in Figure 1 to the next hop of the BGP route.

s/some intermediate BGP speaker/some intermediate BGP speakers
s/both does not/both do not

In Section 3.2, it says:
"When a BGP speaker S has a route R it wishes to advertise with next hop N to
its peer, it SHOULD include the ELCv3 capability if it knows that the egress of
the associated LSP L is EL-capable, otherwise it MUST NOT include the ELCv3
capability." Is it appropriate to use "SHOULD" here, IMHO, it's better to use
"MAY".

In Section 3.3,
OLD:
"When a BGP speaker receives a labeled route that includes the ELCv3, it
indicates the associated LSP supports entropy labels." NEW: "When a BGP speaker
receives a labeled route that includes the ELCv3, it indicates the egress LSR
of associated LSP supports entropy labels."

Thanks,
Mach