Thank you Linda. I'll request LC G/ ________________________________ From: Linda Dunbar <[email protected]> Sent: Tuesday, April 7, 2026 8:20 PM To: Gunter van de Velde (Nokia) <[email protected]>; [email protected] <[email protected]> Cc: BESS <[email protected]>; Matthew Bocci (Nokia) <[email protected]> Subject: RE: [Shepherding AD review] review of draft-ietf-bess-bgp-sdwan-usage-29
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Gunter, Thank you, the revision that has included the resolutions to your comments has been uploaded: https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/ Linda From: Gunter van de Velde (Nokia) <[email protected]> Sent: Tuesday, April 7, 2026 1:52 AM To: Linda Dunbar <[email protected]>; [email protected] Cc: BESS <[email protected]>; Matthew Bocci (Nokia) <[email protected]> Subject: Re: [Shepherding AD review] review of draft-ietf-bess-bgp-sdwan-usage-29 Thanks Linda. Once updated I'll process for the next steps in the lifecycle of the document. Be well, G/ ________________________________ From: Linda Dunbar <[email protected]<mailto:[email protected]>> Sent: Friday, April 03, 2026 5:40 PM To: Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: BESS <[email protected]<mailto:[email protected]>>; Matthew Bocci (Nokia) <[email protected]<mailto:[email protected]>> Subject: RE: [Shepherding AD review] review of draft-ietf-bess-bgp-sdwan-usage-29 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Gunter, Thank you very much for the valuable comments. Please see below after [Linda] for the resolutions. Linda From: Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>> Sent: Thursday, April 2, 2026 1:32 AM To: [email protected]<mailto:[email protected]> Cc: BESS <[email protected]<mailto:[email protected]>>; Matthew Bocci (Nokia) <[email protected]<mailto:[email protected]>> Subject: [Shepherding AD review] review of draft-ietf-bess-bgp-sdwan-usage-29 Hi Authors, WG, # Gunter Van de Velde, RTG AD, comments for draft-ietf-bess-bgp-sdwan-usage-29 # line numbers are rendered from the idnits tool found at https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-bgp-sdwan-usage-29.txt # Many thanks for the shepherd writeup from Matt Bocci, and thanks for the routing directorate reviews from Shuping Peng and Alvaro Retana. # Authors, many thanks for all the hard work on this draft. It came a long way. My generic comments are mostly of editorial nature. # Running idnits identifies a set of unused references, please resolve with the next version. # once an update draft is posted, I'll start processing for IETF LC on this informational track document. #GENERIC COMMENTS #================ 140 plane information. In this document, references to "the RR" denote 141 the RR instance(s) designated by the SD-WAN controller to 142 distribute SD-WAN routing information. Deployments may integrate GV> in section 2 is controller explained and RR introduced. However that comes after this specific usage of the term RR. Is this intentional or can the the term RR be expanded at first usage? [Linda] Good catch. This was not intentional. We will expand RR to “Route Reflector (RR)” at first use in the Introduction. Old: “In this document, references to “the RR” denote the RR instance(s) designated by the SD-WAN controller to distribute SD-WAN routing information” New: “In this document, references to “the Route Reflector (RR)” denote the RR instance(s) designated by the SD-WAN controller to distribute SD-WAN routing information.” 165 2. Conventions used in this document GV> many terms are explained in this section. Could the RR be explicitly mentioned in this list also and how it relates to sd-wan. I know its embroided in other terminologies, but since the term i suse dso often it maybe makes sense to say few words about it. 170 Controller: Used interchangeably with SD-WAN controller to denote 171 the logical system that manages the SD-WAN overlay 172 network. In the context of BGP-controlled SD-WAN, one 173 function of the SD-WAN controller is to provide BGP- 174 based route propagation, i.e., the Route Reflector 175 (RR) function. This RR function may be collocated with 176 or embedded within the SD-WAN controller, but 177 represents only one component of the overall SD-WAN 178 controller. 180 the SD-WAN controller functions are integrated with the BGP Route 181 Reflector (RR). GV> Line 180 may have an editorial tab issue. (it starts at the same character space as Controller) [Linda] How about the following text change: Old: Controller: Used interchangeably with SD-WAN controller to denote the logical system that manages the SD-WAN overlay network. In the context of BGP-controlled SD-WAN, one function of the SD-WAN controller is to provide BGP-based route propagation, i.e., the Route Reflector (RR) function. This RR function may be collocated with or embedded within the SD-WAN controller, but represents only one component of the overall SD-WAN controller. The SD-WAN controller functions: are integrated with the BGP Route Reflector (RR). New: Controller: Used interchangeably with SD-WAN controller to denote the logical system that manages the SD-WAN overlay network. In a BGP-controlled SD-WAN, the controller may include a Route Reflector (RR) function for BGP route propagation and policy-based distribution of SD-WAN routing information. The RR function may be collocated with, embedded in, or otherwise integrated with the SD-WAN controller, but it represents only one component of the overall controller. 762 - Update 1: Client Route Advertisement for advertising the 763 prefixes of client services attached to the client facing 764 interfaces. The Section 8 of [RFC9012] (Recursive Next-Hop 765 Resolution) can be used to associate each client service with 766 the corresponding WAN ports for the desired underlay paths. 767 - Update 2: Underlay WAN Port Advertisement, which conveys 768 information about the underlay WAN facing interfaces of an SD- 769 WAN edge, including attributes such as IPsec SA parameters, MPLS 770 label stacks, and other relevant attributes. These attributes 771 are carried in the BGP Tunnel Encapsulation Attribute, along 772 with associated Color values that allow BGP receivers to 773 correlate the WAN facing interfaces with the client routes 774 advertised in Update 1. GV> I think i understand the high level processing, i do believe that adding a diagram may explain more clearly/accuratly the intent of each bgp route. Note that "underlay wan port" is not mentioned in the convention section [Linda] We believe the existing Figure 6 (Section 5.2) already illustrates the roles of the two BGP UPDATEs and the relationship among the client routes, the SD-WAN edge, and the RR. Instead of adding another figure, we can revise the text in Section 5.3 to refer readers to Figure 6 and to make the distinct roles of the two BGP UPDATEs clearer, including how they are associated through recursive next-hop resolution. New: Update 1: Client Route Advertisement. This UPDATE advertises the prefixes of client services attached to the client-facing interfaces of an SD-WAN edge. As described in Section 8 of [RFC9012], recursive next-hop resolution can be used to associate each client route with the appropriate WAN-facing interface(s) of the advertising SD-WAN edge for the desired underlay path. Figure 6 illustrates the relationship among the client routes, the SD-WAN edge, and the RR. Update 2: WAN-Facing Interface Advertisement. This UPDATE advertises information about the WAN-facing interfaces of an SD-WAN edge that connect to the underlay networks, including attributes such as IPsec SA parameters, MPLS label stacks, and other relevant underlay properties. These attributes are carried in the BGP Tunnel Encapsulation Attribute, together with associated Color values, allowing BGP receivers to associate the advertised WAN-facing interfaces with the client routes advertised in Update 1. Figure 6 also illustrates the SD-WAN edge WAN ports that are the basis for this advertisement. 815 BGP UPDATE #1a: Propagated only to the Payment Gateway node for a 816 point-to-point (P2P) topology between the Payment Application and 817 the Payment Gateway. 818 819 BGP UPDATE #1b: Propagated to C-PE1 and C-PE3 for other prefixes 820 that can be reached by these edge nodes. GV> the text reads 'propagated only to' but does not document which devices are originating the BGP UPDATE? [Linda] How about changing the wording to the following: BGP UPDATE #1a: Originated by the SD-WAN edge attached to the Payment Application and propagated by the RR only to the Payment Gateway node, thereby creating a point-to-point (P2P) topology between the Payment Application and the Payment Gateway. BGP UPDATE #1b: Originated by the same SD-WAN edge for other prefixes and propagated by the RR to C-PE1 and C-PE3 when those prefixes are authorized to be reached by those edge nodes. 822 +-------+ 823 |Payment| 824 +------->| GW |<----+ 825 / +-------+ \ 826 / Blue Tunnel \ 827 /for Payment App:192.0.2.9/30\ 828 / \ 829 +------+--+ +----+----+ 830 --| | | |-192.0.2.9/30 831 | | Red Tunnels | | 832 --| C-PE1 |------------------------| |-192.0.2.4/30 833 |192.0.2.1| | C-PE2 | 834 --| |------------------------|192.0.2.2|-192.0.2.8/30 835 | ------+ +| | VLAN=25; 836 / | |-192.0.2.10/30 837 +---------+ / +---------+ 838 --| |--------------------+ 839 | C-PE3 | / 840 |192.0.2.3| / 841 --| |-----------------+ 842 +---------+ 843 Figure 7: Flow Based SD-WAN Segmentation GV> What are Red Tunnels and Blue tunnels? Could it be that during the editing of the section some context was lost on the tunnel descriptions. [Linda] Added this sentence at the end of the Figure 7: In Figure 7, the “Blue Tunnel” denotes the tunnel used exclusively for Payment Application traffic toward the Payment Gateway, whereas the “Red Tunnels” denote tunnels used for other authorized traffic among SD-WAN edge nodes. 869 SD-WAN services to clients can be IP-based or Ethernet-based. For 870 IP-based services, an SD-WAN edge can learn client addresses from 871 the client-facing interfaces via OSPF, RIP, BGP, or static 872 configuration. For Layer-2 services, the EVPN parameters, such as GV> Can references to the base specs of these protocols be added? [Linda] Added the reference: SD-WAN services to clients can be IP-based or Ethernet-based. For IP-based services, an SD-WAN edge can learn client addresses from the client-facing interfaces via OSPF [RFC2328][RFC5340], RIP [RFC1058][RFC2453], BGP [RFC4271], or static configuration. For Layer-2 services, the EVPN parameters, such as 1041 this Case, an outer UDP field is added to the encrypted payload GV> s/Case/case/ [Linda] Changed. Kind Regards, Gunter Van de Velde Routing Area Director
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
