Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00

Robert Raszuk <> Sun, 04 November 2018 15:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8AE5D124408 for <>; Sun, 4 Nov 2018 07:36:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Can48ALpeNZN for <>; Sun, 4 Nov 2018 07:36:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0179A130E0F for <>; Sun, 4 Nov 2018 07:35:59 -0800 (PST)
Received: by with SMTP id a132so10877206qkg.1 for <>; Sun, 04 Nov 2018 07:35:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3AOv5LsPdnIziUdz+aJfSGnFFxVM2Dbc9bC+QOT/T1s=; b=B1ibe/crrNpyMmwA8p4hAzzZwsw8Leoogwwha3ul5eqCcOjr1rZeFLS3gmGoUmOz9B PJFyUsGBjZvxFpflgZQZurnQTnRB7hSv54kUmdnlFDUfyvbbIuNB6y/Zl9AhE5QS3R2r pfOIPwblDkBZj/U1mBsKPuG1X/gKvI5ljh0M32EAHOWz1pNVuCy0j2rZ5g4qCsZgML21 J3fKZGUo+q7Mvk0GptGyZBlYWyPtYIMgPh7DuPUOUWoTX6Y6LquK0K9T4AS54H5W0QOd FnIlAGdj/8E3uhAHES8crRlP1q+fKq+eUf5QOute0UD8OY44XN1uvY4xLb4chfDkE1El rrrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3AOv5LsPdnIziUdz+aJfSGnFFxVM2Dbc9bC+QOT/T1s=; b=VzQqD74RQRR3f/pADkS134SdcmlLmX7siK8USgOMQEejM8a2eOr9akkW1a+kcwLKmF nLpR2c8XleL2zk5oZEeQ5Pq9JmafRgSwbVpcePrIOWnRgMz7Kb608HrjIbkYzdOMYvhE um/K7WDzjCA5PHUhb6RbjzPeTSsWHs6ybe8BLWksOqc+trdXXfNVCGIBnl+67lkTjzV2 qbfPqMt9lSyNWpp5B7B/OUEmpfPU2bMbdjN6JnsTBwZ2kGkc861JrdVOKzlVefysYZXh KwXPVxjw1qeCUVcpztJcJe5XVrye0pzNVoKz3XIJO1Nvi/h7IGbbwLDBkVLxuoHE82Jw uMjQ==
X-Gm-Message-State: AGRZ1gKVPzyofUt/DHrsmRKMysmMdv+j4oTlsNG5Za74fkU3p/DtWJcu DkxZAr2hlpRZU3GpicIE/zBZMW3M2h4cpdtS8xDT/BJQIX4=
X-Google-Smtp-Source: AJdET5ew2aJi3ozy69ltszb1tHZLIUxEncXx8roMxfG5nlNV4aoyT6ZpsuRfxFP7yul/5swhffSr+wvANqqPOGrgzCo=
X-Received: by 2002:a0c:e84f:: with SMTP id l15mr17760279qvo.124.1541345759047; Sun, 04 Nov 2018 07:35:59 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Sun, 4 Nov 2018 16:35:47 +0100
Message-ID: <>
To: Linda Dunbar <>
Content-Type: multipart/alternative; boundary="00000000000071cea60579d886ab"
Archived-At: <>
Subject: Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 04 Nov 2018 15:36:04 -0000

Hi Linda,

I have one comment to proposed encoding and one overall observation.

*Comment: *

Proposed "EncapsExt sub-TLV" defines as mandatory indication on NAT type.
Possible values are:  NAT Type.without NAT; 1:1 static NAT; Full Cone;
Restricted Cone; Port Restricted Cone; or Symmetric.

You very nicely listed all nat types except one: "unknown" :) Why - Let's
notice that in the other part of the text you state that information of the
NAT type may be obtained from STUN server "can inquire". So if use of STUN
server is optional then there is possibility that there is none and end
point would not know about the NAT type it is traversing.

*Observation: *

This seems to be yet one more time we see proposal of "let's ride on BGP as
we need to exchange endpoint discovery data point to point in a realiable
way". I see zero need in this proposal why BGP is required here as opposed
to any piece of code which can deliver data between two or more endpoints.

Seeing those proposals it puzzles me a lot why skype or hangout are not
using BGP ... after all video or voice call setup does require exchange of
endpoint data. Likewise another unknown mystery is why SMTP is not riding
on BGP too ?

Yes overall we are missing now pretty much every day a global distributed
system to exchange endpoint data in a dynamic way.

Before we proceed on this or any other similar BGP extension I would highly
appreciate some discussion on why below alternatives or other new similar
proposals can be used instead of BGP for the described applications.

1. LISP mapping plane
2. Products of IDentity Enabled Networks WG
3. DynamicDNS
4. Registry of Data on AWS


On Tue, Oct 30, 2018 at 5:19 PM Linda Dunbar <>

> IDR group, BESS group,
> specifies a new BGP SAFI (=74) in order to advertise a SD-WAN edge node’s
> capabilities in establishing SD-WAN overlay tunnels with other SD-WAN nodes
> through third party untrusted networks.
> draft-sajassi-bess-secure-evpn-00 describes an EVPN solution for PE nodes
> to exchange key and policy to create private pair-wise IPsec Security
> Associations without IKEv2 point-to-point signaling or any other direct
> peer-to-peer session establishment messages.
> I think those two solutions are not conflicting with each other. Actually
> they are compliment to each other to some degree. For example,
> -        the Re-key mechanism described by
> draft-sajassi-bess-secure-evpn-00 can be utilized by
> draft-dunbar-idr-bgp-sdwan-overlay-ext
> -        The SD-WAN Overlay SAFI can be useful to simplify the process on
> RR to re-distribute the Tunnel End properties to authorized peers.
> -        When SD-WAN edge nodes use private address, or no IP address,
> NAT properties for the end points distribution described
> draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.
> -        The secure channel between SD-WAN edge nodes and RR described by
> draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.
> Any thoughts?
> Thank you very much.
> Linda Dunbar
> _______________________________________________
> BESS mailing list