Hi Reese,
I have made changes and posted to github:
https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/refs/heads/main/draft-ietf-idr-bgp-ct.txt
Diff:
https://author-tools.ietf.org/diff?url_1=https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-35.txt&url_2=https://raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/refs/heads/main/draft-ietf-idr-bgp-ct.txt
If you have any further comments, please let me know. If everything look OK, I
can publish the next version to IETF.
Please see below for some inline responses. KV>
Thanks
Kaliraj
From: Reese Enghardt via Datatracker
[email protected]<mailto:[email protected]>
Date: Monday, February 3, 2025 at 1:56 PM
To: [email protected]<mailto:[email protected]>
[email protected]<mailto:[email protected]>
Cc:
[email protected]<mailto:[email protected]>
[email protected]<mailto:[email protected]>,
[email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]>,
[email protected]<mailto:[email protected]>
[email protected]<mailto:[email protected]>
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$
<https://urldefense.com/v3/__https:/wiki.ietf.org/en/group/gen/GenArtFAQ__;!!NEt6yMaO-gk!C2aE03Ml2dHSqFr58R_O93n5Um5pCVxflarmgkLcMP2skYxcDZMqf83DzQN4qnYrGNE8OV-1zHF5GLM$%20>
.
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.
KV> Moved the quote to the Introduction.
"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.
KV> Makes sense. Altered.
"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?
KV> Yes this spec leverages aspects of VPN technologies like RD, RT - and RFC
4364 procedures.
KV> That is what is descibe in Appendix. Earlier versions had this description
in main body of
KV> draft. But we received comments that it is distracting background info, so
we moved it to Appendix.
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".
KV> I see it is before Mapping Community in Sec 2.1.
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.
KV> Yes it gives overview of the whole solution using two Intents denoted by
colors
KV> 100 (low-latency) and 200 (high-bandwidth). Added text clarifying this.
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?
KV> That is correct. This example describes both Intra-domain and Inter-domain
KV> application. Intra-AS usecase is explained with SN11 as ingress and PE11
KV> as Egress PE.
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.
KV> We did convert it to SVG in version 35. Yea it tries to describe the whole
solution
KV> in brief in one diagram, so it is a bit busy. We've tried our best. :)
"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.
KV> These are Inter-AS options described in RFC-4364 Section 10. Will include
the reference here.
KV> Actually Section 1 (Introduction) has these references when referring to
them first time:
"The constructs and procedures defined in this document apply equally to
intra-AS as well as
inter-AS (a.k.a. multi-AS) Option A, Option B and Option C (Section 10,
[RFC4364]) style
deployments in provider networks."
KV> But I can add the reference here also.
"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.
KV> Ack. Changed.
"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.
KV> Added.
"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.
KV> It is the loopback addresses on the Egress node. Loopback is more familiar
to
KV> operators since they provision them. So would like to leave it as loopback.
"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.
KV> Yes. Reworded. "This dissemination makes the end-to-end network a
"Transport Class" aware tunneled network."
"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.
KV> The resolution-scheme is used to realize the Intent. e.g. use color 100
tunnels with fallback over best-effort.
KV> The above para tries to explain this only. Added a line explaining it.
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?
KV> Added text clarifying about Resolution scheme in section 3. Pls Note: Sec 5
has
KV> more details about resolution scheme
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.
KV> This is to explain both intra-AS and inter-AS service-mapping. As explained
in Sec 3 3rd para:
KV> "SN11 is an ingress PE with intra domain reachability to PE11. PE21 is an
ingress PE with inter domain reachability to PE11."
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.
KV> The following para describes this:
"To accomplish this, the "Resolution Scheme" is configured with the primary
Transport Class, and an ordered list of fallback Transport Classes. Two
Resolution Schemes are considered equivalent in Intent if they consist of the
same ordered set of TRDBs."
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?
KV> It is the right reference. I added the following line to the section:
"A Transport Class Route Target Extended community with TC ID 100
is denoted as "transport-target:0:100"
Nits/editorial comments:
Abstract:
"A new BGP address family that leverages RFC 4364 ("BGP/MPLS IP Virtual
Private
Networks (VPNs)" procedures […]"
Missing closing bracket
KV> Fixed.
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"?
KV> Reworded to the following, please check:
"Such networks provision intra-domain transport tunnels between a pair of
endpoints,
typically a service node or a border node that service traffic traverses
through."
Juniper Business Use Only
_______________________________________________
Gen-art mailing list -- [email protected]
To unsubscribe send an email to [email protected]
