Reviewer: Joel Halpern Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-idr-bgp-car-11 Reviewer: Joel Halpern Review Date: 2025-01-31 IETF LC End Date: 2025-02-13 IESG Telechat date: 2025-02-20 Summary: This document describes an experimental approach to encoding the association of color / routing intent with a BGP advertisement. It is almost ready for publication as an experimental RFC. Major issues: I am aware of the history of debates and compromises that led to this document (and other documents) being aimed for experimental status. However, that does not as far as I can tell obviate the need to describe the experiment. I am not concerned about the question of duration. But I would like to see text that says what conditions would constitute success or failure of the experiment. For example is wide deployment of one of the several described BGP techniques sufficient? Is some deployment of all the described techniques necessary? Are there other measures that should judge the experiment? There is also a question of applicability regarding the SRv6 support. The document appears to advertise SRv6 SIDs across domain boundaries. There is not, as far as I can see, a description of trust boundaries so as to meet the required limitations on the use of SRv6. In fact, the transport domain definition says explicitly that it can be one or more operators, with no mention of trust. Section 7.2.2 on Encapsulation between BRs for BGP SRv6 Prefixes references the H.Insert behavior for SRv6 SIDs. While there is indeed a code point allocated for that behavior, there is no RFC description of that behavior, and there are strong arguments that said behavior violates existing RFCs. Since the operation with H,Encaps is sufficient for the the deployment being described, please remove the reference to H.Insert. Minor issues: Positive: I appreciate the caveat in the definitions regarding intent, making clear the meaning as used in this document. Section 2.9.2.2 on the label index TLV says that this is a transitive attribute. However, it also says that if BGP CAR speaker sets itself as next-hop, it allocates a local label. But apparently it doesn't put that label into the BGP advertisement? Some aspect of the description seems to be missing. Also, that section seems to allow only one segment index, even though a SR-MPLS route will typically need several such? I think I misunderstand how this is supposed to work with SR? Section 2.9.2.3 on SRv6 SID Tlv says that the attribute is non-transitive. Which makes sense. However, I am not seeing the text that specifies what a node should do if it chooses to set itself as next hop? I presume it should replace this TLV with an advertisement of a suitable SRv6 SID (associated with the advertising node) and locally configure that SRv6 SID to map to the received SRv6 information? The last sentence of the section also suggests that incoming MPLS information can be replaced by outgoing SRv6 information, or the obverse. If that is intended, could it please be stated more explicitly? There is a minor point that I think should be documented in section 10.3 on BGP CAR NLRI TLVs. Namely, that if new TLVs are defined, they are not permitted for use with the existing NLRI Types unless the documentation of those types is updated? I believe this is a corollary of the various descriptions, and it would help to state it. Nits/editorial comments: Regarding Service Route Automated Steering on Color-Aware Path in the definitions section, the text says that the ingress router steers the service route. I see that later on, the text says that service route steering steers traffic. If this convoluted phrasing is what we are using everywhere, so be it. But it does seem an odd way to say that the traffic is steered. Section 7.1 giving an overview of CAR using SRv6 says "Steering services over SRv6 based intent-aware multi-domain transport paths may be categorized into two distinct cases, as described in Section 5 of [RFC9252]." While it is not a big deal, this is a confusing way of referring to that portion of RFC 9252. That section has four subsections. And while there are two of them that relate to IPv6 over SRv6, those two sections do not have names that correspond tp the two sub-sections of 7.1 in this document. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
