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