[Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI

Linda Dunbar <linda.dunbar@futurewei.com> Mon, 23 March 2020 17:46 UTC

Return-Path: <linda.dunbar@futurewei.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 CAEE33A0CC5; Mon, 23 Mar 2020 10:46:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com
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 yDu_JKzScUki; Mon, 23 Mar 2020 10:46:36 -0700 (PDT)
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2122.outbound.protection.outlook.com [40.107.93.122]) (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 42E773A0D0F; Mon, 23 Mar 2020 10:46:34 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DPKqAxzcVNH5mGsTlZI5W0989SwnkHF1/F4sY07vtvURJo28xmZIrZZefJfTWL?= =?utf-8?q?7q6McSRq2MjYt+XTvVT75p/1tRfUnf6NCY2UbjY4TxfGngVKyUBs1qnF0jWhA7awz?= =?utf-8?q?RJUO/d87PAVztoW3zqKF/DAlhJlCIeQ5+SCOnK8hcodtMGp9rwQtAzx/tm/uPgDVS?= =?utf-8?q?JRpS3flzgRoPM/XD1fF7gN6x58smQ8b7/MJjiEUzTKc/6GJsLO8QfmN0LD7G/7nqm?= =?utf-8?q?ATUQ+tW5gNRE/okGD9HXMspVylnNwln9jIR+EQWw2QIqmInLz82kFAdxk8EIkSM0E?= =?utf-8?q?Nmc2c++MNGR9n9NdrTbHQ=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DZTkFuPK0PYKAzYQTbbyCiuWyeIHLMBBBdyTc0GDJGlU=3D=3B_b=3DAYtuCj?= =?utf-8?q?SfHejAnZP7zAhVJbqUhQYZXApCImDVwU8zsxbOL7JWA/M670idc9Bmd+qvX8XP6tJ?= =?utf-8?q?JmgaYgfbS28dtAckt9X47KWHpj3fyYU0N0qYs8hxrlzX1MXtKZuc7P+/e7iNLjBmq?= =?utf-8?q?bPP3c+nzCi7FnGEE45SWg/LIIsoRf4QomVL2Xmbaf8Ne2gqtG456IXiTwVx6mfZpA?= =?utf-8?q?LltmO9qKV/LPV2tu2gTDbO0iONkD5Gc/QaVMzkEUGE/7ZjOZBtoCQNExR1Ne7B8N+?= =?utf-8?q?9qjcpqcN3vVoYRfQtocgwpl6PbqSYChsZGqOUmjER/D0Ks+Yib8enEbOqWZfDe2ix?= =?utf-8?q?Rurov1BJD0g=3D=3D?=
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3AContent-Typ?= =?utf-8?q?e=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DZTkFuPK0PYKAzYQTbbyCiuWyeIHLMBBBdyTc0GDJGlU=3D=3B_b=3DZNqK35?= =?utf-8?q?X+VVn056ZOuQr5GgTqM471LEhMKNvxsB5ovjIVQrVYFcN/MLTffCCVTalHp38v0pR?= =?utf-8?q?fzS7sEyO8UGPyoGW0YhS/XuX4UAwvwS7IpgAvAlJldbbRTMDH8+/0foiFsgTqlqsf?= =?utf-8?q?tAsT0k3VtKErN39nh3yTZf26LS21Y797PaA=3D?=
Received: from MWHPR1301MB2096.namprd13.prod.outlook.com (2603:10b6:301:34::35) by MWHPR1301MB2111.namprd13.prod.outlook.com (2603:10b6:301:35::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.8; Mon, 23 Mar 2020 17:46:23 +0000
Received: from MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::a934:b942:156f:d945]) by MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::a934:b942:156f:d945%3]) with mapi id 15.20.2856.015; Mon, 23 Mar 2020 17:46:23 +0000
From: Linda Dunbar <linda.dunbar@futurewei.com>
To: Huaimo Chen <huaimo.chen@futurewei.com>, "idr@ietf.org" <idr@ietf.org>
CC: "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI
Thread-Index: AdYBLZw/F9a/dpF+TIW3a7GzFamIvw==
Date: Mon, 23 Mar 2020 17:46:22 +0000
Message-ID: =?utf-8?q?=3CMWHPR1301MB2096E56F2D64346B8FD2085B85F00=40MWHPR130?= =?utf-8?q?1MB2096=2Enamprd13=2Eprod=2Eoutlook=2Ecom=3E?=
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=linda.dunbar@futurewei.com;
x-originating-ip: [2605:6000:1526:d41e:9197:1a42:30ec:cf4d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7e4a68b5-25a7-433a-7830-08d7cf521a4c
x-ms-traffictypediagnostic: MWHPR1301MB2111:|MWHPR1301MB2111:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: =?utf-8?q?=3CMWHPR1301MB2111EE9CD63183542713F6B78?= =?utf-8?q?5F00=40MWHPR1301MB2111=2Enamprd13=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0351D213B3
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810019020=29=284636?= =?utf-8?b?MDA5KSgzNjYwMDQpKDEzNjAwMykoMzc2MDAyKSgzNDYwMDIpKDM5ODUwNDAw?= =?utf-8?b?MDA0KSgzOTYwMDMpKDE5OTAwNCkoNzY5NjAwNSkoMTg2MDAzKSgzMDg2NDAwMyko?= =?utf-8?q?55016002=29=2833656002=29=289686003=29=2866574012=29=284326008=29?= =?utf-8?q?=28966005=29=28110136005=29=2853546011=29=2886362001=29=284743002?= =?utf-8?b?KSg2NTA2MDA3KSg1MjUzNjAxNCkoODYxMDA2KSg2NDc1NjAwOCkoNjY0NDYwMDgp?= =?utf-8?q?=2866556008=29=2866476007=29=2844832011=29=28450100002=29=2831600?= =?utf-8?b?MikoNDc4NjAwMDAxKSg3NjExNjAwNikoODkzNjAwMikoNjY5NDYwMDcpKDcx?= =?utf-8?q?200400001=29=2881166006=29=285660300002=29=2881156014=29=28290600?= =?utf-8?b?MikoODY3NjAwMikoMTkzNjQzMDAxKSg1NTkwMDEpKDU3OTAwNCk7?= DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR1301MB2111; H:MWHPR1301MB2096.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?iHaCmMteT58A0+9Lx305hjs4Emvmi9S?= =?utf-8?q?ahCp3GhM2FrsnKRGmJSVPJbuAGqqzWtk4+eNUeoRDA9E1QAG81zPa0sOFMk4fMWqi?= =?utf-8?q?IRi5ZbMeojL/oH6We9crESaWJUJva3x9iEcqt8qzno+66uSMBLFGhWgoeh75hZJj7?= =?utf-8?q?oYV/ka9/vCPPan9fdb1WMOJ08TZPKwT+89RSGzrMnP0WHpBxbCnpjcICBlG7XCPQ9?= =?utf-8?q?qgwyfEzcR5rNUVGtm6OldHUuWHRkBZYsXU7QIF0Y5XJ14qmcYt7v5Y4yxbK1+Rr5Y?= =?utf-8?q?fwB4yIZPVHyMYZ2YWmlLIELYHR8HoIyGCVxPFNuv1n+YKZHJLUWRhavZ58PTVWaky?= =?utf-8?q?h9MjK7nJ5U3E9swfqR9NiuhYLhOCUYIpFd2aBOok9znnltJrDBexN50ph6I2n0/1o?= =?utf-8?q?mPNoAYkqQtCHrkHxEZhNfVr+OAfm/n2VV/wf31dCIIywmx4SA8DX2o/M6OruA2ZOB?= =?utf-8?q?OSm+H6ZP6BeRF3XKIaCrQh0ePw/lnY8qlpEPuNhv33pWJUkgCvXXHb0wUEQUHP4Wr?= =?utf-8?q?NCvAjqBeZJZGOv/DLf+2Ki23j?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?K4pjWdpc40FAj9TOqeN5D1CBQBusA9?= =?utf-8?q?EPPTHXL8qleS13o97SSrnLOw5JtE3UVEUSeuZQJ/0CmXMNgq2LycLlIpgoEy0w3/I?= =?utf-8?q?k2Ocm9QY1VDBHN+V48dayAeVGPan/oUS4DgXehbPxSqk9WWTDDvm7KX+BQ5j0u+RS?= =?utf-8?q?llbf/ECDuH4gWk2bcofZxi9j9+gIW5hBrdxLTQs3JcgZJCl8DqohYQ=3D=3D?=
Content-Type: multipart/alternative; boundary="_000_MWHPR1301MB2096E56F2D64346B8FD2085B85F00MWHPR1301MB2096_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7e4a68b5-25a7-433a-7830-08d7cf521a4c
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2020 17:46:23.0852 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: =?utf-8?q?RYL0bTVSQU96SwOEZjlQ3?= =?utf-8?q?U4j/GXeiAFNwnHrC+yEmQ2n8YuFQ3ESNrSRFs04rJg+yM3x1r5csPiXIt90S9BWBw?= =?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1301MB2111
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/IyQTvHUxKpWvoRPV40a3vVFrSpI>
Subject: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI
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: Mon, 23 Mar 2020 17:46:39 -0000

IDR experts:

SDWAN is an overlay network arching over multiple types of networks. A SDWAN edge node may need to map client traffic to different SDWAN network instances (or segmentations).
It might not be feasible to use the AS number in the BGP message to differentiate the SDWAN network instances as multiple SDWAN instances may share the same AS number.

We would like to hear feedback from IDR group on using similar method as  Binding MPLS Labels to Address Prefixes [RFC8277] to bind SDWAN Instance ID to  prefixes.

When  MPLS VPN SAFI (=128) is present, MPLS label is carried by NLRI [RFC8277] as:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Length     |                 Label                 |Rsrv |S|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Prefix                               ~
     ~                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 2: NLRI with One Label

We would like to  propose the SDWAN Instance ID being encoded in the Label field as follows when SDWAN SAFI (=74 allocated by IANA) is used,:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Length     |      SDWAN Instance ID (Label)        |Rsrv |S|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Prefix                               ~
     ~                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        NLRI with SDWAN Instance ID.

Greatly appreciate any comments or other suggestions.

Thank you,
Linda Dunbar

From: Huaimo Chen <huaimo.chen@futurewei.com>
Sent: Monday, March 23, 2020 9:14 AM
To: Linda Dunbar <linda.dunbar@futurewei.com>om>; idr@ietf.org
Cc: bess@ietf.org
Subject: Re: [Idr] FW: Is there any problem of using Private AS as "Identifier" to differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?

Hi Linda,

    It seems that using another SAFI is a possible solution.

Best Regards,
Huaimo
________________________________
From: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>
Sent: Friday, March 20, 2020 12:54 AM
To: Huaimo Chen <huaimo.chen@futurewei.com<mailto:huaimo.chen@futurewei.com>>; idr@ietf.org<mailto:idr@ietf.org> <idr@ietf.org<mailto:idr@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: [Idr] FW: Is there any problem of using Private AS as "Identifier" to differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?


Huaimo,



Thank you very much for the suggestion.

Do you mean using the similar approach as VPN Label carried by NLRI Path Attribute [RFC8277] for SDWAN Segmentation Identifier?

If yes, the UPDATE message should not use the MPLS VPN SAFI (=128) to avoid confusion, right?



Linda



From: Huaimo Chen <huaimo.chen@futurewei.com<mailto:huaimo.chen@futurewei.com>>
Sent: Thursday, March 19, 2020 6:45 PM
To: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>; idr@ietf.org<mailto:idr@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [Idr] FW: Is there any problem of using Private AS as "Identifier" to differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?



Hi Linda,



    It seems that a label may be used as an "Identifier" to differentiate SD-WAN Segmentation.



Best Regards,

Huaimo

________________________________

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> on behalf of Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>
Sent: Thursday, March 19, 2020 1:22 PM
To: idr@ietf.org<mailto:idr@ietf.org> <idr@ietf.org<mailto:idr@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>
Subject: [Idr] FW: Is there any problem of using Private AS as "Identifier" to differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?



BGP Experts,



Do you know if  there is any problem of using  Private AS as  "Identifier" to differentiate SD-WAN Segmentation? Here is the discussion in BESS WG. Want to get IDR WG feedbacks for this question.



Thank you.

Linda



From: Linda Dunbar
Sent: Thursday, March 19, 2020 11:54 AM
To: Najem, Basil <basil.najem@bell.ca<mailto:basil.najem@bell.ca>>; bess@ietf.org<mailto:bess@ietf.org>
Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org<mailto:draft-dunbar-bess-bgp-sdwan-usage@ietf.org>
Subject: Is there any problem of using Private AS as "Identifier" to differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage?



Based on Basil's comment on needing an identifier to differentiate SDWAN instances, I added a section to  draft-dunbar-bess-bgp-sdwan-usage . Want to hear people's feedback.



3.1    Requirements
3.1.1Supporting Multiple SDWAN Segmentations

The term "network segmentation" is used extensively in SDWAN deployment. In general (and in this document), the "Network Segmentation" is referring to the process of dividing the network into logical sub-networks using isolation techniques on a forwarding device such as a switch, router, or firewall. For a homogeneous network, such as MPLS VPN or Layer 2 network, VRF or VLAN are used to separate network segments.

As SDWAN is an overlay network arching over multiple types of networks, it is important to have distinct identifiers to differentiate SDWAN network instances (or segmentations). When different SDWAN network segments do not have their own assigned AS numbers, a very easy way is to use Private AS numbers, in the range of 64512 to 65535, to differentiate different SDWAN segmentations. When using BGP to control the SDWAN networks, the Private AS numbers are carried by the BGP UPDATE messages to their corresponding RRs.



Greatly appreciate any feedback on this description.



Is there any scenario that Private AS cannot be used?



Thank you very much.



Linda Dunbar



From: Najem, Basil <basil.najem@bell.ca<mailto:basil.najem@bell.ca>>
Sent: Friday, February 7, 2020 3:02 PM
To: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>; bess@ietf.org<mailto:bess@ietf.org>
Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org<mailto:draft-dunbar-bess-bgp-sdwan-usage@ietf.org>
Subject: RE: solicit feedback on draft-dunbar-bess-bgp-sdwan-usage description of using BGP UPDATE messages to achieve SD-WAN Application Based Segmentation







Hi Linda;



The SD-WAN Segment is part of the SD-WAN fabric; in other words, there could be more than one Segment over a single underlay depending on the design and the business requirements.



Each Segment represents a single and an isolated L3 domain; therefore, I suggested that we may need to include the Segment ID in the BGP update messages in order to identify and build the routing the table for each Segment (based on the Segment ID).



Hope this helps.



Regards;



Basil





From: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>
Sent: February-03-20 10:40 AM
To: Najem, Basil <basil.najem@bell.ca<mailto:basil.najem@bell.ca>>; bess@ietf.org<mailto:bess@ietf.org>
Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org<mailto:draft-dunbar-bess-bgp-sdwan-usage@ietf.org>
Subject: [EXT]RE: solicit feedback on draft-dunbar-bess-bgp-sdwan-usage description of using BGP UPDATE messages to achieve SD-WAN Application Based Segmentation



Basil,



Thank you very much for the comments.

Your suggested wording change will be incorporated in the next revision.



As for your suggestion of Segment and Segment ID of a SDWAN node (to be included in the BGP UPDATE), does the "Segment" mean the different Underlay?

In the figure below, C-PE1 has 3 WAN ports: 2 to MPLS network and 1 to Public Internet.

Do you mean C-PE1 has 3 WAN "segments"?

If not, can you elaborate more?



[cid:image001..png@01D5FDE3.587A47F0]





Thanks, Linda



From: Najem, Basil <basil.najem@bell.ca<mailto:basil.najem@bell.ca>>
Sent: Sunday, February 02, 2020 5:48 PM
To: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>; bess@ietf.org<mailto:bess@ietf.org>
Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org<mailto:draft-dunbar-bess-bgp-sdwan-usage@ietf.org>
Subject: RE: solicit feedback on draft-dunbar-bess-bgp-sdwan-usage description of using BGP UPDATE messages to achieve SD-WAN Application Based Segmentation





Hello Linda;



I haven't gone through the entire document; however, I have the following quick comments



  1.  Regarding the following paragraph:



1.       Augment of transport, which refers to utilizing overlay paths over different underlay networks. Very often there are multiple parallel overlay paths between any two SDWAN edges, some of which are private networks over which traffic can traverse without encryption, others require encryption, e.g. over untrusted public networks.



The traffic that traverses the privet networks can be either encrypted or unecrypted (in other words, the assumption that the traffic is NOT encrypted is not always correct). I would change the parpagaph to the following (for clarity):



1.       Augment of transport, which refers to utilizing overlay paths over different underlay networks. Very often there are multiple parallel overlay paths between any two SDWAN edges, some of which are private networks over which traffic can traverse with or without encryption, others require encryption, e.g. over untrusted public networks.





  1.  Another thing that we need to discuss is the Segment ID; each Segment (at the SD-WAN Edge) MUST have an ID. The SD-WAN Policy will map the Application Flow to the Segment. Since the Segment is a "routing domain", the BGP update will be exchanged with the memebers of a particular Segment.



As such: Should we include the Segment ID as an attribute in the BGP update messages? Perhaps we need to further discuss this in details.



Any feedback is welcomed and it's highly appreciated.



Regards;



Basil





From: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>
Sent: January-31-20 5:17 PM
To: bess@ietf.org<mailto:bess@ietf.org>
Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org<mailto:draft-dunbar-bess-bgp-sdwan-usage@ietf.org>
Subject: [EXT]solicit feedback on draft-dunbar-bess-bgp-sdwan-usage description of using BGP UPDATE messages to achieve SD-WAN Application Based Segmentation



BESS participants:



"SDWAN" networks is characterized by:

1.       Augment of transport, which refers to utilizing overlay paths over different underlay networks. Very often there are multiple parallel overlay paths between any two SDWAN edges, some of which are private networks over which traffic can traverse without encryption, others require encryption, e.g. over untrusted public networks.

2.       Enable direct Internet access from remote sites, instead hauling all traffic to Corporate HQ for centralized policy control.

3.       Some traffic are routed based on application IDs instead of based on destination IP addresses.





https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-bess-bgp-sdwan-usage%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C99acf950b82f4213da7f08d7cf34789d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637205696587614498&sdata=0MdUmWEie3Fd4y3UCVJ4HBdY0oxiBY4xiTK5%2FiMaAkQ%3D&reserved=0> describes examples of using BGP UPDATE messages to achieve the SDWAN Application Based Segmentation,  assuming that the applications are assigned with unique IP addresses.

In the Figure below, the following BGP Updates can be advertised to ensure that Payment Application only communicates with the Payment Gateway:



[cid:image002..png@01D5FDE3.587A47F0]



BGP UPDATE #1 from C-PE2 to RR for the RED P2P topology (only propagated to Payment GW node:

-        MP-NLRI Path Attribute:

        *   30.1.1.x/24

-        Tunnel Encap Path Attribute

        *   IPsec Attributes for PaymentGW ->C-PE2



BGP UPDATE #2 from C-PE2 to RR for the routes to be reached by Purple:

-        MP-NLRI Path Attribute:

        *   10.1.x.x
        *   12.4.x.x

-        TunnelEncap Path Attribute:

        *   Any node to C-PE2





Your feedback is greatly appreciated.



Thank you very much.



Linda Dunbar

________________________________

External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

________________________________

External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints