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

Linda Dunbar <linda.dunbar@huawei.com> Wed, 27 March 2019 12:46 UTC

Return-Path: <linda.dunbar@huawei.com>
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 78DD91202AF for <idr@ietfa.amsl.com>; Wed, 27 Mar 2019 05:46:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 yXUP4e1kPz4r for <idr@ietfa.amsl.com>; Wed, 27 Mar 2019 05:46:28 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D4A1202AA for <idr@ietf.org>; Wed, 27 Mar 2019 05:46:28 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2F2FDAEE697E255FA174 for <idr@ietf.org>; Wed, 27 Mar 2019 12:46:26 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 27 Mar 2019 12:46:24 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.5]) by SJCEML702-CHM.china.huawei.com ([169.254.4.253]) with mapi id 14.03.0439.000; Wed, 27 Mar 2019 05:46:20 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Robert Raszuk <robert@raszuk.net>
CC: "Ali Sajassi (sajassi)" <sajassi@cisco.com>, idr wg <idr@ietf.org>
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: AQHU5CmzvVG3JmcC5UuuMizcwDumLKYfaNig
Date: Wed, 27 Mar 2019 12:46:19 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B33C48A@sjceml521-mbs.china.huawei.com>
References: <4A95BA014132FF49AE685FAB4B9F17F66B33C11A@sjceml521-mbs.china.huawei.com> <CAOj+MMFXESNVmTC_SabEnF2K=BRN9S7+xC=ovcjDA_s3GAef9Q@mail.gmail.com>
In-Reply-To: <CAOj+MMFXESNVmTC_SabEnF2K=BRN9S7+xC=ovcjDA_s3GAef9Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.220.66.150]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B33C48Asjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Djcr8LxD-X69DYs0NX1NtmqURGE>
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-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: Wed, 27 Mar 2019 12:46:32 -0000

Robert,

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.
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/
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,


2)      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.

Linda.


From: Robert Raszuk [mailto:robert@raszuk.net]
Sent: Wednesday, March 27, 2019 12:14 AM
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: Ali Sajassi (sajassi) <sajassi@cisco.com>; idr wg <idr@ietf.org>
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,
R.

On Tue, Mar 26, 2019 at 11:32 PM Linda Dunbar <linda.dunbar@huawei.com<mailto:linda.dunbar@huawei.com>> wrote:

Ali,

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,

Linda
_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr