Re: [bess] [Idr] FW: Closing on Stephane's open issue with draft-ietf-bess-datacenter-gateway => Requesting feedback from IDR
On Mon, Jun 8, 2020 at 11:58 AM wrote: > I’m ok with that, but in such a case, you have to ensure that everything > will work fine when RTC is used: at least specify the behavior when no RT > are attached. As mentioned, rt-no-rt draft currently says that routes are > not advertised. > > Gyan> Understood and agreed that behavior for both RT and no RT attached > behavior should be added. Agreed that RTC explicitly states if RT > membership does not exist then the routes are not advertised. The behavior > with SAFI 1 is the same as SAFI 128 with regards to RTC support. > > *From:* Robert Raszuk > *Sent:* lundi 8 juin 2020 17:07 > *To:* slitkows.i...@gmail.com > *Cc:* idr@ietf. org ; BESS > *Subject:* Re: [bess] FW: Closing on Stephane's open issue with > draft-ietf-bess-datacenter-gateway => Requesting feedback from IDR > > > > Hi, > > > > > [SLI] It could work if: we prevent usage of RTC for these families > > > > Actually I am not sure we need to prevent anything. Honestly I would leave > it for the proper operator's configuration. > > > > RTC is not something on by default in any AFI/SAFI. > > > > Thx a lot, > R. > > > > > > > > On Mon, Jun 8, 2020 at 4:48 PM wrote: > > Hi Robert, > > > > Thanks for your feedback. > > Please find some comments inline. > > > > Stephane > > > > > > *From:* Robert Raszuk > *Sent:* lundi 8 juin 2020 11:55 > *To:* slitkows.i...@gmail.com > *Cc:* idr@ietf. org ; BESS > *Subject:* Re: [bess] FW: Closing on Stephane's open issue with > draft-ietf-bess-datacenter-gateway => Requesting feedback from IDR > > > > Stephane, > > > > Two points ... > > > >1. It is not clear to me that draft-ietf-bess-datacenter-gateway >recommends to use RTC for anything - do they ? If not there is no >issue. > > [SLI] Right, but nothing prevents someone to activate it or it can be > activated “by inheritance” if sessions already runs VPNv4 for instance with > RTC. > > > >1. Also note that RTC can be enabled on a per AF basis hence even if >you use it say for SAFI 128 you do not need to use it for SAFI 1. > > [SLI] RFC4684 is AFI/SAFI agnostic. I’m not aware of per-AFI/SAFI scoping > of RT membership from an implementation point of view. You can do it by > splitting sessions usually. > > > > [SLI] It could work if: we prevent usage of RTC for these families, or we > specify the default behavior of RTC for AFI/SAFI 1/1, 2/1 when there is no > RT (distribute routes that don’t have an RT). > > > > > > As a general comment I do not see any issues using RTs on non VPN SAFIs. > > > > Thx,, > > R. > > > > On Mon, Jun 8, 2020 at 10:34 AM wrote: > > Hi IDR WG, > > We have a draft that was on WGLC which introduces the usage of Route > Targets > on Internet address families to allow automated filtering of gateway > routes. > I raised a concern on a potential issue happening when Route Target > constraint is deployed on these sessions. > > Internet address families don't use RTs today, and are propagated following > the BGP propagation rules. When applying an RT and when having RTC deployed > on the session (RTC not being family aware), propagation of Internet routes > that don't have an RT may be stopped because of the behavior defined in > draft-ietf-idr-rtc-no-rt. This will so break the existing default behavior > of Internet SAFIs. > > We would like to get IDR's feedback on this topic. > > Thanks, > > Stephane > BESS co-chair > > > -Original Message- > From: Adrian Farrel > Sent: jeudi 4 juin 2020 19:31 > To: slitkows.i...@gmail.com > Cc: bess-cha...@ietf.org; bess@ietf.org; > draft-ietf-bess-datacenter-gate...@ietf.org > Subject: Closing on Stephane's open issue with > draft-ietf-bess-datacenter-gateway > > Hi, > > John and I had a chat today about what we perceive is Stephane's open > issue. > > What we think the concern is is that we are using RTs in conjunction with > normal (i.e., non-VPN) routes. We do this to allow gateways to filter their > imports based on the RT that applies to the SR domain that it serves. > > An option was to use the Route Origin extended community instead. > > RFC 4360, which introduces both the Route Target and the Route Origin > extended communities and gives some guidance. Loosely expressed, the RT > says > which routers should import, the RO says which routers have advertised. In > both cases, the text suggests that "One possible use of the community is > specified in RFC4364" which implies that there are other accepta
Re: [bess] [Idr] FW: Closing on Stephane's open issue with draft-ietf-bess-datacenter-gateway => Requesting feedback from IDR
On Mon, Jun 8, 2020 at 10:49 AM wrote: > Hi Robert, > > > > Thanks for your feedback. > > Please find some comments inline. > > > > Stephane > > > > > > *From:* Robert Raszuk > *Sent:* lundi 8 juin 2020 11:55 > *To:* slitkows.i...@gmail.com > *Cc:* idr@ietf. org ; BESS > *Subject:* Re: [bess] FW: Closing on Stephane's open issue with > draft-ietf-bess-datacenter-gateway => Requesting feedback from IDR > > > > Stephane, > > > > Two points .. > > > >1. It is not clear to me that draft-ietf-bess-datacenter-gateway >recommends to use RTC for anything - do they ? If not there is no >issue. > > [SLI] Right, but nothing prevents someone to activate it or it can be > activated “by inheritance” if sessions already runs VPNv4 for instance with > RTC. > > > >1. Also note that RTC can be enabled on a per AF basis hence even if >you use it say for SAFI 128 you do not need to use it for SAFI 1. > > [SLI] RFC4684 is AFI/SAFI agnostic. I’m not aware of per-AFI/SAFI scoping > of RT membership from an implementation point of view. You can do it by > splitting sessions usually. > > > > [SLI] It could work if: we prevent usage of RTC for these families, or we > specify the default behavior of RTC for AFI/SAFI 1/1, 2/1 when there is no > RT (distribute routes that don’t have an RT). > > > > > > As a general comment I do not see any issues using RTs on non VPN SAFIs. > > [Gyan] Technically there is no issues that I know of using RT with SAFI > 1. As RT is carried in extended community attribute it is common in > certain cases where both standard and extended communities are propagated > to edge Non VPN award edge CEs in a IP VPN use case. In that use case as > well in VRF lite non MPLS IP VPN use cases where RTs can be utilized for RT > import of prefixes into a VRF. As Stephane mentioned with RFC 4684 RTC > membership is AFI/SAFI independent, so if RTC is used it would apply to > all SAFI using RT which in this case applies as well to SAFI 1. > Thx,, > > R. > > > > On Mon, Jun 8, 2020 at 10:34 AM wrote: > > Hi IDR WG, > > We have a draft that was on WGLC which introduces the usage of Route > Targets > on Internet address families to allow automated filtering of gateway > routes. > I raised a concern on a potential issue happening when Route Target > constraint is deployed on these sessions. > > Internet address families don't use RTs today, and are propagated following > the BGP propagation rules. When applying an RT and when having RTC deployed > on the session (RTC not being family aware), propagation of Internet routes > that don't have an RT may be stopped because of the behavior defined in > draft-ietf-idr-rtc-no-rt. This will so break the existing default behavior > of Internet SAFIs. > > We would like to get IDR's feedback on this topic. > > Thanks, > > Stephane > BESS co-chair > > > -Original Message- > From: Adrian Farrel > Sent: jeudi 4 juin 2020 19:31 > To: slitkows.i...@gmail.com > Cc: bess-cha...@ietf.org; bess@ietf.org; > draft-ietf-bess-datacenter-gate...@ietf.org > Subject: Closing on Stephane's open issue with > draft-ietf-bess-datacenter-gateway > > Hi, > > John and I had a chat today about what we perceive is Stephane's open > issue. > > What we think the concern is is that we are using RTs in conjunction with > normal (i.e., non-VPN) routes. We do this to allow gateways to filter their > imports based on the RT that applies to the SR domain that it serves. > > An option was to use the Route Origin extended community instead. > > RFC 4360, which introduces both the Route Target and the Route Origin > extended communities and gives some guidance. Loosely expressed, the RT > says > which routers should import, the RO says which routers have advertised. In > both cases, the text suggests that "One possible use of the community is > specified in RFC4364" which implies that there are other acceptable uses. > > 4364 implies that the RO is used "to uniquely identify the set of routes > learned from a particular site." That is (my words), to apply a filter on > top of the RT to prevent re-import by a site of routes that match the RT > and > that were advertised by other entry points to the site. Indeed, the RO > would > seem to be used (in the 4364 case) only when the RT is also in use. > > We appreciate that the distinction is pretty delicate, but we think we are > right to use RT in this case because we are filtering to import, not to > avoid importing. Furthermore, if we used the RO then, to be consistent with > 4364, we wo
