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 Datatracker nore...@ietf.org<mailto:nore...@ietf.org> Date: Monday, February 3, 2025 at 1:56 PM To: gen-art@ietf.org<mailto:gen-art@ietf.org> gen-art@ietf.org<mailto:gen-art@ietf.org> Cc: draft-ietf-idr-bgp-ct....@ietf.org<mailto:draft-ietf-idr-bgp-ct....@ietf.org> draft-ietf-idr-bgp-ct....@ietf.org<mailto:draft-ietf-idr-bgp-ct....@ietf.org>, i...@ietf.org<mailto:i...@ietf.org> i...@ietf.org<mailto:i...@ietf.org>, last-c...@ietf.org<mailto:last-c...@ietf.org> last-c...@ietf.org<mailto:last-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 to idr-le...@ietf.org<mailto:idr-le...@ietf.org>
_______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
