Hi Linda, Thank you for your reply. I now understand the solution described in the draft and I support its WG adoption.
Best Regards, Shunwan From: Linda Dunbar [mailto:[email protected]] Sent: Friday, October 6, 2023 4:42 AM To: Zhuangshunwan <[email protected]>; [email protected] Subject: RE: Mail regarding draft-ietf-bess-bgp-sdwan-usage ShunWan, Thank you very much for review and the detailed comments. Resolutions to your comments are inserted below. Linda From: BESS <[email protected]<mailto:[email protected]>> On Behalf Of Zhuangshunwan Sent: Thursday, September 28, 2023 6:40 AM To: [email protected]<mailto:[email protected]> Subject: [bess] Mail regarding draft-ietf-bess-bgp-sdwan-usage Dear authors, Some of the text in the section 5.2 of draft-ietf-bess-bgp-sdwan-usage-15 describes the following: " 5.2. BGP Walk Through for Homogeneous Encrypted SD-WAN ... UPDATE U1: - MP-NLRI Path Attribute: 192.0.2.4/30 192.0.2.8/30 - Nexthop: 192.0.2.2 (C-PE2) - Encapsulation Extended Community: TYPE = IPsec UPDATE U2: - MP-NLRI Path Attribute: 192.0.2.2 (C-PE2) - Tunnel Encapsulation Path Attributes (as described in the [SECURE-EVPN]) for IPsec SA detailed attributes, including the WAN address to be used as the IP address of the IPsec encrypted packets. If different client routes attached to C-PE2 need to be reached by separate IPsec tunnels, the Color-Extended-Community [RFC9012] is used to associate routes with the tunnels. See Section 8 of [RFC9012]. ... " I have one comment on the above text: Regarding the "Encapsulation Extended Community: TYPE = IPsec" in UPDATE U1, maybe the possible TYPE should be ESP-Transport or ESP-in-UDP-Transport as described in Sections 9.1 and 9.2 of [Security-EVPN]? [Linda] that is another option. However, since the [Security-EVPN] is further away from reaching RFC stage, I feel we should use the standardized type for now. Best Regards, Shunwan
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
