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]>]

Hi Linda,

I think you may be not reading section 7 quite correctly. Packet P is forwarded by R1 to R2. Both updates U1 and U2 are sent by R2 to R1. What section 7 says is that there is no need for both of these updates to carry the Tunnel Encap attribute. In this example U1 doesn’t carry the attribute and the BGP NH of U1 is sent in U2 with the attribute. The recursive route resolution takes care of the tunnel attribute for U1 because U1 recurses to U2 and U2 has the attribute. As I mentioned earlier there are several different ways specified in [Tunnel-Encap] for not sending the attribute with every routes and they are:

  1.  Recursive resolution
  2.  Coloring
  3.  Local policy

With respect to the example you provided, instead of writing a lengthy email on that here, let me add a section to my document to explain how this scenario is taken care of by the tunnel-encap attribute.

Cheers
Ali



From: Linda Dunbar <[e-mail]>
Date: Friday, June 28, 2019 at 9:57 AM
To: Cisco Employee <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: 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,

Thank you very much for the comments. A few more questions on your suggestions.

You said
“The Tunnel-Encap attribute does NOT need to be sent along with each tenant’s route”.

Then what will be the “route” in the UPDATE message?
Per RFC4271, An UPDATE message is used to advertise feasible routes that share common path attributes to a peer.

You stated in another email using  [Tunnel-encap] “recursive resolution and coloring” to propagate the WAN ports properties to RR (Controller). The Section 7 of Tunnel-encap Recursive Next Hop Resolution is about how R2 advertises route “P” on behalf of R1 which doesn’t support Encapsulation, or allowing nested tunnels:

[cid:image003.png@01D52DA8.A2765F80]


Can you elaborate how to  [Tunnel-encap] “recursive resolution and coloring” to propagate the WAN ports properties to RR (Controller)?

For SDWAN scenario (Figure below), the C-PE-1 needs to do two separate actions:

  1.  advertise to the SDWAN Ctrl on this WAN port A1 & A2 properties: A1 is assigned with private address, and A2 is connected to MPLS (e.g. AWS Direct Connect port)



  1.  Advertise the client routes attached to C-PE-1 to SDWAN Ctrl.



[cid:image004.png@01D52DA8.A2765F80]

I re-read the Section 7 (suggested by your other email), but still can’t figure out. Any help would be greatly appreciated.

Thank you very much.

Linda
From: Ali Sajassi (sajassi) <[e-mail]>
Sent: Friday, June 28, 2019 2:00 AM
To: Linda Dunbar <[e-mail]>; [e-mail]
Subject: 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


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]<mailto:[e-mail]>> on behalf of Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Date: Thursday, June 27, 2019 at 4:34 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-idr-sdwan-port-safi%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C8b44503c6fe840dcf4c508d6fb964ed0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636973020328257074&sdata=xe6HeEhhFo4VYyMrMEX2KMOpIOyMd8Vpa9dDNS%2BgqN4%3D&reserved=0>

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