The draft has few issues that should be addressed. The authors did an excellent job combining ELCv3 with NHC. Draft overview & history and issues solved by this draft: ELCv1 RFC 6790 - ELC optional transitive path attribute 28 that unfortunately gets propagated by transit nodes not supporting per RFC 4271 and not remove as desired. RFC 7447 deprecated the RFC 6790 code point - optional transitive attribute ELCv2 Juniper implementation copies next hop into data field of the path attribute for signaling check, uses the original RFC 6790 code point deprecated by RFC 7447. ELCv3 rev 00 is identical to ELCv2 Juniper implementation optional transitive path attribute, but now with a new code point IANA allocation and thus is required per RFC 8216 must be Standards track. NHC draft - Generic next hop capability which can be used for the EL signaling- non transitive BGP attribute. https://datatracker.ietf.org/doc/html/draft-ietf-idr-next-hop-capability-08 ELCv3 rev 01 – ELCv3 + NHC – Generic next hop capability to support other use cases Juniper customers running ELCv2 with deprecated code point from RFC 7447 need a resolution so the goal of IDR is to get a draft. Juniper has an attribute 28 discard knob to strip attribute 28. An issue was reported recently with attribute 28 ELC caused session reset on versions of Juniper code due to incorrectly flagging the packets as corrupt. https://labs.ripe.net/author/emileaben/unknown-attribute-28-a-source-of-entropy-in-interdomain-routing/ ELCv3 Rev 2 no change ELCv3 Rev 3 Section 3.1 added Readable label depth ELCv3 Rev 4 Security consideration next hop capability filtering in/out & trust relationship ELCv3 Rev 5 IANA codepoint 0 Reserved, By default RCA must not be accepted ELCv3 Rev 6 BY default RCA must be accepted There are no implementations of ELCv3 or NHC. Major issues: None Minor issues: Updates & Recommendations to RFC 2119 Normative language 2nd to last paragraph of Introduction Old An RCA carried in a given BGP UPDATE message conveys information that relates to all NLRI advertised in that particular UPDATE, and only to those NLRI. A different UPDATE message originated by the same source might not include an RCA, and if so, NLRI carried in that UPDATE would not be affected by the RCA. By implication, if a router wishes to use RCA to describe all NLRI it originates, it needs to include an RCA with each UPDATE it sends. In this respect, despite its similar naming, the RCA is unlike RFC 5492 BGP Capabilities. New An RCA carried in a given BGP UPDATE message MAY convey information that relates to all NLRI advertised in that particular UPDATE, and only to those NLRI. A different UPDATE message originated by the same source might not include an RCA, and if so, NLRI carried in that UPDATE would not be affected by the RCA. By implication, if a router wishes to use RCA to describe all NLRI it originates, it MUST include an RCA with each UPDATE it sends. In this respect, despite its similar naming, the RCA is unlike RFC 5492 BGP Capabilities. Section 2.1 – I think it would be good to more clearly correlate the “address given in the header portion of the RCA” and what that is as it is referred back t in section 2.3. Old The BGP Router Capabilities attribute (RCA attribute, or just RCA) is an optional, transitive BGP path attribute with type code 39. The RCA has as its data a network layer address, representing the next hop of the route the RCA accompanies. New The BGP Router Capabilities attribute (RCA attribute, or just RCA) is an optional, transitive BGP path attribute with type code 39. The RCA header has its data field set to the network layer address, representing the next hop of the NLRI AFI / SAFI route. Rewritten to make more clear I would not call RCA an optimization but rather a way to provide next hop intelligence in an opaque data fields that is extensible to a variety of meanings Old The RCA signals potentially useful optimizations, so it is desirable to make it transitive; the next hop data is to ensure correctness if it traverses BGP speakers that do not understand the RCA. New The RCA signals potentially useful next hop extensibility logic, so it is desirable to make it transitive; the next hop data is to ensure correctness in cases where it may traverses BGP speakers that do not understand the RCA. Nits: Abstract Should say a “new optional transitive attribute” as its optional. As the NHC was folded into ELCv3 no need to reference this draft. https://datatracker.ietf.org/doc/html/draft-ietf-idr-next-hop-capability-08 Introduction This specification defines a new BGP optional transitive attribute to carry such capability information, the "Router Capabilities Attribute", or RCA. (This somewhat ponderous name is regrettable but is needed in order to be descriptive while still distinguishing it from RFC 5492 BGP Capabilities.) Maybe you can exlclude in (This somewhat ponderous name is regrettable but is needed in order to be descriptive while still distinguishing it from RFC 5492 BGP Capabilities.) I think RCA is an appropriate term to the use case and as it may seem confusing RFC 5492 “capability advertisement with BGP” is subjective only that the word “capability” is used in both but RFC 5492 is “BGP capability” update with the addition of capability options parameter type 2 & error handling where RCA is about “router capability” advertisement. ! Making this next two sentences easier to parse Old Since the RCA is intended chiefly for conveying information about forwarding plane features, it needs to be regenerated whenever the BGP route's next hop is changed. Since owing to the properties of BGP transitive attributes this can't be guaranteed (an intermediate router that doesn't implement this specification would be expected to propagate the RCA as opaque data), the RCA identifies itself with the next hop of its originator. New Since RCA is intended for conveying information about forwarding plane features, RCA MUST to be regenerated whenever the BGP route's next hop is changed. Transitiveness of BGP path attributes does not guarantee this behavior (an intermediate router that doesn't implement this specification would be expected to propagate the RCA as opaque data), thus requiring the RCA to identify itself with the next hop of its originator. Last sentence in introduction Old It updates [RFC6790] and [RFC7447] with regard to this BGP signaling, this is further discussed in Section 3. New It updates [RFC6790] and [RFC7447] with regard to this BGP signaling, discussed further in Section 3. I am in agreement with the updates from Rev 5 to Rev6 in the changes made in Section 2.2 & 2.3. In particular that the implementation should accept the RCA by default. In section 2.2 & 2.3 sending & receiving the RCA is the default applicable to all NLRI and if so that should be specified. As it is recommended to have configuration control and fine grain control that maybe available for attribute propagation by implementations for advertising and accepting RCA, I think its OK to send & receive RCA for ALL NLRI by default. Since the RCA is being used for signaling of the next hop data field extensible to any TLVs that require such as entropy label for load balancing or any other use case I am not sure how the path attribute could impact routing and cause a routing loop as its not a mandatory path attribute and is optional transitive but is not part of the BGP best path selection algorithm. In cases where all nodes do not understand the capability which is understandable and the RCA draft accounts for that with regards to propagation w/o regeneration with next hop changes results in mismatch and the RCA is discarded. So that does provide the interoperability with other non supporting nodes and provides incremental deployment so now sure how the RCA could result in routing loops. Maybe this subject should be expanded upon if its a real danger. The presence of a capability SHOULD NOT influence route selection or route preference, unless tunneling is used to reach the BGP next hop or the selected route has been learned from External BGP (that is, the next hop is in a different Autonomous System). Indeed, it is in general impossible for a node to know that all BGP routers of the Autonomous System (AS) will understand a given capability, and if different routers within an AS were to use a different preference for a route, forwarding loops could result unless tunneling is used to reach the BGP next hop.¶ Section 2.5 Talks about the Anycast use case AFAIK with MPLS unidirectional LSP is possible and LDP downstream unsolicited from downstream to upstream node label mapping message for the FEC label binding. If we had multiple egress PE LER with the same loopback the LSP would only build to one of the egress LSRs not all of them. I think this section should be removed as Anycast is really only relevant in the context of SR-MPLS using the Anycast SID where the node-sid loopback0 is defined on multiple egress PE’s for resiliency or on inter-domain boundaries with node-sid same loopback on all ASBRs. Section 6.1 Good idea to include OAD draft here to incorporate into the specification for RCA use cases "inter admin domain" RCA localization for cooperating ASN’s in an OAD. https://datatracker.ietf.org/doc/draft-uttaro-idr-bgp-oad/ As the RCA optional transitive attribute is likely to be propagated inter domain resulting in “attribute escape” it is at least limited to the receiving ASBR which will fail the next hop check and discard the RCA. The next hop within the operator domain would be then then exposed to the other carriers domain but limited to the 1st ASBR within the domain. Care must be taken with unwanted leakage of next hop data field and unintentional exposure and consequences. https://datatracker.ietf.org/doc/draft-haas-idr-bgp-attribute-escape/ Kind Regards Gyan