Hi John, Reese,
I made another github push today with minor edits.
I published version 36 of the draft which incorporates comments from
Reese.
If there are any more comments, we can update in next version.
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ct-36
@Reese Enghardt <mailto:i...@tenghardt.net>, thanks a bunch for the
comments. They indeed uplifted how the draft looks.
Thanks
Kaliraj
Juniper Business Use Only
*From: *John Scudder <jgs=40juniper....@dmarc.ietf.org>
*Date: *Friday, February 7, 2025 at 5:57 AM
*To: *Kaliraj Vairavakkalai <kali...@juniper.net>
*Cc: *Reese Enghardt <i...@tenghardt.net>, gen-art@ietf.org
<gen-art@ietf.org>, draft-ietf-idr-bgp-ct....@ietf.org
<draft-ietf-idr-bgp-ct....@ietf.org>, i...@ietf.org <i...@ietf.org>,
last-c...@ietf.org <last-c...@ietf.org>
*Subject: *Re: [Idr] Genart last call review of draft-ietf-idr-bgp-ct-35
*[External Email. Be cautious of content]*
Hi Reese, Kaliraj,
Thanks for your review, Reese, and your work updating the draft,
Kaliraj. For clarity: I’ve issued the IESG ballot for the document to
be on the agenda of the February 20 IESG telechat, but you should
still go ahead and publish the update as soon as you’re ready.
Thanks,
—John
On Feb 7, 2025, at 5:46 AM, Kaliraj Vairavakkalai
<kaliraj=40juniper....@dmarc.ietf.org> wrote:
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
<https://urldefense.com/v3/__https:/raw.githubusercontent.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/refs/heads/main/draft-ietf-idr-bgp-ct.txt__;!!NEt6yMaO-gk!BdX_QeCYuJFQRRqa535TWvIniKZaO_NG4FjiLu8Yj7JprDkezzkDC56s0udCI4sX-X2gqmJ7V9IppJKvaPFixvcRQiVL$>
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
<https://urldefense.com/v3/__https:/author-tools.ietf.org/diff?url_1=https:**Awww.ietf.org*archive*id*draft-ietf-idr-bgp-ct-35.txt&url_2=https:**Araw.githubusercontent.com*ietf-wg-idr*draft-ietf-idr-bgp-ct*refs*heads*main*draft-ietf-idr-bgp-ct.txt__;Ly8vLy8vLy8vLy8vLw!!NEt6yMaO-gk!BdX_QeCYuJFQRRqa535TWvIniKZaO_NG4FjiLu8Yj7JprDkezzkDC56s0udCI4sX-X2gqmJ7V9IppJKvaPFixosYBcUr$>
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 datatrackernore...@ietf.org
Date: Monday, February 3, 2025 at 1:56 PM
To:gen-art@ietf.orggen-...@ietf.org
Cc:draft-ietf-idr-bgp-ct....@ietf.orgdraft-ietf-idr-bgp-ct.all@ietf.org,idr@ietf.org...@ietf.org,last-call@ietf.orglast-c...@ietf.org
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
Juniper Business Use Only
_______________________________________________
Idr mailing list --i...@ietf.org <mailto:i...@ietf.org>
To unsubscribe send an email toidr-le...@ietf.org
<mailto:idr-le...@ietf.org>
