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:26 AM <slitkows.i...@gmail.com> wrote: > Hi Adrian, > > My point is really tied to what will happen when RTC is enabled > (considering > draft-ietf-idr-rtc-no-rt). The behavior will be to drop the routes that > don't have an RT which will break existing Internet families behavior. > " When RTC is applied, on a particular BGP session, to routes of other > address families, the default behavior MUST be that routes without > any RTs are not distributed on that session. This default "default > behavior" applies to all AFI/SAFIs for which a different default > behavior has not been defined." > > Let me run this to IDR to get their feedback (as draft-ietf-idr-rtc-no-rt > is > owned by IDR). > > Stephane > > -----Original Message----- > From: Adrian Farrel <adr...@olddog.co.uk> > 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
