Re: [Idr] soliciting feedback for draft-dunbar-idr-sdwan-port-safi, which specifies a new NLRI for SDWAN edge to advertise its WAN ports properties

["Ali Sajassi (sajassi)" <[e-mail]>]

Linda,

After the long thread we had on the topic of Tunnel-Encap, it should hopefully be clear by now that tunnel-encap can be used for your “WAN ports” and the property associated with a tunnel for these WAN ports can be signaled via the attribute. The Tunnel-Encap attribute does NOT need to be sent along with each tenant’s route and the [Tunnel-Encap] specified two way to do that: 1) recursive resolution and 2) coloring.  Furthermore, [Tunnel-Encap] allows you to setup multiple tunnels to a given end-point by advertising a single route along with the attribute for these tunnels. [Tunnel-Encap] does a nice job in providing examples for all of these.

Cheers,
Ali

From: Idr <[e-mail]> on behalf of Linda Dunbar <[e-mail]>
Date: Thursday, June 27, 2019 at 4:34 PM
To: "[e-mail]" <[e-mail]>
Subject: [Idr] soliciting feedback for draft-dunbar-idr-sdwan-port-safi, which specifies a new NLRI for SDWAN edge to advertise its WAN ports properties

IDR Experts:

We would love to hear your feedback, criticism, or suggestion for https://datatracker.ietf.org/doc/draft-dunbar-idr-sdwan-port-safi/

The document specifies a new BGP NLRI and SAFI for advertising WAN ports properties of a SDWAN edge node. SDWAN edge node’s WAN ports may face untrusted networks, such as the public internet, may get assigned IP addresses from the Internet Service Providers (ISPs), may get assigned dynamic IP addresses via DHCP, or may have private addresses (e.g. inside third party Cloud DCs). Packets forwarded through those SDWAN WAN ports might need to be encrypted (depending on the user policies) or need to go through NAT. SDWAN edge nodes need to propagate those WAN ports properties to the peers who are authorized to communicate across different types of underlay networks including the untrusted networks.

Many people have suggested using the SAFI/NLRI used by draft-ietf-idr-tunnel-encaps-12. Here is why Tunnel-Encap is not enough:


  *   Tunnel-Encap draft describes how to construct a BGP UPDATE messages that advertise endpoints’ tunnel encapsulation capability and the respective attached client routes, so that the receivers of the BGP UPDATE can establish appropriate tunnels with the endpoints for the client routes. Tunnel-encap has a “Remote endpoint subTLV” for controller to advertise a node’s encapsulation capabilities.   The receivers of the Tunnel UPDATE would construct the encapsulation header with the Outer Destination Address equal to the address carried in the “Remote Endpoint sub-TLV”..
  *   The Tunnel-Encap draft doesn’t cover the SDWAN Edge WAN ports properties advertisement propagation, especially over untrusted networks.
  *   The addresses advertised by Tunnel-Encap UPDATE are the addresses of client routes reachable via the advertised encapsulation headers. The Address Family for the WAN ports of SDWAN Edge is totally different address family. The goal is to register the WAN port properties to its respective controller. Therefore, it is cleaner, less processing on receivers for implementation, and less error prone to have a different NLRI for WAN ports properties registration than re-using client route NLRI.

Greatly appreciate feedback and criticisms.

Thank you
Linda