Re: [bess] [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI
Thanks Robert!! For me to really comprehend I have to have to put the tire to the road and test in my Dev lab. Any caveats with Cisco XR? Ping me off list on cisco specific reply. Kind regards Gyan On Tue, Mar 31, 2020 at 6:43 AM Robert Raszuk wrote: > 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 import >> 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 if >> the VRF is not defined on the PE. RFC 4684 RTC capability allows only the >> 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 due >> 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 MPLS >>>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 ; i...@ietf.org; >>> bess@ietf.org >>> *Subject:* Re: [Idr] Seeking feedback of >>> draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance >>> 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
Re: [bess] WG adoption poll for draft-gmsm-bess-evpn-bfd-04
Support adoption. mike From: Bocci, Matthew (Nokia - GB) Date: Wed, Feb 26, 2020 at 9:42 AM Subject: WG adoption poll for draft-gmsm-bess-evpn-bfd-04 To: draft-gmsm-bess-evpn-...@ietf.org , bess@ietf.org Cc: bess-cha...@ietf.org Hello, This email begins a two-weeks WG adoption poll for draft-gmsm-bess-evpn-bfd-04 [1] . Please review the draft and post any comments to the BESS working group list. We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document won't progress without answers from all the authors and contributors. Currently, there are no IPR disclosures against this document. If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll for adoption closes on Wednesday 11th March 2020. Regards, Matthew and Stephane ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] [Idr] Seeking feedback of draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance ID in the NLRI
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 import > 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 if > the VRF is not defined on the PE. RFC 4684 RTC capability allows only the > 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 due > 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 MPLS >>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 ; i...@ietf.org; >> bess@ietf.org >> *Subject:* Re: [Idr] Seeking feedback of >> draft-dunbar-idr-sdwan-port-safi using SDWAN SAFI to encode SDWAN Instance >> 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 “different name to Route target(s) carried in >> the SAFI 128”? >> >> Do you mean having a different name (say SDWAN_Target)
