Subject: [Idr] draft-dunbar-idr-sdwan-port-safi address the WAN Port property registration that is not covered by Ali's SECURE-EVPN

From: Linda Dunbar <[email-masked]>
Date: Tue, 26 Mar 2019 22:31:55 +0000

Ali,

After my presentation of draft-dunbar-idr-sdwan-port-safi, you stated at the microphone that your draft-sajassi-bess-secure-evpn-01 can cover what is presented.

Your draft-sajassi-bess-secure-evpn-01 doesn't cover the following important features for SD-WAN:

Since SDWAN edge nodes (virtual or physical) deployment at a specific location can be ephemeral, Zero Touch Provisioning (ZTP) is a common requirement, which includes SDWAN node registering the properties of its WAN ports facing the public internet to its controller upon power up, whereas PE's WAN ports are pre-configured. A SD-WAN node can have multiple WAN ports, some egress to a private network through which traffic can traverse natively without encryption, and some ports egress to public network through which traffic has to be encrypted. Client's routes can egress to either WAN ports facing private network or WAN ports facing the public internet depending on the client specified policy and the feedback from the WAN traffic monitoring functions.

draft-dunbar-idr-sdwan-port-safi, is for advertising the properties of a SDWAN edge node WAN ports that face untrusted networks, such as the public internet. Those WAN ports 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 sent over those SDWAN WAN ports might need to be encrypted (depending on the user policies) or need to go through NAT. The newly proposed NLRI is for this purpose.

Best Regards,

Linda

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 27 Mar 2019 00:14:19 +0100

Hi Linda,

> Your draft-sajassi-bess-secure-evpn-01 doesn’t cover the following
important features for SD-WAN

Please observe that while you may be correct in the observation made below
your proposal is realistically also nowhere near to what SDWAN needs to
truly operate.

Just think about SLA probing (both triggering path selection based on
dynamically signaled parameters by controller as well as reporting the
results to controller, think about managing the endpoints, doing upgrades,
performing endpoint debugging, think about OAM required for overlay and
underlay probing from each end point etc ... ) do you think all of this
really belongs in BGP ?

See any decent SDWAN deployment to succeed is way much more complex then
discovering endpoints and setting IPSec between them.

Now please also think what happens if you discover unauthorized/spoof
endpoints ....

Kind regards,
R.

On Tue, Mar 26, 2019 at 11:32 PM Linda Dunbar <[email-masked]>
wrote:

>
>
> Ali,
>
>
>
> After my presentation of draft-dunbar-idr-sdwan-port-safi, you stated at
> the microphone that your draft-sajassi-bess-secure-evpn-01 can cover what
> is presented.
>
>
>
> Your draft-sajassi-bess-secure-evpn-01 doesn’t cover the following
> important features for SD-WAN:
>
>
>
> Since SDWAN edge nodes (virtual or physical) deployment at a specific
> location can be ephemeral, Zero Touch Provisioning (ZTP) is a common
> requirement, which includes SDWAN node registering the properties of its
> WAN ports facing the public internet to its controller upon power up,
> whereas PE’s WAN ports are pre-configured. A SD-WAN node can have multiple
> WAN ports, some egress to a private network through which traffic can
> traverse natively without encryption, and some ports egress to public
> network through which traffic has to be encrypted. Client’s routes can
> egress to either WAN ports facing private network or WAN ports facing the
> public internet depending on the client specified policy and the feedback
> from the WAN traffic monitoring functions.
>
>
>
> draft-dunbar-idr-sdwan-port-safi, is for advertising the properties of a
> SDWAN edge node WAN ports that face untrusted networks, such as the public
> internet. Those WAN ports 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
> sent over those SDWAN WAN ports might need to be encrypted (depending on
> the user policies) or need to go through NAT. The newly proposed NLRI is
> for this purpose.
>
>
>
> Best Regards,
>
>
>
> Linda
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 27 Mar 2019 12:46:19 +0000

Robert,

You are absolutely correct that there are much more aspects of SD-WAN, such as SLA probing, intelligent path selection (via different egress ports) based on the monitoring functions over entire network, etc. We don’t think those features belong to BGP.  I was asked to restrict the discussion to IDR specific.

Some of what you mentioned have been documented the Problem Statement & Gap Analysis for SD-WAN Overlay. We welcome your comments and contributions. Unauthorized/spoof endpoints is also discussed in those drafts.
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/
SD-WAN operational capabilities and requirements have been studied in other operator forums (ONUG) and RTGWG.
Glad to discuss these topics privately or on the RTGWG forum

Using BGP for the WAN port property registration is only a small portion of SDWAN.  draft-dunbar-idr-sdwan-port-safi proposes a new NLRI  for this purpose because of the following reasons:

1)      BGP-LS + EVPN is putting lots of information into specific NLRI (AFI/SAFI) pair for a target audience,

So discussion load on BGP protocol in general is the topic for another general thread,

2)      SD-WAN NRLI will be a targeted (AFI/SAFI) pair so it is assumed that communities will provide policy to limit distribution,

Thank you very much for the comments.

Linda.

From: Robert Raszuk [mailto:[email-masked]]
Sent: Wednesday, March 27, 2019 12:14 AM
To: Linda Dunbar <[email-masked]>
Cc: Ali Sajassi (sajassi) <[email-masked]>; idr wg <[email-masked]>
Subject: Re: [Idr] draft-dunbar-idr-sdwan-port-safi address the WAN Port property registration that is not covered by Ali's SECURE-EVPN

Hi Linda,

> Your draft-sajassi-bess-secure-evpn-01 doesn’t cover the following important features for SD-WAN

Please observe that while you may be correct in the observation made below your proposal is realistically also nowhere near to what SDWAN needs to truly operate.

Just think about SLA probing (both triggering path selection based on dynamically signaled parameters by controller as well as reporting the results to controller, think about managing the endpoints, doing upgrades, performing endpoint debugging, think about OAM required for overlay and underlay probing from each end point etc ... ) do you think all of this really belongs in BGP ?

See any decent SDWAN deployment to succeed is way much more complex then discovering endpoints and setting IPSec between them.

Now please also think what happens if you discover unauthorized/spoof endpoints ....

Kind regards,
R.

On Tue, Mar 26, 2019 at 11:32 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Ali,

Your draft-sajassi-bess-secure-evpn-01 doesn’t cover the following important features for SD-WAN:

Since SDWAN edge nodes (virtual or physical) deployment at a specific location can be ephemeral, Zero Touch Provisioning (ZTP) is a common requirement, which includes SDWAN node registering the properties of its WAN ports facing the public internet to its controller upon power up, whereas PE’s WAN ports are pre-configured. A SD-WAN node can have multiple WAN ports, some egress to a private network through which traffic can traverse natively without encryption, and some ports egress to public network through which traffic has to be encrypted. Client’s routes can egress to either WAN ports facing private network or WAN ports facing the public internet depending on the client specified policy and the feedback from the WAN traffic monitoring functions.

Best Regards,

Linda
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 27 Mar 2019 20:42:30 +0000

Linda, thx for the email and I also wanted to comment in the IDR meeting, but we did not have the time, so hence my email.
Here is my feedback. You are proposing to introduce a new AFI/SAFI in BGP to indicate:

  *   Port IP address, info
  *   IPSEC required or not per link
  *   NAT traversal

Port info you don’t need in a routing protocol and you already have NH which is actually your port IP, so in my view this extension  is not required. More augmented info you can get from Netconf/GNMI/etc
IPSEC required on a link or not, you can use the encap attribute RFC5512/new proposal which is getting to RFC in IDR for that.
NAT traversal is something we need to extend probably, but I believe it is better to extend BGP EVPN and/or IP-VPN for this as most machinery in SD-WAN would use either EVPN or IP-VPN.

From: Idr <[email-masked]> on behalf of Linda Dunbar <[email-masked]>
Date: Wednesday, 27 March 2019 at 13:46
To: Robert Raszuk <[email-masked]>
Cc: IDR <[email-masked]>
Subject: Re: [Idr] draft-dunbar-idr-sdwan-port-safi address the WAN Port property registration that is not covered by Ali's SECURE-EVPN

Robert,

  1.  BGP-LS + EVPN is putting lots of information into specific NLRI (AFI/SAFI) pair for a target audience,

  1.  SD-WAN NRLI will be a targeted (AFI/SAFI) pair so it is assumed that communities will provide policy to limit distribution,

Linda.

Hi Linda,

Kind regards,
R.

Ali,

Best Regards,

Linda