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://wiki.ietf.org/en/group/gen/GenArtFAQ>. 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"? -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
