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 <robert@raszuk.net> Tue, 13 August 2019 08:16 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D5C120112 for <idr@ietfa.amsl.com>; Tue, 13 Aug 2019 01:16:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyVxxglEQTBz for <idr@ietfa.amsl.com>; Tue, 13 Aug 2019 01:16:26 -0700 (PDT)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD2B120127 for <idr@ietf.org>; Tue, 13 Aug 2019 01:16:26 -0700 (PDT)
Received: by mail-qt1-x829.google.com with SMTP id x4so7490854qts.5 for <idr@ietf.org>; Tue, 13 Aug 2019 01:16:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eR1nICcLsb1gO2tJZjbfAX5+Gs3YqrDtAUOSRRysqVk=; b=ad850n+WxUZpB7oMMZXbu+ANHpX4rGskaP/xGcb62dQ1r0iQMlh3nnSqEJETNhMN6r 9dNj9IujEr6m8XFE/wwMLhsPzSnn2Qsd6QAmWy0bpmDUtcJAL06bfdnDtEisZY4H2JM8 NlC/v/b93pVjcVkY1l1C330tndyymir8GLT1QTCjYazY2F3WNQxeokFjpMaLE0DOBs6t B3cvc8Df3D1ito7edilYQLY7FsaemNhxkzzzV/Ovw7t7SC7wbKvOLIBjjTcyElDvbK0+ VcPB7r2lM3qgLgc23XKguFlE52kt8plJaWogmsv1nTYZsYq7WZ9uDTJ+h1Q0dIHyvOrv t4iA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eR1nICcLsb1gO2tJZjbfAX5+Gs3YqrDtAUOSRRysqVk=; b=Ibh6H1lA0w3b6sXpwXfrTUmX8y3zXRErNUhcekCjWfUgYZa/26lA23QIV9j/o5GnPH rE2zlxXptSmU4GLriFWlEDt9xjFJSRDgunnApMtktUrPsKbevhFL8IB4WtNhVPevSNaR oiTjYC3XQX+BoG6HjSGn1Yxyz695m0tF053+6ZiQS9lV7QDurefeZIavAVJj2lFayG82 3NsHBDY5oH/sDe9JHIR7Fr8/UmsmmEdG15oRSZVmHPxS/uWIIrlRWxg7ATwkDR6hoIek aZdruyEzmLQaZlrAFWQSdoXY1EqYy0UQqac9Kdw2crlzJiTEP23pnRZnt2qBV3Ehk5rG 2DMw==
X-Gm-Message-State: APjAAAWDqh8p/MoOcXwwIBM+hJFSOUogh9NtN1piqFLt9r6HVe2IXUxd ES8MVCAUdNzhV7YHqD4Rhw/3mTQrsO0WVdEf9EYfL1gA
X-Google-Smtp-Source: APXvYqyC41ylK7F795sdDSpXJ2y8GzH4EddZ7CqyqfiAIIVRKtAtPW5xG9aay/8p9bjDC38fnAabvEF1UUHtYBXrWoQ=
X-Received: by 2002:ac8:34ea:: with SMTP id x39mr3520447qtb.311.1565684184816; Tue, 13 Aug 2019 01:16:24 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR13MB35824E1E96BE08CDCBE8488585D30@MN2PR13MB3582.namprd13.prod.outlook.com>
In-Reply-To: <MN2PR13MB35824E1E96BE08CDCBE8488585D30@MN2PR13MB3582.namprd13.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 13 Aug 2019 10:16:13 +0200
Message-ID: <CAOj+MMEgkHL12kE87SVaUEJ+9Xeob=gU5Z=sKX+isQ=x0PtA-A@mail.gmail.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/related; boundary="000000000000ab8084058ffb410b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/oUaNhJ8Zv2rBbX_vLwBAL2AGMcc>
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)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Aug 2019 08:16:36 -0000

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 <linda.dunbar@futurewei.com>
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/
>
>
>
> 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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>