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

[Linda Dunbar <[e-mail]>]

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 <[e-mail]>
Sent: Monday, November 04, 2019 6:54 PM
To: Linda Dunbar <[e-mail]>
Cc: [e-mail]
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.

No it is not trivial - but clearly possible.

Best,
Robert.


On Mon, Nov 4, 2019 at 11:39 PM Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:
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.

[cid:image001.jpg@01D593E4.1FC92480]


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://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
[e-mail]<mailto:[e-mail]>
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>