Subject: [bess] Any protocols suitable for Application Flow Based Segmentation in draft-bess-bgp-sdwan-usage-3?

From: Linda Dunbar <[email-masked]>
Date: Mon, 4 Nov 2019 22:39:29 +0000

In MEF SD-WAN Service Specification WG, there has been a lot of discussion on Application Flow Based Segmentation.
Application Flow based Segmentation refers to separating traffic based on business and security needs, e.g. having different topology for different traffic types or users/apps.
For example, retail business requires traffic from payment applications in all branches only go to the Payment Gateway in its HQ Data Centers, whereas other applications can be multi-point (in Cloud DC too).
Segmentation is a feature that can be provided or enabled for a single SDWAN service (or domain). Each Segment can have its own policy and topology.
In the figure below, the traffic from the Payment application (Red Dotted line) is along the Tree topology, whereas other traffic can be multipoint to multi point topology as in VRF.

Segmentation is analogous to VLAN (in L2 network) and VRF (in L3 network). But unlike VRF where all the intermediate nodes can forward per VRF, in SDWAN Overlay, the multipoint to multipoint WAN is an overlay network. If using IPsec Point to Point tunnel, there would be N*(N-1) tunnels, which is too many to many.

Does anyone know an existing protocol that can handle the above scenario described in https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/

Thank you very much.

Linda Dunbar

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 5 Nov 2019 01:53:45 +0100

Hi Linda,

> Overlay, the multipoint to multipoint WAN is an overlay network. If using
IPsec
> Point to Point tunnel, there would be N*(N-1) tunnels, which is too many
to many.

Please observe that any to any encapsulated paths setup in good SDWAN is
day one requirement. And that is not only any src/dst to any src/dst. It is
actually from any source interface over any available underlay to any
available remote interface of the destination.

Imagine if you have two end points each with three interfaces to the
underlay. So number of overlay pipes to be created in corresponding
SDWAN data planes is 9 in each direction just over those *two* end points.
18 if you consider bidirectional traffic.

Good SDWAN can build such state and not only that .. it can also run in
continued fashion SLA probes over all possible paths between given src and
destination. When data is sent over selected per application path it is
then encrypted. It can even do much more ... it can perform
SDWAN-TE treating some endpoints as transits :).

It has been deployed and is fully operating with no concern of scalability
for number of years at least from one vendor I am aware of. So I question
your observation and do believe that adding vrf based routing over well
designed and correctly written SDWAN is of any scalability concern. As a
matter of fact the implementation I am familiar with also has built in
concept of VRFs too.

No it is not trivial - but clearly possible.

Best,
Robert.

On Mon, Nov 4, 2019 at 11:39 PM Linda Dunbar <[email-masked]> wrote:

> Application Flow based Segmentation refers to separating traffic based on
> business and security needs, e.g. having different topology for different
> traffic types or users/apps.
> For example, retail business requires traffic from payment applications in
> all branches only go to the Payment Gateway in its HQ Data Centers, whereas
> other applications can be multi-point (in Cloud DC too).
> Segmentation is a feature that can be provided or enabled for a single
> SDWAN service (or domain). Each Segment can have its own policy and
> topology.
> In the figure below, the traffic from the Payment application (Red Dotted
> line) is along the Tree topology, whereas other traffic can be multipoint
> to multi point topology as in VRF.
>
>
>
> Segmentation is analogous to VLAN (in L2 network) and VRF (in L3 network).
> But unlike VRF where all the intermediate nodes can forward per VRF, in
> SDWAN Overlay, the multipoint to multipoint WAN is an overlay network. If
> using IPsec Point to Point tunnel, there would be N*(N-1) tunnels, which is
> too many to many.
>
> Does anyone know an existing protocol that can handle the above scenario
> described in
> *https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/*
> <https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/>
>
>
> Thank you very much.
>
> Linda Dunbar
>
>
>
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 5 Nov 2019 20:20:09 +0000

Robert,

You said “It has been deployed and is fully operating with no concern of scalability for number of years at least from one vendor I am aware of.”

How many nodes of this deployment?

As you described: just two nodes might need 18 IPsec tunnels. How about 100 node SDWAN network? 100*99 * 18?

“So number of overlay pipes to be created in corresponding SDWAN data planes is 9 in each direction just over those *two* end points. 18 if you consider bidirectional traffic”

Linda

From: Robert Raszuk <[email-masked]>
Sent: Monday, November 04, 2019 6:54 PM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]
Subject: Re: [bess] Any protocols suitable for Application Flow Based Segmentation in draft-bess-bgp-sdwan-usage-3?

Hi Linda,

> Overlay, the multipoint to multipoint WAN is an overlay network. If using IPsec
> Point to Point tunnel, there would be N*(N-1) tunnels, which is too many to many.

Please observe that any to any encapsulated paths setup in good SDWAN is day one requirement. And that is not only any src/dst to any src/dst. It is actually from any source interface over any available underlay to any available remote interface of the destination.

Imagine if you have two end points each with three interfaces to the underlay. So number of overlay pipes to be created in corresponding SDWAN data planes is 9 in each direction just over those *two* end points. 18 if you consider bidirectional traffic.

Good SDWAN can build such state and not only that .. it can also run in continued fashion SLA probes over all possible paths between given src and destination. When data is sent over selected per application path it is then encrypted. It can even do much more ... it can perform SDWAN-TE treating some endpoints as transits :).

It has been deployed and is fully operating with no concern of scalability for number of years at least from one vendor I am aware of. So I question your observation and do believe that adding vrf based routing over well designed and correctly written SDWAN is of any scalability concern. As a matter of fact the implementation I am familiar with also has built in concept of VRFs too.

Best,
Robert.

On Mon, Nov 4, 2019 at 11:39 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Does anyone know an existing protocol that can handle the above scenario described in https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-bess-bgp-sdwan-usage%2F&data=02%7C01%7Cldunbar%40futurewei.com%7C3b3333f3d3284c07ad6908d7618aa34a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637085120416218921&sdata=deTxi%2FNkX678x8qEX4hCipAcf%2ByosvtUu%2Fu2iA5aFRA%3D&reserved=0>

Thank you very much.

Linda Dunbar

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=02%7C01%7Cldunbar%40futurewei.com%7C3b3333f3d3284c07ad6908d7618aa34a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637085120416228917&sdata=ELZ8iXkQd2Jocc4wVYZ6ps%2FAbBLIjeneD5vmLf%2FRdxk%3D&reserved=0>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 5 Nov 2019 22:15:14 +0100

Linda,

The key message here is that in properly designed SDWAN your limit is
capped by volume of data traffic required to be encrypted and supported by
your platform. Number of overlay adjacencies does not matter.

It does not matter since the size of your FIB has orders of magnitude more
capacity then any single SDWAN number of endpoints.

Best,
R,

On Tue, Nov 5, 2019 at 9:20 PM Linda Dunbar <[email-masked]> wrote:

> Robert,
>
>
>
> You said “It has been deployed and is fully operating with no concern of
> scalability for number of years at least from one vendor I am aware of.”
>
>
>
> “So number of overlay pipes to be created in corresponding SDWAN data
> planes is 9 in each direction just over those *two* end points. 18 if you
> consider bidirectional traffic”
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Monday, November 04, 2019 6:54 PM
> *To:* Linda Dunbar <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [bess] Any protocols suitable for Application Flow Based
> Segmentation in draft-bess-bgp-sdwan-usage-3?
>
>
>
> Hi Linda,
>
>
>
> https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-bess-bgp-sdwan-usage%2F&data=02%7C01%7Cldunbar%40futurewei.com%7C3b3333f3d3284c07ad6908d7618aa34a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637085120416218921&sdata=deTxi%2FNkX678x8qEX4hCipAcf%2ByosvtUu%2Fu2iA5aFRA%3D&reserved=0>
>
>
>
>
>
> Thank you very much.
>
>
>
> Linda Dunbar
>
>
>
>
>
>
>
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=02%7C01%7Cldunbar%40futurewei.com%7C3b3333f3d3284c07ad6908d7618aa34a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637085120416228917&sdata=ELZ8iXkQd2Jocc4wVYZ6ps%2FAbBLIjeneD5vmLf%2FRdxk%3D&reserved=0>
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 5 Nov 2019 22:07:57 +0000

Robert,

It is not the FIB size, but the number of IPsec SA maintenance required at each edge node that makes it difficult to scale more than 100 nodes.
Each IPsec SA requires periodical key refreshment. For one node maintaining X number of IPsec SA, it is tremendous amount of work.

Linda

From: Robert Raszuk <[email-masked]>
Sent: Tuesday, November 05, 2019 3:15 PM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]
Subject: Re: [bess] Any protocols suitable for Application Flow Based Segmentation in draft-bess-bgp-sdwan-usage-3?

Linda,

The key message here is that in properly designed SDWAN your limit is capped by volume of data traffic required to be encrypted and supported by your platform. Number of overlay adjacencies does not matter.

It does not matter since the size of your FIB has orders of magnitude more capacity then any single SDWAN number of endpoints.

Best,
R,

On Tue, Nov 5, 2019 at 9:20 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Linda

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Monday, November 04, 2019 6:54 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] Any protocols suitable for Application Flow Based Segmentation in draft-bess-bgp-sdwan-usage-3?

Hi Linda,

Best,
Robert.

Does anyone know an existing protocol that can handle the above scenario described in https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-bess-bgp-sdwan-usage%2F&data=02%7C01%7Cldunbar%40futurewei.com%7C0122616e8155496367d708d762354640%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637085853266243839&sdata=jo6WEei6clyY04voV97hfw76CbJjJZJNO4t3YFesI2w%3D&reserved=0>

Thank you very much.

Linda Dunbar

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=02%7C01%7Cldunbar%40futurewei.com%7C0122616e8155496367d708d762354640%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637085853266243839&sdata=trin1bRzUoN4q95fs7vH%2FyjeMo9n7zI9DVUKCJUt2PY%3D&reserved=0>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Nov 2019 00:21:29 +0100

> it is tremendous amount of work.

Well I am afraid this is entering implementation space and not subject to
any further debate on or off the list. Only note that IPSec is not the only
payload encryption option at your disposal for quality SDWANs.

On Tue, Nov 5, 2019 at 11:07 PM Linda Dunbar <[email-masked]> wrote:

> Robert,
>
>
>
> It is not the FIB size, but the number of IPsec SA maintenance required at
> each edge node that makes it difficult to scale more than 100 nodes.
>
> Each IPsec SA requires periodical key refreshment. For one node
> maintaining X number of IPsec SA, it is tremendous amount of work.
>
>
>
> Linda
>
>
>
> *Sent:* Tuesday, November 05, 2019 3:15 PM
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-bess-bgp-sdwan-usage%2F&data=02%7C01%7Cldunbar%40futurewei.com%7C0122616e8155496367d708d762354640%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637085853266243839&sdata=jo6WEei6clyY04voV97hfw76CbJjJZJNO4t3YFesI2w%3D&reserved=0>
>
>
>
>
>
> Thank you very much.
>
>
>
> Linda Dunbar
>
>
>
>
>
>
>
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=02%7C01%7Cldunbar%40futurewei.com%7C0122616e8155496367d708d762354640%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637085853266243839&sdata=trin1bRzUoN4q95fs7vH%2FyjeMo9n7zI9DVUKCJUt2PY%3D&reserved=0>
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 5 Nov 2019 23:50:51 +0000

Robert,

Without getting into any implementation, are there any terrible problems of allowing IPsec tunnel as transport segment and each edge node forward packets destined to other nodes, as done by VRF. What issues do you see? (other than it is not IPsec tunnel per client interface/group)?

Thanks, Linda

From: Robert Raszuk <[email-masked]>
Sent: Tuesday, November 05, 2019 5:21 PM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]
Subject: Re: [bess] Any protocols suitable for Application Flow Based Segmentation in draft-bess-bgp-sdwan-usage-3?

> it is tremendous amount of work.

Well I am afraid this is entering implementation space and not subject to any further debate on or off the list. Only note that IPSec is not the only payload encryption option at your disposal for quality SDWANs.

On Tue, Nov 5, 2019 at 11:07 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Linda

Linda,

Best,
R,

Linda

Hi Linda,

Best,
Robert.

Does anyone know an existing protocol that can handle the above scenario described in https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-bess-bgp-sdwan-usage%2F&data=02%7C01%7Cldunbar%40futurewei.com%7C1a8c6ef5c497471433d108d76246e99d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637085929036137526&sdata=yNCeZ6BHR%2BDhlG18PQdjuABUeTzmjdpjDXbQpUYF8jE%3D&reserved=0>

Thank you very much.

Linda Dunbar

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=02%7C01%7Cldunbar%40futurewei.com%7C1a8c6ef5c497471433d108d76246e99d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637085929036137526&sdata=0kqN0jefS4%2FftqPrRmmSZDwl6LFYVOPQrTAmsMPEuJ8%3D&reserved=0>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 12 Nov 2019 18:39:10 -0500

Sorry to talk implementation on or off list but from a pure net-net vpn VTI tunnel mode perspective using DMVPN that scales pretty well to 100’s of user sites homing to a pair of mGRE DMVPN head ends which I have deployed.  I have not done any with over a 1000 on a pair but that’s a lot even for any mpls deployments I have worked with.  The IPSEC SA is all done with hardware encryption and so the scaling is very high for most all vendors the maximum number of IPSEC tunnels that can be hit.

I would say a similar analogy would be that most SP routers support 1M+ FIB entires per customer VRF on average per vendor which is way high and its rare that you have an L3 VPN that exceeds 1M routes.  These days the hardware far exceeds the possible use cases.

Gyan

Sent from my iPhone

> On Nov 5, 2019, at 6:50 PM, Linda Dunbar <[email-masked]> wrote:
> 
> Robert,
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 14 Nov 2019 11:47:36 +0000

Gyan,

Thank you very much for providing the examples. Yes, DMVPN or DSVPN has been used for SD-WAN. We used them too for network less than 100 nodes.
For routers that already have BGP protocol stack, it is easier to leverage the BGP UPDATE to propagate the information.

draft-bess-bgp-sdwan-usage is an informational draft showing how BGP is used for some SDWAN Scenarios. The purpose of the draft is to show to the industry IETF’s protocols work well. (p.s. DMVPN or DSVPN is not IETF standard, they both use vendors extended version of NHRP). Hope to discuss with you more.

For example,

Looking for more comments,

Linda

From: Gyan Mishra <[email-masked]>
Sent: Wednesday, November 13, 2019 7:39 AM
To: Linda Dunbar <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; [email-masked]
Subject: Re: [bess] Any protocols suitable for Application Flow Based Segmentation in draft-bess-bgp-sdwan-usage-3?

Gyan
Sent from my iPhone

On Nov 5, 2019, at 6:50 PM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Thanks, Linda

Linda

Linda,

Best,
R,

Linda

Hi Linda,

Best,
Robert.

Does anyone know an existing protocol that can handle the above scenario described in https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-bess-bgp-sdwan-usage%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ce6f240b5eb394c85e7d408d767c987a1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637091987588944891&sdata=M%2BhKQZ8H%2FNy09J20NUHBVZS3SpesHqljBvmyjKwYl1o%3D&reserved=0>

Thank you very much.

Linda Dunbar

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ce6f240b5eb394c85e7d408d767c987a1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637091987588944891&sdata=WxuxnuPEFnLT8hunSPvBs7CtHdU17Y0vs0svAG%2Fe6S0%3D&reserved=0>
_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ce6f240b5eb394c85e7d408d767c987a1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637091987588954845&sdata=PSv7iiZCUHa2fufnVyKGcHYnXEfoCdOA2gOv%2Fs2t60k%3D&reserved=0>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 16 Nov 2019 02:12:56 -0500

Linda 

So with this new SDWAN architecture it would eliminate the need for DMVPN NHRP based proprietary VTI tunnel mode architecture or any IPSEC hub/spoke architecture and all would be done via an SDWAN controller that does the discovery and builds the bgp session from all the SDWAN endpoints to the RR controller and all the tunnels are ZTP provisioned and comes up.

Does this solution use BGP AD? similar to what is used for MVPN EVPN VPLS etc.

Since you still have to maintain all the IPSEC IKEv2 SAs what makes this solution with BGP scale better then traditional IPSEC hub/spoke overlay with SDWAN MP-MP overlay.

Gyan

Sent from my iPhone

> On Nov 14, 2019, at 6:47 AM, Linda Dunbar <[email-masked]> wrote:
> 
> Gyan,
>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 19 Nov 2019 08:22:21 +0000

Gyan,

Traditional IPsec is point to point. Each node has to be configured with remote subnets on the remote node as well as the certificate.
For SDWAN Zero Touch Provisioning, each node doesn’t know who is authorized to communicate with him.

By leveraging BGP UPDATE sending to its RR, RR can use the policy and certificate management stored in RR to propagate to a set of CPEs that are authorized to communicate with the node. Each node doesn’t need to worry about the remote nodes’ certificate, doesn’t need to validate who can communicate with him. Each node only to send out its public key and authentication methods (AH or ESP).

As the result, the number of messages to maintain IPsec key among a group of nodes is much less.

For example,

Linda

Sent: Saturday, November 16, 2019 3:13 PM

Linda

Gyan

Sent from my iPhone

On Nov 14, 2019, at 6:47 AM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Gyan,

For example,

Linda

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 13, 2019 7:39 AM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] Any protocols suitable for Application Flow Based Segmentation in draft-bess-bgp-sdwan-usage-3?

Gyan
Sent from my iPhone

Thanks, Linda

Linda

Linda,

Best,
R,

Linda

Hi Linda,

Best,
Robert.

Does anyone know an existing protocol that can handle the above scenario described in https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-bess-bgp-sdwan-usage%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C022850a8ffda45860a4f08d76a646953%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637094851824206965&sdata=A7qW7pAg6Y%2BSluT85Dk6Af4i4dU0aQ0jiTgr5oFT5SE%3D&reserved=0>

Thank you very much.

Linda Dunbar

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C022850a8ffda45860a4f08d76a646953%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637094851824216963&sdata=JQPbwJY6yTThKbNS9oXlMXyh883s45Hqfthu7YpbyiA%3D&reserved=0>
_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C022850a8ffda45860a4f08d76a646953%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637094851824216963&sdata=JQPbwJY6yTThKbNS9oXlMXyh883s45Hqfthu7YpbyiA%3D&reserved=0>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 19 Nov 2019 20:38:11 -0500

Hi Linda 

After reading this document I realized this is an informational draft although very technical with details packet walk.

Is there a new IANA AFI/SAFI assigned to this new bgp capability for provisioning SD WAN endpoints.

Also is there an RFC that describes this BGP SDWAN new capability.

I need to read that document before reading this draft to help connect the dots on how this is going to work.

Thank you 

Gyan

Sent from my iPhone

> On Nov 19, 2019, at 3:22 AM, Linda Dunbar <[email-masked]> wrote:
> 
> Gyan,
>