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:linda.dun...@futurewei.com] Sent: Friday, October 6, 2023 4:42 AM To: Zhuangshunwan <zhuangshun...@huawei.com>; bess@ietf.org 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 <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> On Behalf Of Zhuangshunwan Sent: Thursday, September 28, 2023 6:40 AM To: bess@ietf.org<mailto:bess@ietf.org> 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
