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?
DR# I would request Sue to clarify this since as you mentioned, it is not specific to BGP CAR and applies to other solutions too.
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.
DR# We have updated the definition to indicate it is between cooperating domains. The draft also states in Section 12 that section 9.3 of <xref target="RFC9252"/> applies.
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.
DR# It’s removed in the updated version.
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.
DR# This section describes the use of Label-Index which is used in conjunction with the Label that’s already described in the previous section. We have updated the text to clarify.
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?
DR# This is as per RFC8669. The label-index is for a given prefix or Node, which will have only 1 SID.
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?
DR# We have updated the text.
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.
DR# Updated.
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.
DR# The references are not to those subsections, but to the two broad forms that are described in Paragraph 5 and Paragraph 7 respectively.
Regards,
-Dhananjaya
