[Last-Call] Re: [Idr] Genart last call review of draft-ietf-idr-bgp-ct-35

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

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.net@xxxxxxxxxxxxxx> wrote:


Hi Reese,
 
 
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 noreply@xxxxxxxx
      Date: Monday, February 3, 2025 at 1:56 PM
      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
 
 
      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 -- idr@xxxxxxxx
To unsubscribe send an email to idr-leave@xxxxxxxx

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux