Return-Path: 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 7E1E73A126D; Thu, 19 Mar 2020 16:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, 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 39bNo3c6Zao0; Thu, 19 Mar 2020 16:44:47 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2104.outbound.protection.outlook.com [40.107.243.104]) (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 598D03A126F; Thu, 19 Mar 2020 16:44:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3Dc4sgp8zg1qIaAUPAoxeNZmTiTyhXbJxI4gcZ+77aftAA7XNmZDSnYFK0lUGTg?= =?utf-8?q?4S3KHgAq7UUwzdmpo8cyentcn2tLj0VQot4o53tW9fnRmffavibooH4nTh34oGTMS?= =?utf-8?q?svbdI7HnfF2JwB79ZCFJW2AhdjhSZXOg5J/jtKxEV7Pm7Vp7ml+jiBaUqlxunIyDn?= =?utf-8?q?QDtZl4pI8PVdti4IoyhDqoWw2rBhhEw17FNsX7qEq1JL574qdPn3pgKSq2lWxX1ng?= =?utf-8?q?+FQf45CvV7O6m2B4F4+BkJeP2i5qrA9QFJkVIcaeyfZB550IkZajZwIoKS0Tf/Q3q?= =?utf-8?q?XZ2PWfiGKZDF1dL8Leo+A=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=3DWT4q24bvgvILGexqvwpAsxcxmPAlN6yDSvt1kb1y0Ls=3D=3B_b=3DnFEDgY?= =?utf-8?q?ga9svHD6Gg3iiz0G1yOafW9yKuQ7T2QV9nrMWHM2WsUzPUlU7b+aAd7HTZHz5KD9d?= =?utf-8?q?siqWNOOmUYqTmHMoUsz0mrlFSmqpMFcmNyL6zM8ojpQNqxmiAvYsriUgTTTwVrhgr?= =?utf-8?q?Iwj7Z8yRy6Lj/fnXcOH8CSU1KpG0NP7AcLOQe0kbtTusI2a/IBQrU0eP9/zP5DRiB?= =?utf-8?q?8vvwPOe1fS1AEynQU9Z/5OKPs1wERos6SXDnFVlFrjJkPAHstIB6d2dIcnjDhfajJ?= =?utf-8?q?62uF24vVDr1AqE3AKcxW4Fj7dWmGQDLxXvHiBEy6cBlr/seirkVFB2BBEVkHI76px?= =?utf-8?q?T5eGpETdoGA=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=3DWT4q24bvgvILGexqvwpAsxcxmPAlN6yDSvt1kb1y0Ls=3D=3B_b=3DQlXm1s?= =?utf-8?q?fASdCccLZi3g7nhf41dBUewo7g4kazDmAidChTtmqn3o8OsmOS96K5oQKrvl/tXSt?= =?utf-8?q?28w21cb5z+VAbpHQVL1rvemgUe8J/K7Iog3EWpAD970GTNMVtqZ54FrqdW+qzqZb1?= =?utf-8?q?ThpeUwfRUSgDy+BI4AXcfGN/9ZtMk6Rq+eM=3D?= Received: from BY5PR13MB3651.namprd13.prod.outlook.com (2603:10b6:a03:22e::19) by BY5PR13MB3287.namprd13.prod.outlook.com (2603:10b6:a03:18b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.12; Thu, 19 Mar 2020 23:44:43 +0000 Received: from BY5PR13MB3651.namprd13.prod.outlook.com ([fe80::b87d:8a82:886f:f088]) by BY5PR13MB3651.namprd13.prod.outlook.com ([fe80::b87d:8a82:886f:f088%9]) with mapi id 15.20.2835.017; Thu, 19 Mar 2020 23:44:43 +0000 From: Huaimo Chen To: Linda Dunbar , "idr@ietf.org" CC: "bess@ietf.org" Thread-Topic: [Idr] FW: Is there any problem of using Private AS as "Identifier" to differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage? Thread-Index: AQHV/hMalni6vDbTZU6510VZAoeuSahQk7bz Date: Thu, 19 Mar 2020 23:44:43 +0000 Message-ID: =?utf-8?q?=3CBY5PR13MB365140B73C5BB40C81684B73F2F40=40BY5PR13MB3?= =?utf-8?q?651=2Enamprd13=2Eprod=2Eoutlook=2Ecom=3E?= References: =?utf-8?q?=3CMWHPR1301MB2096A17F9653EBEEAAF9C6AE85F40=40MWHPR130?= =?utf-8?q?1MB2096=2Enamprd13=2Eprod=2Eoutlook=2Ecom=3E=2C_=3CMWHPR1301MB209?= =?utf-8?q?69D3F2062607748C04CC485F40=40MWHPR1301MB2096=2Enamprd13=2Eprod=2E?= =?utf-8?q?outlook=2Ecom=3E?= In-Reply-To: =?utf-8?q?=3CMWHPR1301MB20969D3F2062607748C04CC485F40=40MWHPR13?= =?utf-8?q?01MB2096=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=huaimo.chen@futurewei.com; x-originating-ip: [2601:199:4300:8e5a:1892:e8dc:1d57:128c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: af554cc9-ce6b-44b8-2676-08d7cc5f7fcb x-ms-traffictypediagnostic: BY5PR13MB3287:|BY5PR13MB3287: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: =?utf-8?q?=3CBY5PR13MB32875844D6AFAD41ED296F60F2F?= =?utf-8?q?40=40BY5PR13MB3287=2Enamprd13=2Eprod=2Eoutlook=2Ecom=3E?= x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0347410860 x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810019020=29=284636?= =?utf-8?b?MDA5KSgzOTg1MDQwMDAwNCkoMTM2MDAzKSgzNzYwMDIpKDM5NjAwMykoMzY2?= =?utf-8?b?MDA0KSgzNDYwMDIpKDE5OTAwNCkoOTY2MDA1KSgxMTAxMzYwMDUpKDUzNTQ2?= =?utf-8?b?MDExKSgyOTA2MDAyKSg2NjQ3NjAwNykoNzYxMTYwMDYpKDc2OTYwMDUpKDMz?= =?utf-8?q?656002=29=2866946007=29=28316002=29=2844832011=29=2819627405001?= =?utf-8?b?KSg0Nzg2MDAwMDEpKDY1MDYwMDcpKDg5MzYwMDIpKDE4NjAwMykoODYzNjIwMDEp?= =?utf-8?q?=2881156014=29=2881166006=29=288676002=29=2852536014=29=286644600?= =?utf-8?b?OCkoOTY4NjAwMykoNTUwMTYwMDIpKDQzMjYwMDgpKDY2NTc0MDEyKSg0NTAx?= =?utf-8?q?00002=29=2866556008=29=2864756008=29=285660300002=29=287120040000?= =?utf-8?q?1=29=3B?= DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR13MB3287; H:BY5PR13MB3651.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?xE5nsClmDh0TbOLMNZYFC/W8HwNxxsU?= =?utf-8?q?KjOgansCCaJAN+Ou+GzgQl4wXfUVbfJaX6GTvKYl0hVi5VMbiOdMqDYFQILzCVT36?= =?utf-8?q?1kocMfQKVdPGaqs+WkY3IJcl5k8Fm1Tp/G62DlpzdWnbetEdmDpOLSIw59fPZIZxj?= =?utf-8?q?5lJh7w7fccEabPG3Hhd3uL7KVVQ2bLzid/8jbIQU5pExHV59UVqM5ZsKxKEShFIKN?= =?utf-8?q?AfKpN3gdt/O97+3/8+0r1QAh/BwPyiyw9hG/rfhjb5PX9EuZJ+ZTqeqRK2/Qb6mBJ?= =?utf-8?q?HzgyZlWgxw43Xdze5Lgrq5BzeZFzfx1aHxMvQPggrMVq5+8nm0czptJ1WxO7H2z85?= =?utf-8?q?Iv9OjdDidEq6mezcH9ovTz/DbY3rYFhUb4R2mijnCeLs/q6zb3xRYIsFf3IOZLTc8?= =?utf-8?q?W2Y/4SwXhFZEWZ7n7usORhR8z46NBgIKQzhWGFqbY+xzBaErmm4VvH+ia1vf4ojg+?= =?utf-8?q?d6q3H8aKefT+t07Eg2Cpi28l8NNYKUdqjmbYLxLwr6g4svRw=3D=3D?= x-ms-exchange-antispam-messagedata: =?utf-8?q?+0N5oIEuje3MfleEIBIbIGf5p3rcLU?= =?utf-8?q?xDbDLU0zTUO/K70LK5FMqQhbfPgz27Qb3nifwAh5IancB6CSfKrTNz4pr1AWzgtxr?= =?utf-8?q?/LAtIBDOQXJ8tREhs8zXf5j41fkQ2RQAVReSWo18W/xfH1Rbv0lAclX/6jwLYfw6T?= =?utf-8?q?fgZAS7njjlO4Jxb50sy98b75jOqUgGuH+y88QZXr12PrQ5QCTmJs/g=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY5PR13MB365140B73C5BB40C81684B73F2F40BY5PR13MB3651namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: af554cc9-ce6b-44b8-2676-08d7cc5f7fcb X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2020 23:44:43.2481 (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?+7zS/EiU2Ju1AaT9H7HRC?= =?utf-8?q?PezEASimWzH56N1pLspQ4oJNreRzlHc5J6M3V1TvEW72UQsJzZ8KHQdMRYLkIBJvg?= =?utf-8?q?=3D=3D?= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3287 Archived-At: 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? X-BeenThere: idr@ietf.org 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: Thu, 19 Mar 2020 23:44:53 -0000 --_000_BY5PR13MB365140B73C5BB40C81684B73F2F40BY5PR13MB3651namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Linda, It seems that a label may be used as an "Identifier" to differentiate S= D-WAN Segmentation. Best Regards, Huaimo ________________________________ From: Idr on behalf of Linda Dunbar Sent: Thursday, March 19, 2020 1:22 PM To: idr@ietf.org Cc: 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. Wa= nt 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 ; bess@ietf.org Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org Subject: Is there any problem of using Private AS as "Identifier" to differ= entiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwan-usage? Based on Basil=92s comment on needing an identifier to differentiate SDWAN = instances, I added a section to draft-dunbar-bess-bgp-sdwan-usage . Want t= o hear people=92s feedback. 3.1 Requirements 3.1.1Supporting Multiple SDWAN Segmentations The term =93network segmentation=94 is used extensively in SDWAN deployment= . In general (and in this document), the =93Network Segmentation=94 is refe= rring to the process of dividing the network into logical sub-networks usin= g 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, V= RF 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 in= stances (or segmentations). When different SDWAN network segments do not ha= ve their own assigned AS numbers, a very easy way is to use Private AS numb= ers, in the range of 64512 to 65535, to differentiate different SDWAN segme= ntations. When using BGP to control the SDWAN networks, the Private AS numb= ers 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 > Sent: Friday, February 7, 2020 3:02 PM To: Linda Dunbar >; bess@ietf.org Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org Subject: RE: solicit feedback on draft-dunbar-bess-bgp-sdwan-usage descript= ion of using BGP UPDATE messages to achieve SD-WAN Application Based Segmen= tation Hi Linda; The SD-WAN Segment is part of the SD-WAN fabric; in other words, there coul= d be more than one Segment over a single underlay depending on the design a= nd the business requirements. Each Segment represents a single and an isolated L3 domain; therefore, I su= ggested that we may need to include the Segment ID in the BGP update messag= es in order to identify and build the routing the table for each Segment (b= ased on the Segment ID). Hope this helps. Regards; Basil From: Linda Dunbar > Sent: February-03-20 10:40 AM To: Najem, Basil >; bess@ie= tf.org Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org Subject: [EXT]RE: solicit feedback on draft-dunbar-bess-bgp-sdwan-usage des= cription of using BGP UPDATE messages to achieve SD-WAN Application Based S= egmentation 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 inc= luded in the BGP UPDATE), does the =93Segment=94 mean the different Underla= y? In the figure below, C-PE1 has 3 WAN ports: 2 to MPLS network and 1 to Publ= ic Internet. Do you mean C-PE1 has 3 WAN =93segments=94? If not, can you elaborate more? [cid:image001..png@01D5FDE3.587A47F0] Thanks, Linda From: Najem, Basil > Sent: Sunday, February 02, 2020 5:48 PM To: Linda Dunbar >; bess@ietf.org Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org Subject: RE: solicit feedback on draft-dunbar-bess-bgp-sdwan-usage descript= ion of using BGP UPDATE messages to achieve SD-WAN Application Based Segmen= tation Hello Linda; I haven=92t 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 di= fferent underlay networks. Very often there are multiple parallel overlay p= aths between any two SDWAN edges, some of which are private networks over w= hich 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 u= necrypted (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 di= fferent underlay networks. Very often there are multiple parallel overlay p= aths between any two SDWAN edges, some of which are private networks over w= hich traffic can traverse with or without encryption, others require encryp= tion, 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 Appli= cation Flow to the Segment. Since the Segment is a =93routing domain=94, th= e 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=92s highly appreciated. Regards; Basil From: Linda Dunbar > Sent: January-31-20 5:17 PM To: bess@ietf.org Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org Subject: [EXT]solicit feedback on draft-dunbar-bess-bgp-sdwan-usage descrip= tion of using BGP UPDATE messages to achieve SD-WAN Application Based Segme= ntation BESS participants: =93SDWAN=94 networks is characterized by: 1. Augment of transport, which refers to utilizing overlay paths over di= fferent underlay networks. Very often there are multiple parallel overlay p= aths between any two SDWAN edges, some of which are private networks over w= hich 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/ describes examples of using BGP U= PDATE messages to achieve the SDWAN Application Based Segmentation, assumi= ng 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 / Cou= rriel externe: Soyez prudent avec les liens et documents joints ________________________________ External Email: Please use caution when opening links and attachments / Cou= rriel externe: Soyez prudent avec les liens et documents joints --_000_BY5PR13MB365140B73C5BB40C81684B73F2F40BY5PR13MB3651namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
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@i= etf.org> on behalf of Linda Dunbar <linda.dunbar@futurewei.com> Sent: Thursday, March 19, 2020 1:22 PM
To: idr@ietf.org <idr@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
Subject: [Idr] FW: Is there any problem of using Private AS as "= ;Identifier" to differentiate SD-WAN Segmentation for draft-dunbar-bes= s-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>; bess@ietf.org
Cc: draft-dunbar-bess-bgp-sdwan-usage@ietf.org
Subject: Is there any problem of using Private AS as "Identifie= r" to differentiate SD-WAN Segmentation for draft-dunbar-bess-bgp-sdwa= n-usage?

 

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

 

3.1    Requirements

3.1.1Supporting Multiple SDWAN Segmentations

The term =93network segmentation=94 is used extensively in SDWAN deployment= . In general (and in this document), the =93Network Segmentation=94 is refe= rring to the process of dividing the network into logical sub-networks usin= g 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 segme= nts.

As SDWAN is an overlay network arching over multiple types of networks, it = is important to have distinct identifiers to differentiate SDWAN network in= stances (or segmentations). When different SDWAN network segments do not ha= ve their own assigned AS numbers, a very easy way is to use Private AS numbers, in the range of 64512 to 655= 35, to differentiate different SDWAN segmentations. When using BGP to contr= ol 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>
Sent: Friday, February 7, 2020 3:02 PM
To: Linda Dunbar <l= inda.dunbar@futurewei.com>; bess@ietf.org
Cc: dr= aft-dunbar-bess-bgp-sdwan-usage@ietf.org
Subject: RE: solicit feedback on draft-dunbar-bess-bgp-sdwan-usage d= escription 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 ove= r a single underlay depending on the design and the business requirements.<= /span>

 

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

 

Hope this helps.

 

Regards;

 

Basil

 

 

From: Linda Dunbar <linda.dunbar@futurewei.com>
Sent: February-03-20 10:40 AM
To: Najem, Basil <basil.na= jem@bell.ca>; bess@ietf.org
Cc: dr= aft-dunbar-bess-bgp-sdwan-usage@ietf.org
Subject: [EXT]RE: solicit feedback on draft-dunbar-bess-bgp-sdwan-us= age 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 inc= luded in the BGP UPDATE), does the =93Segment=94 mean the different Underla= y?

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

Do you mean C-PE1 has 3 WAN =93segments=94?

If not, can you elaborate more?

 

 

 

Thanks, Linda

 

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

 

 

Hello Linda;

 

I haven=92t gone through the e= ntire document; however, I have the following quick comments

 

  1. Regarding the following paragraph:

 

  1. Augment of transport, w= hich refers to utilizing overlay paths over different underlay networks. Ve= ry often there are multiple parallel overlay paths between any two SDWAN ed= ges, 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 i= s NOT encrypted is not always correct). I would change the parpagaph to the following (for clarity):

 

  1. Augment of transport, w= hich refers to utilizing overlay paths over different underlay networks. Ve= ry often there are multiple parallel overlay paths between any two SDWAN ed= ges, some of which are private networks over which traffic can traverse with or withou= t encryption, others require encryption, e.g. over untrusted public network= s.

 

 

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

 

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

 

Any feedback is welcomed and it=92s highly appreciated.

 

Regards;

 

Basil

 

 

From: Linda Dunbar <linda.dunbar@futurewei.com>
Sent: January-31-20 5:17 PM
To: bess@ietf.org
Cc: dr= aft-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 Base= d Segmentation

 

BESS participants:

 

=93SDWAN=94 networks is characterized by:

  1. Augment of transport, w= hich refers to utilizing overlay paths over different underlay networks. Ve= ry often there are multiple parallel overlay paths between any two SDWAN ed= ges, 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 c= entralized 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/= describes examples of using BGP UPDATE messages to achieve the SDWAN Appli= cation Based Segmentation,  assuming that the applications are assigne= d 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:

 

 

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

-  &= nbsp;     MP-NLRI Path Attribute:

      • 30.1.1.x/24

-  &= nbsp;     Tunnel Encap Path Attribut= e

      • IPsec Attributes for PaymentGW ->C-PE2

 

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

-  &= nbsp;     MP-NLRI Path Attribute:

      • 10.1.x.x
      • 12.4.x.x

= -&n= bsp;       TunnelEncap Path Attribute= :

      • Any node to C-PE2

 

 

Your feedback is greatly appreciated.

 

Thank you very much.

 

Linda Dunbar

External Email:Courriel externe: Soyez prudent avec les liens et documents joints

External Email:Courriel externe: Soyez prudent avec les liens et documents joints

--_000_BY5PR13MB365140B73C5BB40C81684B73F2F40BY5PR13MB3651namp_--