From: Reese Enghardt via Datatracker <noreply@xxxxxxxx>
Date: Monday, February 3, 2025 at 1:56 PM
To: gen-art@xxxxxxxx <gen-art@xxxxxxxx>
Cc: draft-ietf-idr-bgp-ct.all@xxxxxxxx <draft-ietf-idr-bgp-ct.all@xxxxxxxx>, idr@xxxxxxxx <idr@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: Genart last call review of draft-ietf-idr-bgp-ct-35
[External Email. Be cautious of content]
Reviewer: Reese Enghardt
Review result: Ready with Nits
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://urldefense.com/v3/__https://wiki.ietf.org/en/group/gen/GenArtFAQ__;!!NEt6yMaO-gk!C2aE03Ml2dHSqFr58R_O93n5Um5pCVxflarmgkLcMP2skYxcDZMqf83DzQN4qnYrGNE8OV-1zHF5GLM$ >.
Document: draft-ietf-idr-bgp-ct-35
Reviewer: Reese Enghardt
Review Date: 2025-02-03
IETF LC End Date: 2025-02-07
IESG Telechat date: 2025-02-20
Summary: The spec does a great job covering a complex system in a lot of
detail. I have a few comments on how to make the spec easier to understand for
readers.
Major issues: None.
Minor issues:
Introduction:
While it makes sense to point to RFC9315 to define what "Intent" is, please
consider quoting the definition from Section 2.1 at the beginning of the
Introduction. Alternatively, please point to the specific section of RFC9315
that the reader should read to be able to understand the rest of the document.
Alternatively, or maybe in addition, please consider giving a few more concrete
examples of "intent-aware" paths, possibly based on the examples in Section 3.1
of RFC 9315.
"Customers need to be able to signal desired Intent to the network, and the
network needs to have constructs able to enact the customer's intent. […] These
constructs enable services to express their intent to use one or more
identifiable classes, and mechanisms to selectively map traffic onto
"intent-aware" tunnels for these classes."
Do "signal intent" and "express intent" mean the same here? To me it would make
sense to think of a customer as person who expresses intent in terms of a goal
and outcome, and then a service signals the intent to the network. Please
consider rephrasing this part to make it clearer who does what.
"Appendix C provides an outline of the design philosophy behind this
specification. In particular, readers who are already familiar with one or more
BGP VPN technologies may want to review this appendix before reading the main
body of the specification."
As an unfamiliar reader with BGP VPN technologies, here it would help to
briefly explain the relationship between this spec and VPN technologies: Does
this spec leverage the VPN technologies, i.e., a VPN can be a transport tunnel?
Section 2.1:
I suggest moving the definition for "color:0:100" up so it comes before the
"Mapping Community" definition, which uses "color:0:100".
Section 3:
Is this overview already an example of an intent and how a network can map it
onto Transport Classes? If yes, please consider stating the specific intent at
the beginning of the section. If no, please consider explaining what parts of
the spec the example covers. Section 8 appears to have a more illustrative or
"full" example, and I wonder about the difference between the two sections.
If I understand correctly, it's possible to use Intent Driven Service Mapping
within just a single AS. Would it be possible to explain how the mapping works
for traffic within a single AS first, and then explain the signaling between
multiple ASes as a second step?
Figure 1 is very busy and the ASCII art takes a while to parse. Please consider
using SVG instead, and maybe even splitting the figure into two figures, with
one figure being the example topology and the other figure being the mappings
and other content below the topology. This would help readers see more quickly
that the same node names show up multiple times, once in the topology and once
in the part below.
"Figure 1 depicts the intra-AS and inter-AS application of these constructs. It
uses an example topology of Inter-AS option C network with two AS domains."
As a non-expert, I would find it helpful to explain what an Inter-AS option C
network is here. I did not see anything that says option C in Figure 1, and I
did not see option C defined in Section 2. Please consider adding a definition.
"BGP CT and BGP LU are transport layer families used between the two AS
domains."
Is this "Transport Families" as defined in Section 2.1? If so, I suggest to use
the defined term.
"IP1, IP2, IP3 are service prefixes (AFI/SAFI: 1/1) behind egress PE11."
What is a service prefix? I did not see the term defined in Section 2. Please
consider adding a definition.
"BGP CT makes it possible to advertise multiple tunnels to the same destination
address, thus avoiding the need for multiple loopbacks on the Egress Service
Node (eSN)."
What does loopback mean in this context, is it the same as an endpoint of a
tunnel as per definition of EP in Section 2? If so, please consider to
substitute loopbacks with EPs here and on other uses.
"It disseminates "Transport Class" information for the transport prefixes
across the participating domains while avoiding the need of per-transport class
loopback. This is not possible with BGP LU without using per-color loopback.
This makes the end-to-end network a "Transport Class" aware tunneled network."
What is "This" in the last sentence - Disseminating Transport Class
information? I suggest to substitute the "This" for a more specific subject
here.
"The following text illustrates CT architecture having the property of
providing tiered fallback options at a per-route granularity. In Figure 1, the
Resolution Schemes are shown and the following next hop resolutions are done by
SN11 and PE21 for the service routes of prefixes IP1, IP2, IP3: Resolve IP1
next hop over available tunnels in TRDB for Transport Class 100 with fallback
to TRDB for best effort. Resolve IP2 next hop over available tunnels in TRDB
for Transport Class 200 with fallback to TRDB for best effort. Resolve IP3 next
hop over available tunnels in TRDB for Transport Class 100 with fallback to
TRDB for Transport Class 200."
Is a transport class the same as an intent here, i.e., are 100 and 200
different intents? Or is the intent the color? Please consider briefly
explaining how the different concepts apply to this example.
It would also be helpful to know if or how the intent is formalized or
expressed. Is an intent the same as a color or a transport class? If an intent
is the same as a color, but Gold can have finer shades in Section 11.2.3, does
this mean the color implies an intent but the intent does not always imply a
color?
Why are SN11 and PE21 the nodes doing the resolution? For PE21, it is plausible
for me that that's where the traffic enters the network. But SN11 appears to be
within AS 1, while traffic enters AS1 at BN11, as far as I can tell. Please
consider briefly explaining why these nodes play the roles that they do.
Section 5:
"An implementation may provide an option for the overlay route to resolve over
less preferred Transport Classes, should the resolution over a primary
Transport Class fail."
What is a primary Transport Class? I did not see the concept defined in Section
2. Please consider adding a definition.
Section 5.1:
"An example of mapping community is "color:0:100", described in [RFC9012], or
the "transport-target:0:100" described in Section 4.3 in this document."
In Section 4.3 I don't see "transport-target:0:100", is this the right
reference?
Nits/editorial comments:
Abstract:
"A new BGP address family that leverages RFC 4364 ("BGP/MPLS IP Virtual Private
Networks (VPNs)" procedures […]"
Missing closing bracket
Section 1:
"Provider networks that are deployed using such styles provision intra-domain
transport tunnels between a pair of endpoints, typically a service node or a
border node, that service traffic use to traverse that domain"
Is it "used to traverse that domain", or is is there a term "service traffic
use"? Or is it simply "…that service traffic that traverses that domain"?
