Re: [Idr] Solicit feedback to BGP UPDATE encoding options for SDWAN WAN port properties propagation among SDWAN edges (pros & cons to draft-dunbar-idr-sdwan-port-safi and alternatives)

["Wanghaibo (Rainsword)" <[e-mail]>]

Hi Linda,
I think both option 1 & 2 is Ok , but use for different scenario.
For option 2, it may use for all service share same SDWAN tunnel. For option 1, it may use for each service has different requirement.
Though option 1 also can realize the share same SDWAN tunnel, but it will choose one or more routes to advertise the SDWAN tunnel info , it may cause the tunnel deploy complex.

Regards,
Haibo

From: Idr [mailto:[e-mail]] On Behalf Of Linda Dunbar
Sent: Tuesday, August 13, 2019 6:19 AM
To: [e-mail]
Subject: [Idr] Solicit feedback to BGP UPDATE encoding options for SDWAN WAN port properties propagation among SDWAN edges (pros & cons to draft-dunbar-idr-sdwan-port-safi and alternatives)

IDR participants:

Many thanks to the feedback from IETF105 discussion on draft-dunbar-idr-sdwan-port-safi, especially the hallway discussions with Ali Sajassi, John Drake, Keyur Patel and Sue Hares on other possible encoding options. I put together an analysis of multiple BGP UPDATE encoding options to achieve SDWAN WAN port properties propagation among SDWAN edges. Please see the slides in the IDR WIKI page: https://trac.ietf.org/trac/idr/attachment/wiki/WikiStart/

The Goal is for WAN Ports Property Propagation across SDWAN nodes in different domains
[cid:image005.png@01D551EE.1F4A7FA0]


The constraints are those SDWAN edges can be spread across different geographical locations, their connection to RR can be over untrusted networks, and they might not know the reachable addresses for the peers they need to communicate (therefore needing RR to propagate).

There are many ways to skin the cat... different encoding for BGP Update Messages

Option 1: Extending Tunnel-Encap with existing IP's SAFI to achieve WAN port registration.
[cid:image007.png@01D551EE.1F4A7FA0]

*       Pros:
-      no new SAFI introduced, the update messages can traverse existing routers
*       Cons:
-      Same IPv4/IPv6 SAFI NLRI carries the WAN port information that is very different from clients' routes attached to the C-PEs.
-     The receivers (RR) has to do extra processing to differentiate the UPDATE messages  from the attached routes UPDATE messages.

Option 2: Tunnel-Encap with SDWAN NLRI for SDWAN WAN Ports Prosperities & Policies described by draft-dunbar-idr-sdwan-port-safi-02
[cid:image009.png@01D551EE.1F4A7FA0]

*       Pros:
-      Clean design and processing on the receivers (RRs). Simpler processing to differentiate the UPDATE messages  from the attached routes UPDATE messages.
*       Cons:
-      New NLRI is introduced, the update messages can't traverse existing routers
*       Since the the Tunnel UPDATE message with the new SDWAN NLRI/SAFI is strictly between SDWAN edge nodes and their respective RR(s) via a secure tunnel, the SDWAN UPDATE messages are not going to traverse existing routers. Therefore, it doesn't cause any issues.

Option 3: Using the new SAFI introduced for BGP labeled Colored Unicast  described by draft-szarecki-idr-bgp-lcu-traffic-steering

[cid:image011.png@01D551EE.1F4A7FA0]

*       Pros:
-      leverage the newly proposed NLRI for carrying Traffic Color across domains
-      Similar goal as SDWAN needing to propagating WAN port properties across domain/geolocations
*       Cons:
-      Need to attach the attributes which haven't been specified by the draft yet.


Need to ask merging the content from draft-dunbar-idr-sdwan-port-safi-02..


We are looking for feedback to those analysis and options.

Thank you very much
Linda Dunbar