I have looked at the diffss, and I would ask for one further
clarification. You edited the definition of "Transport Network" to say
"A network that comprises of multiple cooperating domains managed by one
or more operators". There is a trivial grammar problem, and I would ask
for a few words to strengthen the relationship and ground it in "trust
domain yielding:
A network that is comprised of multiple cooperating domains managed by
one or more operators that have agreed to trust each other's
specification of SRv6 SIDs.
Thank you
Joel
On 2/8/2025 1:22 AM, Dhananjaya Rao (dhrao) wrote:
Hi Joel,
Thanks very much for your careful review.
We have submitted (v-12) with updates to address your comments. Please
also see inline (DR#) for some responses.
*From: *Joel Halpern via Datatracker <nore...@ietf.org>
*Date: *Saturday, February 1, 2025 at 3:08 PM
*To: *gen-art@ietf.org <gen-art@ietf.org>
*Cc: *draft-ietf-idr-bgp-car....@ietf.org
<draft-ietf-idr-bgp-car....@ietf.org>, i...@ietf.org <i...@ietf.org>,
last-c...@ietf.org <last-c...@ietf.org>
*Subject: *Genart last call review of draft-ietf-idr-bgp-car-11
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
_______________________________________________
Gen-art mailing list -- gen-art@ietf.org
To unsubscribe send an email to gen-art-le...@ietf.org
