Basil, You asked a really good question "can you please explain how RFC8388 is used to learn the client prefixes in this scenario?"
SDWAN services to clients can be IP based or Ethernet based. RFC8388 has specified necessary parameters to be configured for Ethernet based services to clients. For IP based services, clients routes can be learned via OSPF, RIP, BGP or statically configuration. The mapping from clients routes to SDWAN Segmentation Identifier have to be configured. Do you think the following description is clear enough? "SDWAN services to clients can be IP based or Ethernet based. For IP based services, an SDWAN node can learn client routes from the client facing ports via OSPF, RIP, BGP or Statically configuration. If the SDWAN services are layer 2 services, the relevant EVPN parameters, such as the ESI (Ethernet Segment Identifier), EVI, CE-VID to EVI mapping have to be configured in the same way as EVPN described in RFC8388. " The CNx in Figure 2 represents a Client Network. Some CN can be multi-homed to two PEs (which is not shown in the figure for -02 revision, will be updated for -03 revision). Linda Dunbar From: Najem, Basil <basil.na...@bell.ca> Sent: Wednesday, January 27, 2021 9:19 PM To: Linda Dunbar <linda.dun...@futurewei.com>; bess@ietf.org Subject: RE: Is there any issue with the changes to the Packet Walk-Through for BGP SDWAN usage ? Dear Linda; Is CNx in Figure 2 represents a distinct IP prefix? If yes, this must be added to the description. The SD-WAN node can learn the local client's prefixes (i.e. the client prefixes that are connected directly to the node) via a routing protocol (e.g. OSPF, BGP); can you please explain how RFC8388 is used to learn the client prefixes in this scenario? More explanation is warranted here. Regards; Basil From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> On Behalf Of Linda Dunbar Sent: January-27-21 12:09 PM To: bess@ietf.org<mailto:bess@ietf.org> Subject: [EXT][bess] Is there any issue with the changes to the Packet Walk-Through for BGP SDWAN usage ? BESS WG: We recently made some changes to the Packet Walk-Through for BGP SDWAN usage https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bess-bgp-sdwan-usage%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ca271373344174f2afc5508d8c33b670c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637474007204890051%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HreBlgraCVoucOQzWmZxtrvM%2FUSI%2BE7frw%2BlER0jFJY%3D&reserved=0> . Since the draft is already a WG draft, want to solicit feedback from the WG if the changes are appropriate. 5.1 Packet Walk-Through for Scenario #1 (Homogeneous WAN) (This is referring to a type of SDWAN network with edge nodes encrypting all traffic over WAN to other edge nodes, regardless of whether the underlay is private or public.). A single IPsec security association (SA) protects data in one direction. Under the Scenario #1, two SAs must be present to secure traffic in both directions between any two end points, which can be two C-PE nodes, two client ports, or two prefixes. Upon power up, a SDWAN node can learn client routes from the Client facing ports in the same way as EVPN described in RFC8388. Controller, i.e. BGP-RR, facilitates the IPsec SA establishment and rekey management as described in [SECURE-EVPN]. Controller manages how client's routes are associated with individual IPSec SA. Using Figure 2 of the Section 3.2 as an example. Let's assume that the IPsec SAs terminate at the C-PE nodes. To enable full mesh communication within client CN2 that are attached to C-PE1, C-PE3, and C-PE4, six one directional IPsec SAs must be established: C-PE1 <-> C-PE3; C-PE1 <-> C-PE4; C-PE3 <-> C-PE4. The C-PE node address (or loopback address) acts as the Next Hop address for the prefixes attached to the C-PE node. When a C-PE receives a packet from its client port, the C-PE uses the IPsec SA whose destination address matches the Next Hop address of the packet's destination to encrypt the packet and forward the encrypted packet to the target C-PE via one of the C-PE's WAN ports. When a C-PE receives an encrypted packet from its WAN port, it decrypted the packet and forward the inner packet to the client port based on the inner packet's destination address. Any issues with this description? Thanks, Linda Dunbar
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
