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? 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) 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 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? 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. 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? 1041 this Case, an outer UDP field is added to the encrypted payload GV> s/Case/case/ Kind Regards, Gunter Van de Velde Routing Area Director
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
