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 protected]> wrote: > > 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, > > <image003.png> > > Linda > > From: Gyan Mishra <[email protected]> > Sent: Saturday, November 16, 2019 3:13 PM > To: Linda Dunbar <[email protected]> > Cc: Robert Raszuk <[email protected]>; [email protected] > Subject: Re: [bess] Any protocols suitable for Application Flow Based > Segmentation in draft-bess-bgp-sdwan-usage-3? > > 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 protected]> wrote: > > 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, > > <image001.png> > <image002.png> > > Looking for more comments, > > Linda > > > From: Gyan Mishra <[email protected]> > Sent: Wednesday, November 13, 2019 7:39 AM > To: Linda Dunbar <[email protected]> > Cc: Robert Raszuk <[email protected]>; [email protected] > Subject: Re: [bess] Any protocols suitable for Application Flow Based > Segmentation in draft-bess-bgp-sdwan-usage-3? > > > 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 protected]> wrote: > > 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)? > > <image002.png> > > Thanks, Linda > > From: Robert Raszuk <[email protected]> > Sent: Tuesday, November 05, 2019 5:21 PM > To: Linda Dunbar <[email protected]> > Cc: [email protected] > 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 protected]> 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 > > From: Robert Raszuk <[email protected]> > Sent: Tuesday, November 05, 2019 3:15 PM > To: Linda Dunbar <[email protected]> > Cc: [email protected] > 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 protected]> 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.” > > 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 protected]> > Sent: Monday, November 04, 2019 6:54 PM > To: Linda Dunbar <[email protected]> > Cc: [email protected] > 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 <[email protected]> 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. > > <image001.jpg> > > > 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 > > > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
