Re: [bess] FW: Closing on Stephane's open issue with draft-ietf-bess-datacenter-gateway => Requesting feedback from IDR
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. 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 < <mailto:slitkows.i...@gmail.com> slitkows.i...@gmail.com> wrote: Hi Robert, Thanks for your feedback. Please find some comments inline. Stephane From: Robert Raszuk < <mailto:rob...@raszuk.net> rob...@raszuk.net> Sent: lundi 8 juin 2020 11:55 To: <mailto:slitkows.i...@gmail.com> slitkows.i...@gmail.com Cc: idr@ietf. org < <mailto:i...@ietf.org> i...@ietf.org>; BESS < <mailto:bess@ietf.org> bess@ietf.org> 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. 2. 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 < <mailto:slitkows.i...@gmail.com> slitkows.i...@gmail.com> 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 < <mailto:adr...@olddog.co.uk> adr...@olddog.co.uk> Sent: jeudi 4 juin 2020 19:31 To: <mailto:slitkows.i...@gmail.com> slitkows.i...@gmail.com Cc: <mailto:bess-cha...@ietf.org> bess-cha...@ietf.org; <mailto:bess@ietf.org> bess@ietf.org; <mailto:draft-ietf-bess-datacenter-gate...@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 c
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 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 would still be using the RT anyway. > > That, we think, disposes of the "RT or RO?" question. > > Now, we can go back to the original formulation of the question: is it OK > to > use RT with "non-VPN IP addresses"? Well, we consulted around a bit > privately amongst some BGP experts, and we couldn't find a
Re: [bess] FW: Closing on Stephane's open issue with draft-ietf-bess-datacenter-gateway => Requesting feedback from IDR
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. 2. 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 mailto:slitkows.i...@gmail.com> > 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 mailto:adr...@olddog.co.uk> > Sent: jeudi 4 juin 2020 19:31 To: slitkows.i...@gmail.com <mailto:slitkows.i...@gmail.com> Cc: bess-cha...@ietf.org <mailto:bess-cha...@ietf.org> ; bess@ietf.org <mailto:bess@ietf.org> ; draft-ietf-bess-datacenter-gate...@ietf.org <mailto: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 would still be using the RT anyway. That, we think, disposes of the "RT or RO?" question. Now, we can go back to the original formulation of the question: is it OK to use RT with "non-VPN IP addresses"? Well, we consulted around a bit privately amongst some BGP experts, and we couldn't find anyone to say it was actually a problem. And (of course) no one raised the issue in WG last call - but Matthew might claim that is because the document was only lightly reviewed, and Stephane might claim that this is because he had already raised the point. Obviously, some of the authors know a bit about BGP, and Eric was a lead author on 4364 and drove a lot of the details of what we wrote. Two points in closing: - If someone can show that we break something, we will have to fix it. - If the chairs want to run this point past IDR and BESS explicitly, that would be fine. Hope this helps. Best, Adrian ___ BESS mailing list B
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. 2. 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. 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 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 would still be using the RT anyway. > > That, we think, disposes of the "RT or RO?" question. > > Now, we can go back to the original formulation of the question: is it OK > to > use RT with "non-VPN IP addresses"? Well, we consulted around a bit > privately amongst some BGP experts, and we couldn't find anyone to say it > was actually a problem. And (of course) no one raised the issue in WG last > call - but Matthew might claim that is because the document was only > lightly > reviewed, and Stephane might claim that this is because he had already > raised the point. Obviously, some of the authors know a bit about BGP, and > Eric was a lead author on 4364 and drove a lot of the details of what we > wrote. > > Two points in closing: > - If someone can show that we break something, we will have to fix it. > - If the chairs want to run this point past IDR and BESS explicitly, that > would be fine. > > Hope this helps. > > Best, > Adrian > > > ___ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] FW: Closing on Stephane's open issue with draft-ietf-bess-datacenter-gateway => Requesting feedback from IDR
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 would still be using the RT anyway. That, we think, disposes of the "RT or RO?" question. Now, we can go back to the original formulation of the question: is it OK to use RT with "non-VPN IP addresses"? Well, we consulted around a bit privately amongst some BGP experts, and we couldn't find anyone to say it was actually a problem. And (of course) no one raised the issue in WG last call - but Matthew might claim that is because the document was only lightly reviewed, and Stephane might claim that this is because he had already raised the point. Obviously, some of the authors know a bit about BGP, and Eric was a lead author on 4364 and drove a lot of the details of what we wrote. Two points in closing: - If someone can show that we break something, we will have to fix it. - If the chairs want to run this point past IDR and BESS explicitly, that would be fine. Hope this helps. Best, Adrian ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
