Re: [Idr] [bess] 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 <slitkows.ietf@gmail.com> 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 <robert@raszuk.net>
> *Sent:* lundi 8 juin 2020 17:07
> *To:* slitkows.ietf@gmail.com
> *Cc:* idr@ietf. org <idr@ietf.org>; BESS <bess@ietf.org>
> *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 <slitkows.ietf@gmail.com> wrote:
>
> Hi Robert,
>
>
>
> Thanks for your feedback.
>
> Please find some comments inline.
>
>
>
> Stephane
>
>
>
>
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* lundi 8 juin 2020 11:55
> *To:* slitkows.ietf@gmail.com
> *Cc:* idr@ietf. org <idr@ietf.org>; BESS <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.
>
>
>
>    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 <slitkows.ietf@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 <adrian@olddog.co.uk>
> Sent: jeudi 4 juin 2020 19:31
> To: slitkows.ietf@gmail.com
> Cc: bess-chairs@ietf.org; bess@ietf.org;
> draft-ietf-bess-datacenter-gateway@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
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD