[bess] FW: Closing on Stephane's open issue with draft-ietf-bess-datacenter-gateway => Requesting feedback from IDR

[[e-mail]]

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 <[e-mail]> 
Sent: jeudi 4 juin 2020 19:31
To: [e-mail]
Cc: [e-mail]; [e-mail];
[e-mail]
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