Re: [Idr] draft-dunbar-idr-sdwan-port-safi address the WAN Port property registration that is not covered by Ali's SECURE-EVPN

"Henderickx, Wim (Nokia - BE/Antwerp)" <> Wed, 27 March 2019 20:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 322F11203A0 for <>; Wed, 27 Mar 2019 13:42:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aUQndjs9rbOz for <>; Wed, 27 Mar 2019 13:42:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 711AC1202AB for <>; Wed, 27 Mar 2019 13:42:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=axCGPqotcnuFAzjz6JHWS7LQoIl1xvM8OYVenGaDmb8=; b=UHRTR6Inp1FjSdxwpaadTI2MYMWf5b7brd2bgbqyHJgAIAr18MTGHPaWb535j4Hmu9aFH+NYGxH6B17vG36lliGfCtF4GyyYXLd+Q20jA18QEQX31tKlURthASUxeyfpMJ8DbHmaDUtq0Qp45iFjUQSiGY+Htf0KHl4I1NGKFYg=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.14; Wed, 27 Mar 2019 20:42:30 +0000
Received: from ([fe80::d9f4:4bd1:b11a:cd3]) by ([fe80::d9f4:4bd1:b11a:cd3%3]) with mapi id 15.20.1750.014; Wed, 27 Mar 2019 20:42:30 +0000
From: "Henderickx, Wim (Nokia - BE/Antwerp)" <>
To: Linda Dunbar <>, Robert Raszuk <>
CC: idr wg <>
Thread-Topic: [Idr] draft-dunbar-idr-sdwan-port-safi address the WAN Port property registration that is not covered by Ali's SECURE-EVPN
Thread-Index: AdTj8xmd93+GSvgSRLiyQoUk9BbENQALvUjwAAHlNoAAHFvZgAASuWeA
Date: Wed, 27 Mar 2019 20:42:30 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: nl-BE, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6d9538cb-561d-49d1-4300-08d6b2f4bb4f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR07MB5086;
x-ms-traffictypediagnostic: VI1PR07MB5086:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 0989A7979C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(39860400002)(396003)(376002)(346002)(199004)(189003)(83716004)(106356001)(26005)(81156014)(8936002)(81166006)(186003)(71190400001)(66574012)(229853002)(6436002)(33656002)(316002)(6486002)(97736004)(68736007)(71200400001)(99286004)(3846002)(105586002)(8676002)(2906002)(6116002)(82746002)(58126008)(5660300002)(110136005)(102836004)(86362001)(2616005)(236005)(25786009)(6506007)(66066001)(14454004)(7736002)(11346002)(53546011)(476003)(6306002)(14444005)(446003)(966005)(561944003)(478600001)(486006)(4326008)(54896002)(6512007)(53936002)(36756003)(606006)(6246003)(76176011)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5086;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: XBjjUKO9OXZiercIxnEnC7f5pM+XQIqrH3IV9fjb8oJWoouQNxbt7nCZ/TnOHDnFOT2lX79lElfTOjy6kbx42OHJJi5GUWGwQtKYunnWmWby44SSk8vxpAShS2Mqw0e1tGY0rJAuaUG+1UtJA+8iz3jSEdHuB0MGWMbehtbPBg1qvcIEf5B8cxF6LH59SbYWXHX0HUAgdE2miMAHcpStO2kkm0rKZzV4xawOe6eQQQ2w8hqz0Xs17HFWC05U13el4sqvxk12maVhuklVP7ZY7zOKeQ8DufxsPHttiYnNN5nUGY6wYZHfkV+aZdbJy2NRtN0ljtcwFyY5oqxPTQoo9SQVezyeR+QCB9c2vnfpVmupTVJTY7T4AIfVWq6wbcF8grkNeC/YZwy6ObjI25tioEGuYSmxs3yJDs2ZL+4LWxY=
Content-Type: multipart/alternative; boundary="_000_2C0A8CC7CD2A46AA8A0C7E9513F9A4B4nokiacom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6d9538cb-561d-49d1-4300-08d6b2f4bb4f
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2019 20:42:30.2891 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5086
Archived-At: <>
Subject: Re: [Idr] draft-dunbar-idr-sdwan-port-safi address the WAN Port property registration that is not covered by Ali's SECURE-EVPN
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Mar 2019 20:42:38 -0000

Linda, thx for the email and I also wanted to comment in the IDR meeting, but we did not have the time, so hence my email.
Here is my feedback. You are proposing to introduce a new AFI/SAFI in BGP to indicate:

  *   Port IP address, info
  *   IPSEC required or not per link
  *   NAT traversal

Port info you don’t need in a routing protocol and you already have NH which is actually your port IP, so in my view this extension  is not required. More augmented info you can get from Netconf/GNMI/etc
IPSEC required on a link or not, you can use the encap attribute RFC5512/new proposal which is getting to RFC in IDR for that.
NAT traversal is something we need to extend probably, but I believe it is better to extend BGP EVPN and/or IP-VPN for this as most machinery in SD-WAN would use either EVPN or IP-VPN.

From: Idr <> on behalf of Linda Dunbar <>
Date: Wednesday, 27 March 2019 at 13:46
To: Robert Raszuk <>
Cc: IDR <>
Subject: Re: [Idr] draft-dunbar-idr-sdwan-port-safi address the WAN Port property registration that is not covered by Ali's SECURE-EVPN


You are absolutely correct that there are much more aspects of SD-WAN, such as SLA probing, intelligent path selection (via different egress ports) based on the monitoring functions over entire network, etc. We don’t think those features belong to BGP.  I was asked to restrict the discussion to IDR specific.

Some of what you mentioned have been documented the Problem Statement & Gap Analysis for SD-WAN Overlay. We welcome your comments and contributions. Unauthorized/spoof endpoints is also discussed in those drafts.
SD-WAN operational capabilities and requirements have been studied in other operator forums (ONUG) and RTGWG.
Glad to discuss these topics privately or on the RTGWG forum

Using BGP for the WAN port property registration is only a small portion of SDWAN.  draft-dunbar-idr-sdwan-port-safi proposes a new NLRI  for this purpose because of the following reasons:

  1.  BGP-LS + EVPN is putting lots of information into specific NLRI (AFI/SAFI) pair for a target audience,

So discussion load on BGP protocol in general is the topic for another general thread,

  1.  SD-WAN NRLI will be a targeted (AFI/SAFI) pair so it is assumed that communities will provide policy to limit distribution,

Thank you very much for the comments.


From: Robert Raszuk []
Sent: Wednesday, March 27, 2019 12:14 AM
To: Linda Dunbar <>
Cc: Ali Sajassi (sajassi) <>; idr wg <>
Subject: Re: [Idr] draft-dunbar-idr-sdwan-port-safi address the WAN Port property registration that is not covered by Ali's SECURE-EVPN

Hi Linda,

> Your draft-sajassi-bess-secure-evpn-01 doesn’t cover the following important features for SD-WAN

Please observe that while you may be correct in the observation made below your proposal is realistically also nowhere near to what SDWAN needs to truly operate.

Just think about SLA probing (both triggering path selection based on dynamically signaled parameters by controller as well as reporting the results to controller, think about managing the endpoints, doing upgrades, performing endpoint debugging, think about OAM required for overlay and underlay probing from each end point etc ... ) do you think all of this really belongs in BGP ?

See any decent SDWAN deployment to succeed is way much more complex then discovering endpoints and setting IPSec between them.

Now please also think what happens if you discover unauthorized/spoof endpoints ....

Kind regards,

On Tue, Mar 26, 2019 at 11:32 PM Linda Dunbar <<>> wrote:


After my presentation of draft-dunbar-idr-sdwan-port-safi, you stated at the microphone that your draft-sajassi-bess-secure-evpn-01 can cover what is presented.

Your draft-sajassi-bess-secure-evpn-01 doesn’t cover the following important features for SD-WAN:

Since SDWAN edge nodes (virtual or physical) deployment at a specific location can be ephemeral, Zero Touch Provisioning (ZTP) is a common requirement, which includes SDWAN node registering the properties of its WAN ports facing the public internet to its controller upon power up, whereas PE’s WAN ports are pre-configured. A SD-WAN node can have multiple WAN ports, some egress to a private network through which traffic can traverse natively without encryption, and some ports egress to public network through which traffic has to be encrypted. Client’s routes can egress to either WAN ports facing private network or WAN ports facing the public internet depending on the client specified policy and the feedback from the WAN traffic monitoring functions.

draft-dunbar-idr-sdwan-port-safi, is for advertising the properties of a SDWAN edge node WAN ports that face untrusted networks, such as the public internet. Those WAN ports may get assigned IP addresses from the Internet Service Providers (ISPs), may get assigned dynamic IP addresses via DHCP, or may have private addresses (e.g. inside third party Cloud DCs). Packets sent over those SDWAN WAN ports might need to be encrypted (depending on the user policies) or need to go through NAT. The newly proposed NLRI is for this purpose.

Best Regards,

Idr mailing list<>