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 D1C293A1FBC for ; Tue, 31 Mar 2020 03:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net 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 ATeHMzyKm2eV for ; Tue, 31 Mar 2020 03:43:07 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E70E3A1231 for ; Tue, 31 Mar 2020 03:43:07 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id a49so21464967otc.11 for ; Tue, 31 Mar 2020 03:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dv1jNy75r13HVk+rO+8QHkyL36ZQZTu/G+/1sRxj7Y0=; b=CYBeg6HLTsGUy12Q8kw4tvAIUkEVjoQ47kBXviHqnIqRQTwt6Nh9SM5V2DQL8TkTxn 8k7gCGQ+nkeFD5rRUS3m10khB11A6RiriNlyFghzc7CrlPulNbr2KcJO4Rk/nB1PRp70 tl9vuCee/0AK7V6lPIMvn7/b9dntwFSy2enme2i3AouS3Sxre01V0DFzfB2vu3cs27e4 dGdKUTW/xTm2s3oDFz7vjmc1MDg84aEhBA8c8lptmrzY5PVqlSk7X058D94luIiG9pDJ 0glxvjayOs65BW0AIBkUpjbPeV2wm/hw9iYnfD7e6SYR+hVrpwZ/QKmmzlQkS3d4XgtM 1g9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dv1jNy75r13HVk+rO+8QHkyL36ZQZTu/G+/1sRxj7Y0=; b=l2U0E140rHAkOqPdJOBjmxxsPRNlcRy1WkDhDdwqnSNiubeDJmypdDhCoYQDieEDbm PQYsd/u38AcI98pQJTLK/qtUJvDbkfwbE3cg1tBMqRtvEMPS3oFl0/DaiIKypFlpbF41 RdpQ5clhQ2AjYEvAWD9DvX20VxLhKOpbrlU/qEbC+GIWTuW5AS+7X17TDllMn2JZI0V+ 2rBWFsdx5sBlSxxgB8He8POIRjnNcL8oiWUVNTLuGJQ1IszrnULekqfRRW19eA9TCwUH pXBqEct5KE7ZrWMeRl8CYuozv4/Q5aHbDJ0on5GT0w62j9OWBuWF+FiySRHiRkcNhf5e 3HYg== X-Gm-Message-State: ANhLgQ1VIJPs54Rq4v+h9MyyvEmrPdugwwglpzhbkJZRBxU6iFS8ObnU DA+HUoOYpdPX+bbyIcBd65WeUKoawA+O1pip61M2gw== X-Google-Smtp-Source: ADFU+vuoAMVpkZG7BxwO32kp0ZG48DkZQhYcGI5E8YNxe8rGjRVyBOObDBWiqrCByXG680ePuYpS70Hm0HdesY/8Qwg= X-Received: by 2002:a4a:874f:: with SMTP id a15mr2557921ooi.8.1585651386166; Tue, 31 Mar 2020 03:43:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Tue, 31 Mar 2020 12:42:55 +0200 Message-ID: To: Gyan Mishra Cc: Linda Dunbar , Huaimo Chen , "bess@ietf.org" , "idr@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009c3db405a2243bc8" Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 10:43:12 -0000 --0000000000009c3db405a2243bc8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Gyan, As topic 1 - Extended community which is used for filtering incoming updates can be configured under BGP AF - there is nothing in the protocol which mandates that such RTs need to be configured under VRF section. As of topic 2 - This is huge misconception by many people who think that SAFI 128 requires MPLS transport. So let me clearly state that SAFI 128 application can happily run for many years now over pure IP transport. VPN labels and transport paradigm are completely separate. Hint: RFC7510 or RFC4023. Moreover - let me also state that MPLS transport does not bring any benefits other then few bits savings in the packet header as compared with say IPv4 transport. Contrary it costs a lot of complexity in the control plane and forwarding planes of the network elements. Thx, R. On Tue, Mar 31, 2020 at 7:48 AM Gyan Mishra wrote: > > Robert & Linda > > Sorry to inject myself into this thread. > > You stated that that RFC 4364 SAFI 128 for vpnv4 vpnv6 is the BGP control > plane service layer overlay from PE to RR. Agreed. By default all PEs > including the SDWAN PE have RT Filtering enabled by default and only impo= rt > the RT into the VRF at the control plane level if the VRF is configured > with RT advertised by the RR is being imported by the PE, if not the SAFI > 128 prefixes are dropped. So I understand that the BGP updates is a > control plane function, but how would the routes get imported by the PE i= f > the VRF is not defined on the PE. RFC 4684 RTC capability allows only th= e > RTs imported on the PE to be advertised by the RR to reduced the SAFI 128 > route advertised by the RR that would result in being filtered on the PE. > > So how would that work using SAFI 128 RT to provide the network slicing > for SDWAN without VRF configured. > > Also you mentioned that SAFI 128 L3 vpn services overlay can run over any > underlay and that does not have to be MPLS based. I know SAFI 128 works > with SR-MPLS but there you are reusing the MPLS data plane. With SRv6 du= e > to PM draft signaling by egress PE for end.dx instantiation, so there is > not any service label necessary as is with MPLS and thus SAFI 128 works > with SRv6. > > How would SAFI 128 work with IP underlay used with SDWAN? > > Even with inter-as option b c ab, with BGP LU you do have topmost label > which is via BGP labeled unicast. For inter as options if SAFI128 would > work w/o BGP LU you could just run SAFI 128 over IP. I have never tried > but I think the control plane would come up but the data plane would be > broken. > > Kind regards > > Gyan > > On Tue, Mar 24, 2020 at 9:26 PM Linda Dunbar > wrote: > >> Robert, >> >> >> >> Want to confirm the following two points with you. Do I interpret your >> words correctly? >> >> >> >> - If a CPE supports traditional VPN with multiple VRFs, and supports >> multiple SDWAN instances, the traditional VRF configuration is still = same >> which are carried by BGP Route Target Extended community. >> - For the SDWAN Instances supported by the same CPE, we can use >> Extended Community with a different name (say SDWAN Target ID). When = the >> SDWAN Target ID is used, the SAFI 128 can be used for routes for the = SDWAN >> instance, with the exception that the label in the NLRI is not the M= PLS >> label carried by the data packets . >> >> >> >> Thank you. >> >> >> >> Linda Dunbar >> >> *From:* Robert Raszuk >> *Sent:* Tuesday, March 24, 2020 3:32 AM >> *To:* Linda Dunbar >> *Cc:* Huaimo Chen ; idr@ietf.org; >> bess@ietf.org >> *Subject:* Re: [Idr] Seeking feedback of >> draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instan= ce >> ID in the NLRI >> >> >> >> Hi Linda, >> >> >> >> Nope you do not need VRFs. RT construct works at the control plane level= . >> VRF may be useful for traffic separation purposes on multitenant CPEs or= if >> you would like to relax requirements for unique IP across SDWAN sites - = but >> not a must otherwise. >> >> >> >> My main point was that BGP SAFI 128 gives you for free transport for >> multiple routing contexts so why not leverage it as is? >> >> >> >> Moreover you may suddenly also discover that RTC (RFC4684) is your >> SDWAN friend too. >> >> >> >> Many thx, >> R. >> >> >> >> >> >> >> >> >> >> On Tue, Mar 24, 2020 at 5:15 AM Linda Dunbar >> wrote: >> >> Robert, >> >> >> >> Thank you very much for the feedback. >> >> >> >> If using your suggested Route Target approach to represent the SDWAN >> Instance ID, does it mean that a SDWAN Edge has to use the same approach= to >> configure the VRF for SDWAN instances? >> >> If the edge node supports both traditional VPN and SDWAN, will it cause >> confusion for RT to represent both? >> >> >> >> RT is encoded in the Extended_Communities Path Attribute, SAFI 128 is >> encoded in the MP_REACH_NLRI Path Attribute. >> >> >> >> What do you mean by saying =E2=80=9Cdifferent name to Route target(s) ca= rried in >> the SAFI 128=E2=80=9D? >> >> Do you mean having a different name (say SDWAN_Target) in >> Extended_Communities Path Attribute, and have MP_REACH_NLRI Path Attribu= te >> including the SAFI 128? >> >> >> >> SDWAN Instance ID is for the control Plane, not to be carried by the dat= a >> packets. SAFI 128 for VPN has the Label encoded in the NLRI field that i= s >> to be carried by the data packets. But SDWAN Instance ID is not carried = by >> the Data Packets. Is it correct? >> >> >> >> Thank you. >> >> Linda >> >> >> >> >> >> >> >> >> >> *From:* Robert Raszuk >> *Sent:* Monday, March 23, 2020 2:28 PM >> *To:* Linda Dunbar >> *Cc:* Huaimo Chen ; idr@ietf.org; >> bess@ietf.org >> *Subject:* Re: [Idr] Seeking feedback of >> draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instan= ce >> ID in the NLRI >> >> >> >> Hi Linda, >> >> >> >> I think you are mixing data plane and control plane. >> >> >> >> In SDWAN data plane is of no issue as you are interconnecting sites in a >> given VPN over mesh of secure tunnels. >> >> >> >> You are asking how to keep control plane separate between VPN instances. >> This is precisely what RFC4364 does already and RT import/export is used= to >> indicate the instance which given set of reachability belongs. Why to >> reinvent the wheel and do something new just for the heck of it :) ? >> >> >> >> To be original you can at best invent a different name to Route target(s= ) >> carried in the SAFI 128 but let's keep the mechanism the same. That woul= d >> be my suggestion. >> >> >> >> Kind regards, >> >> R. >> >> >> >> PS. While this is obvious for some many folks are still confused. RFC436= 4 >> does not need to run over MPLS data plane. It can run over IPSec or over >> DTLS or over UDP/IP just fine. >> >> >> >> On Mon, Mar 23, 2020 at 6:47 PM Linda Dunbar >> wrote: >> >> 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 networ= k >> 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 ma= y >> 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 Instanc= e >> ID to prefixes. >> >> >> >> When MPLS VPN SAFI (=3D128) 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 (=3D74 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 >> *Sent:* Monday, March 23, 2020 9:14 AM >> *To:* Linda Dunbar ; 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 >> *Sent:* Friday, March 20, 2020 12:54 AM >> *To:* Huaimo Chen ; 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? >> >> >> >> 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 (=3D128) to >> avoid confusion, right? >> >> >> >> Linda >> >> >> >> *From:* Huaimo Chen >> *Sent:* Thursday, March 19, 2020 6:45 PM >> *To:* Linda Dunbar ; 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 a label may be used as an "Identifier" to differentiat= e >> SD-WAN Segmentation. >> >> >> >> Best Regards, >> >> Huaimo >> ------------------------------ >> >> *From:* Idr on behalf of Linda Dunbar < >> linda.dunbar@futurewei.com> >> *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 discussio= n >> 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 ; bess@ietf.org >> *Cc:* 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=E2=80=99s comment on needing an identifier to differentia= te SDWAN >> instances, I added a section to draft-dunbar-bess-bgp-sdwan-usage . Wan= t >> to hear people=E2=80=99s feedback. >> >> >> 3.1 Requirements 3.1.1Supporting Multiple SDWAN Segmentations >> >> The term =E2=80=9Cnetwork segmentation=E2=80=9D is used extensively in S= DWAN deployment. >> In general (and in this document), the =E2=80=9CNetwork Segmentation=E2= =80=9D 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 netw= ork >> instances (or segmentations). When different SDWAN network segments do n= ot >> 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 SDWA= N >> segmentations.. When using BGP to control the SDWAN networks, the Privat= e >> 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 >> *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 >> 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 >> *Sent:* February-03-20 10:40 AM >> *To:* Najem, Basil ; bess@ietf.org >> *Cc:* 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 messag= es >> 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 =E2=80=9CSegment=E2=80=9D 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 =E2=80=9Csegments=E2=80=9D? >> >> If not, can you elaborate more? >> >> >> >> >> >> >> >> 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 >> description of using BGP UPDATE messages to achieve SD-WAN Application >> Based Segmentation >> >> >> >> >> >> Hello Linda; >> >> >> >> I haven=E2=80=99t 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 requ= ire >> encryption, e.g. over untrusted public networks. >> >> >> >> The traffic that traverses the privet networks can be either encrypted o= r >> 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 =E2=80=9C= routing >> domain=E2=80=9D, 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 discuss this in details. >> >> >> >> Any feedback is welcomed and it=E2=80=99s 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 >> description of using BGP UPDATE messages to achieve SD-WAN Application >> Based Segmentation >> >> >> >> BESS participants: >> >> >> >> =E2=80=9CSDWAN=E2=80=9D 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 requ= ire >> 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 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 Gatew= ay: >> >> >> >> >> >> 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 >> * >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > -- > > Gyan Mishra > > Network Engineering & Technology > > Verizon > > Silver Spring, MD 20904 > > Phone: 301 502-1347 > > Email: gyan.s.mishra@verizon.com > > > > --0000000000009c3db405a2243bc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Gyan,

As topic 1 - = Extended community which is used for=C2=A0filtering incoming updates can be= configured under=C2=A0BGP AF - there is nothing in the protocol which mand= ates that such RTs need to be configured under VRF section.=C2=A0

As of topic 2 - This is huge misconception by many people= =C2=A0who think that SAFI 128 requires MPLS transport. So let me clearly st= ate that SAFI 128 application can happily run for many years now over pure = IP transport. VPN labels and transport paradigm are completely separate. Hi= nt: RFC7510 or RFC4023. Moreover - let me also state that MPLS transport=C2= =A0does not bring any benefits other then few bits savings in the packet he= ader as=C2=A0compared with say IPv4 transport. Contrary it costs a lot of c= omplexity in the control plane and forwarding planes of the network element= s.=C2=A0

Thx,
R.
=C2=A0

On Tue, Mar 31, 2020 at 7:48 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

Robert =C2=A0& Linda=C2=A0

Sorry to inject myself into this thread.

You stated that that RFC 4364 SAFI 128 for vpn= v4 vpnv6 is the BGP control plane service layer overlay from PE to RR. Agre= ed.=C2=A0 By default all PEs including the SDWAN PE have RT Filtering enabl= ed by default and only import the RT into the VRF at the control plane leve= l if the VRF is configured with RT advertised by the RR is being imported b= y the PE, if not the SAFI 128 prefixes are dropped.=C2=A0 So I understand t= hat the BGP updates is a control plane function, but how would the routes g= et imported by the PE if the VRF is not defined on the PE.=C2=A0 RFC 4684 R= TC capability allows only the RTs imported on the PE to be advertised by th= e RR to reduced the SAFI 128 route advertised by the RR that would result i= n being filtered on the PE.

So how would that work using SAFI 128 RT to provide the network s= licing for SDWAN without VRF configured.

<= div dir=3D"auto">Also you mentioned that SAFI 128 L3 vpn services overlay c= an run over any underlay and that does not have to be MPLS based.=C2=A0 I k= now SAFI 128 works with SR-MPLS but there you are reusing the MPLS data pla= ne.=C2=A0 With SRv6 due to PM draft signaling by egress PE for end.dx insta= ntiation, so there is not any service label necessary as is with MPLS and t= hus SAFI 128 works with SRv6.

How would SAFI 128 work with IP underlay used with SDWAN?

Even with =C2=A0inter-as option b c= ab, with BGP LU you do have topmost label which is via BGP labeled unicast= .=C2=A0 For inter as options if SAFI128 would work w/o BGP LU you could jus= t run SAFI 128 over IP.=C2=A0 I have never tried but I think the control pl= ane would come up but the data plane would be broken.

Kind regards=C2=A0

Gyan=C2=A0

On Tue, Mar 24, 2020 at 9:= 26 PM Linda Dunbar <linda.dunbar@futurewei.com> wrote:

Robert,

=C2=A0

Want to confirm the following two points with you. D= o I interpret your words correctly?

=C2=A0

  • If a CPE supports traditional VPN with multip= le VRFs, and supports multiple SDWAN instances, the traditional VRF configu= ration is still same which are carried by BGP Route Target Extended community. =C2=A0
  • For the = SDWAN Instances supported by the same CPE, we can use Extended Community wi= th a different name (say SDWAN Target ID). When the SDWAN Target ID is used= , the SAFI 128 can be used for routes for the SDWAN instance, =C2=A0with the exception that the = label in the NLRI is not the MPLS label carried by the data packets . =C2= =A0

=C2=A0

Thank you.

=C2=A0

Linda Dunbar

From: Robert Raszuk <robert@raszuk.net>
Sent: Tuesday, March 24, 2020 3:32 AM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: Huaimo Chen <huaimo.chen@futurewei.com>; idr@ietf.org; bess@ietf.org
Subject: Re: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-s= afi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI<= /p>

=C2=A0

Hi Linda,

=C2=A0

Nope you do not need VRFs. RT construct works at the= control plane level. VRF may be useful for traffic separation purposes on = multitenant=C2=A0CPEs or if you would like to relax requirements for unique= IP across SDWAN sites - but not a must otherwise.=C2=A0

=C2=A0

My main point was=C2=A0 that BGP SAFI 128 gives you = for free transport for multiple routing contexts so why not leverage=C2=A0i= t as is?=C2=A0

=C2=A0

Moreover you may suddenly=C2=A0also discover that RT= C (RFC4684) is your SDWAN=C2=A0friend too.=C2=A0

=C2=A0

Many=C2=A0thx,
R.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Tue, Mar 24, 2020 at 5:15 AM Linda Dunbar <linda.dunbar@f= uturewei.com> wrote:

Robert,

=C2=A0

Thank you very much for the feedback.

=C2=A0

If using your suggested Route Target approach to rep= resent the SDWAN Instance ID, does it mean that a SDWAN Edge has to use the= same approach to configure the VRF for SDWAN instances?

If the edge node supports both traditional VPN and S= DWAN, will it cause confusion for RT to represent both?

=C2=A0

RT is encoded in the Extended_Communities Path Attri= bute, SAFI 128 is encoded in the MP_REACH_NLRI Path Attribute.

=C2=A0

What do you mean by saying =E2=80=9Cdifferent name t= o Route target(s) carried in the SAFI 128=E2=80=9D? =C2=A0

Do you mean having a different name (say SDWAN_Targe= t) in Extended_Communities Path Attribute, and have MP_REACH_NLRI Path Attr= ibute including the SAFI 128?

=C2=A0

SDWAN Instance ID is for the control Plane, not to b= e carried by the data packets. SAFI 128 for VPN has the Label encoded in th= e NLRI field that is to be carried by the data packets. But SDWAN Instance ID is not carried by the Data Packets. Is it correct? <= u>

=C2=A0

Thank you.

Linda

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: Robert Raszuk <robert@raszuk.net>
Sent: Monday, March 23, 2020 2:28 PM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: Huaimo Chen <huaimo.chen@futurewei.com>; idr@ietf.org; bess@ietf.org
Subject: Re: [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-s= afi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI<= /p>

=C2=A0

Hi Linda,

=C2=A0

I think you are mixing data plane and control plane.= =C2=A0

=C2=A0

In SDWAN=C2=A0data plane is of no issue as you are i= nterconnecting sites in a given VPN over mesh of secure tunnels.=C2=A0

=C2=A0

You are asking how to keep control plane separate=C2= =A0between VPN instances. This is precisely what RFC4364 does already and R= T import/export is used to indicate the instance which given set of reachability belongs. Why to reinvent the wheel and do someth= ing new just for the heck of it :) ?=C2=A0

=C2=A0

To be original you can at best invent=C2=A0a differe= nt name to Route target(s) carried in the SAFI 128 but let's keep the m= echanism=C2=A0the same. That would be my suggestion.

=C2=A0

Kind regards,

R.

=C2=A0

PS. While this is obvious for some many folks are st= ill confused. RFC4364 does not need to run over MPLS data plane. It can run= over IPSec or over DTLS or over UDP/IP just fine.=C2=A0

=C2=A0

On Mon, Mar 23, 2020 at 6:47 PM Linda Dunbar <linda.dunbar@f= uturewei.com> wrote:

<= div>

IDR experts:

=C2=A0

SDWAN is an overlay network arching over multiple ty= pes of networks. A SDWAN edge node may need to map client traffic to differ= ent 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.

=C2=A0

We would like to hear feedback from IDR group on usi= ng similar method as =C2=A0Binding MPLS Labels to Address Prefixes [RFC8277= ] to bind SDWAN Instance ID to =C2=A0prefixes.

=C2=A0

When =C2=A0MPLS VPN SAFI (=3D128) is present, MPLS l= abel is carried by NLRI [RFC8277] as:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Length=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Label=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |Rsrv |S|<= u>

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Prefix=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= ~

=C2=A0=C2=A0=C2=A0=C2=A0 ~=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Figure 2: N= LRI with One Label

=C2=A0

We would like to =C2=A0propose the SDWAN Instance ID= being encoded in the Label field as follows when SDWAN SAFI (=3D74 allocat= ed by IANA) is used,:

=C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3=

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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

= =C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+

= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Length=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SDWAN Instance ID (Label)=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |Rsrv |S|

= =C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+

= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Prefix=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ~=

= =C2=A0=C2=A0=C2=A0=C2=A0 ~=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0|

= =C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 =C2=A0NLRI with SDWAN Instance ID.

=C2=A0

Greatly appreciate any comments or other suggestions= ..

=C2=A0

<= div lang=3D"EN-US">

Thank you,

Linda Dunbar

=C2=A0

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

=C2=A0

Hi Linda,=

=C2=A0

=C2=A0 = =C2=A0 It seems that using another SAFI is a possible solution.

=C2=A0

Best Rega= rds,

Huaimo

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

=C2=A0

Huaimo,

=C2=A0

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 (=3D128) to = avoid confusion, right?

=C2=A0

Linda

=C2=A0

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

=C2=A0

Hi Linda,

=C2=A0

=C2=A0 =C2=A0 It seems that a= label may be used as an=C2=A0"Identifier" to differentiate SD-WA= N Segmentation.

=C2=A0

Best Regards,

Huaimo

From: Idr <idr-b= ounces@ietf.org> on behalf of Linda Dunbar <linda.dunbar@futurewei.com&g= t;
Sent: Thursday, March 19, 2020 1:22 PM
To: idr@ietf.org <idr@ietf.org&g= t;
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?

=C2=A0

BGP Experts,

=C2=A0

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

=C2=A0

Thank you.

Linda

=C2=A0

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?

=C2=A0

Based on Basil=E2=80=99s comment on needing an identifier to differentia= te SDWAN instances, I added a section to =C2=A0draft-dunbar-bess-bgp-sdwan-= usage . Want to hear people=E2=80=99s feedback.

=C2=A0

3.1=C2=A0=C2=A0=C2=A0 Requirements

3.1.1Supporting Multiple SDWAN Segmentations

The term =E2=80=9Cnetwork segmentation=E2=80=9D is used extensively in S= DWAN deployment. In general (and in this document), the =E2=80=9CNetwork Se= gmentation=E2=80=9D is referring to the process of dividing the network int= o logical sub-networks using isolation techniques on a forwarding device such as a switch, router, or firewall. For a homogeneous network, s= uch as MPLS VPN or Layer 2 network, VRF or VLAN are used to separate networ= k 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 655= 35, to differentiate different SDWAN segmentations.. When using BGP to cont= rol the SDWAN networks, the Private AS numbers are carried by the BGP UPDAT= E messages to their corresponding RRs.

=C2=A0

Greatly appreciate any feedback on this description.

=C2=A0

Is there any scenario that Private AS cannot be used?

=C2=A0

Thank you very much.

=C2=A0

Linda Dunbar

=C2=A0

From: Najem, Basil <basil.najem@bell.ca>
Sent: Friday, February 7, 2020 3:02 PM
To: Linda Dunbar <linda.dunbar@futurewei.com>; bess@ietf.org
Cc: draft-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

=C2=A0

=C2=A0=

=C2=A0=

Hi Linda;<= /u>

=C2=A0=

The SD-WAN Segment i= s part of the SD-WAN fabric; in other words, there could be more than one S= egment over a single underlay depending on the design and the business requ= irements.

=C2=A0=

Each Segment represe= nts 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 ident= ify and build the routing the table for each Segment (based on the Segment ID).

=C2=A0=

Hope this helps.

=C2=A0=

Regards;

=C2=A0=

Basil<= u>

=C2=A0

=C2=A0=

From: Linda Dunbar <linda.dunbar@futurewei.com>
Sent: February-03-20 10:40 AM
To: Najem, Basil <basil.najem@bell.ca>; bess@ietf.org
Cc: draft-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

=C2=A0

Basil,

=C2=A0

Thank you very much for the comments.

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

=C2=A0

As for your suggestion of Segment and Segment ID of a SDWAN node (to be = included in the BGP UPDATE), does the =E2=80=9CSegment=E2=80=9D mean the di= fferent Underlay?

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

Do you mean C-PE1 has 3 WAN =E2=80=9Csegments=E2=80=9D?

If not, can you elaborate more?

=C2=A0

=C2=A0

=C2=A0

Thanks, Linda

=C2=A0

From: Najem, Basil <basil.najem@bell.ca>
Sent: Sunday, February 02, 2020 5:48 PM
To: Linda Dunbar <linda.dunbar@futurewei.com>; bess@ietf.org
Cc: draft-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

=C2=A0

=C2=A0=

Hello Linda;<= u>

=C2=A0=

I haven=E2=80=99t go= ne through the entire document; however, I have the following quick comment= s

=C2=A0=

  1. Regarding the following paragraph:

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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.

=C2=A0

The traffic that traverses the privet networks can be either encrypte= d or unecrypted (in other words, the assumption that the traffic is NOT enc= rypted is not always correct). I would change the parpagaph to the following (for clarity):<= /p>

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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.

=C2=A0

=C2=A0

  1. Another thing t= hat 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 Se= gment. Since the Segment is a =E2=80=9Crouting domain=E2=80=9D, the BGP update will be exchanged with th= e memebers of a particular Segment.

=C2=A0

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

=C2=A0

Any feedback is welcomed and it= =E2=80=99s highly appreciated.

=C2=A0

Regards;

=C2=A0

Basil

= =C2=A0

=C2=A0

From: Linda Dunbar <linda.dunbar@futur= ewei.com>
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 = description of using BGP UPDATE messages to achieve SD-WAN Application Base= d Segmentation

=C2=A0<= /u>

BESS participants:

=C2=A0

=E2=80=9CSDWAN=E2=80=9D networks is ch= aracterized by:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Enable direct Internet = access from remote sites, instead hauling all traffic to Corporate HQ for c= entralized policy control.

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

=C2=A0

=C2=A0

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, =C2=A0assuming 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 communic= ates with the Payment Gateway:

=C2=A0

=C2=A0

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

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MP-NLRI Path Attribute:

      • 30.1.1.x/24

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tunnel Encap Path Attribute

      • IPsec Attributes for PaymentGW ->C-PE2

=C2=A0

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

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MP-NLRI Path Attribute:=

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

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TunnelEncap Path Attribute:

      • Any node to C-PE2

=C2=A0

=C2=A0

Your feedback is greatly appreciated.

=C2=A0

Thank you very much.

=C2=A0

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

_______________________________________________
Idr mailing list
Idr@ietf.org
https://= www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--

Gyan=C2=A0 = Mishra

Network Engineering & Technology=C2=A0

Verizon=C2=A0

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com



--0000000000009c3db405a2243bc8--