Re: [Idr] Solicit feedback to BGP UPDATE encoding options for SDWAN WAN port properties propagation among SDWAN edges (pros & cons to draft-dunbar-idr-sdwan-port-safi and alternatives)

[Robert Raszuk <[e-mail]>]

Hi Linda,

> note: the BGP for SDWAN Edges is running at different layers than the BGP
for underlay networks, i.e. not “FLAT” BGP

So I was under impression that you are to discover the interested SDWAN
peers with this extension - well apparently not if what you are defining is
an overlay BGP.

But then if you have to discover the peers dynamically in some other way
prior to establishing said BGP sessions - why not to add this information
as part of auto discovery mechanism ?

Many thx,
R.






On Tue, Aug 13, 2019 at 8:07 PM Linda Dunbar <[e-mail]>
wrote:

> Robert,
>
>
>
> Thanks for the quick feedback. It is interesting that you mentioned LISP,
> I had “LISP” listed as the 4th option in my first version of the analysis,
> then decided to remove it because the discussion is in IDR group.
> Legitimate question on WHY BGP?
>
>
>
> In addition to looking into your suggested “out of box thinking” that BGP
> carrying some short reference the actual information should be kept outside
> of it in one of the new global databases,  here are some of the Compelling
> reasons of using BGP to distribute SDWAN edge properties among peers that
> might be spread across the globe:
>
> (note: the BGP for SDWAN Edges is running at different layers than the BGP
> for underlay networks, i.e. not “FLAT” BGP. They are among SDWAN edges, not
> for exposing to underlay provider as you stated EBGP. When the underlay
> network service providers use SDWAN to temporarily expand bandwidth in some
> segments, they have more reason to use BGP to minimize amount of learning &
> configuration of introducing new protocols in their environment)
>
>
>
>    - BGP already widely deployed as sole protocol (see RFC 7938). Even if
>       not for this purpose of propagating SDWAN WAN port properties, the BGP base
>       protocol implementation is supported by virtually all switches/routers
>       (virtual & physical).  Even AWS VPC export the BGP routes.
>       - Wide acceptance – minimal learning (which is very important
>       requirement for operations)
>       - Robust and simple implementation,
>       - Reliable transport
>       - Guaranteed in-order delivery
>       - Incremental updates
>       - No flooding and selective filtering
>       - RR already has the capability to apply policies to communications
>       among peers.
>
> Bottom line:  It is much easier to add one function than adding a
> brand-new protocol stack.
>
>
>
> Alternative: extending LISP, NHRP, DSVPN/DMVPN
>
>    - In addition to more proposal changes needed, NHRP/DSVPN/DMVPN don’t
>       scale well.
>       - More learning, more barrier to be deployed, just think how many
>       decades of painful journey deploying IPv6.
>       -
>
> Prior extension of BGP for non-client routes reachability: Flowspec, BGP
> LS, Segment routing policies, etc
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Tuesday, August 13, 2019 3:16 AM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [Idr] Solicit feedback to BGP UPDATE encoding options for
> SDWAN WAN port properties propagation among SDWAN edges (pros & cons to
> draft-dunbar-idr-sdwan-port-safi and alternatives)
>
>
>
> Hi Linda,
>
>
>
> I must up front say that your efforts in this area are very useful ! Thank
> you for this work.
>
>
>
> But in the same time I need to ask why are we so much hostage of BGP and
> attempt to propagate all of this opaque information in BGP ? SDWANs by
> design are to span globe and out of the information you would inject into
> global BGP only tiny fraction (if even that much) would benefit - for rest
> of the users it will be unneeded data.
>
>
>
> My suggestion here is to think outside of the box and while BGP could
> carry some short reference the actual information should be kept outside of
> it in one of the new global databases. See today I operate a global SDWAN
> and it works just fine when my controller is distributed in AWS cloud.
>
>
>
> I would be actually afraid to advertise anything in my EBGP sessions to my
> providers and it may just attract attacks and hackers towards my sides
> without any real value to the sites I am interconnecting.
>
>
>
> So perhaps we should spend this energy on building secure NNI to the
> interface of such public database rather to keep loading more and more
> service info into flat BGP ?
>
>
>
> Many thx,
>
> R.
>
>
>
> PS. Natural question POPs up - what's wrong with using LISP mapping plane
> for it ? Sure some are allergic to LISP just like some were allergic to
> MPLS, but is this really a right reason not to explore full spectrum of
> options ?
>
>
>
> On Tue, Aug 13, 2019 at 12:48 AM Linda Dunbar <[e-mail]>
> wrote:
>
> IDR participants:
>
>
>
> Many thanks to the feedback from IETF105 discussion on
> draft-dunbar-idr-sdwan-port-safi, especially the hallway discussions with
> Ali Sajassi, John Drake, Keyur Patel and Sue Hares on other possible
> encoding options. I put together an analysis of multiple BGP UPDATE
> encoding options to achieve SDWAN WAN port properties propagation among
> SDWAN edges. Please see the slides in the IDR WIKI page:
> https://trac.ietf.org/trac/idr/attachment/wiki/WikiStart/
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fattachment%2Fwiki%2FWikiStart%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C1dcce2de7b98451f28ac08d71fc68923%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637012809899266710&sdata=pOfkTPzzGqHfcukg6Oz5gtcNmFNPnd5D73H76OTEr5E%3D&reserved=0>
>
>
>
> The Goal is for WAN Ports Property Propagation across SDWAN nodes in
> different domains
>
>
>
>
>
> The constraints are those SDWAN edges can be spread across different
> geographical locations, their connection to RR can be over untrusted
> networks, and they might not know the reachable addresses for the peers
> they need to communicate (therefore needing RR to propagate).
>
>
>
> There are many ways to skin the cat… different encoding for BGP Update
> Messages
>
> *Option 1: Extending Tunnel-Encap with existing IP’s SAFI to achieve WAN
> port registration. *
>
>
>
>    - *Pros:*
>
>
>    - no new SAFI introduced, the update messages can traverse existing
>       routers
>
>
>    - *Cons:*
>
>
>    - Same IPv4/IPv6 SAFI NLRI carries the WAN port information that is
>       very different from clients’ routes attached to the C-PEs.
>       - The receivers (RR) has to do extra processing to differentiate
>       the UPDATE messages  from the attached routes UPDATE messages.
>
>
>
> *Option 2: Tunnel-Encap with SDWAN NLRI for SDWAN WAN Ports Prosperities &
> Policies described by draft-dunbar-idr-sdwan-port-safi-02*
>
>
>
>    - *Pros:*
>
>
>    - *Clean design and processing on the receivers (RRs). Simpler *processing
>       to differentiate the UPDATE messages  from the attached routes UPDATE
>       messages.
>
>
>    - *Cons:*
>
>
>    - New NLRI is introduced, the update messages can’t traverse existing
>       routers
>
>
>    - Since the the Tunnel UPDATE message with the new SDWAN NLRI/SAFI is
>          strictly between SDWAN edge nodes and their respective RR(s) via a secure
>          tunnel, the SDWAN UPDATE messages are not going to traverse existing
>          routers. Therefore, it doesn’t cause any issues.
>
>
>
> *Option 3: Using the new SAFI introduced for BGP labeled Colored Unicast
>  described by draft-szarecki-idr-bgp-lcu-traffic-steering*
>
>
>
>
>
>    - *Pros:*
>
>
>    - leverage the newly proposed NLRI for carrying Traffic Color across
>       domains
>       - Similar goal as SDWAN needing to propagating WAN port properties
>       across domain/geolocations
>
>
>    - *Cons:*
>
>
>    - Need to attach the attributes which haven’t been specified by the
>       draft yet.
>
>
>
> Need to ask merging the content from draft-dunbar-idr-sdwan-port-safi-02..
>
>
>
>
>
> We are looking for feedback to those analysis and options.
>
>
>
> Thank you very much
>
> Linda Dunbar
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C1dcce2de7b98451f28ac08d71fc68923%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637012809899266710&sdata=t%2B11tSNemH%2FSteHUL%2FefOgSi1WB8QPfvKxocxbcnkBE%3D&reserved=0>
>
>