Re: [Idr] RFC 4684 pedantry - routes with no Route Target

[Robert Raszuk <[e-mail]>]

Hi Jeff,

Naturally I fully agree with your conclusion ;-)

> - Permit a per-peer, per-AFI/SAFI knob to enable/disable RT-C processing.
> - Provide for exceptions to the rule and document them.

I think all implementations of RTC I looked at do both of those
already (modulo your definition of "RT-C processing").

You are nowhere mentioning the need for NULL-RT encoding which sort of
leads me to guess that you want this to be a static config on both
ends per peer/per safi. Is this what the hidden context is ?

If so I would be actually fine with that too. Just let's spell it out
for clarity.

After all you provision SAFI once for all so extra setup twick for MDT
safi as example should be peanut.

Best,
R.


On Wed, Jun 4, 2014 at 10:40 PM, Jeffrey Haas <[e-mail]> wrote:
> On Wed, May 21, 2014 at 06:46:03PM +0200, Robert Raszuk wrote:
>> Assume I do have a valid SR application to filter tiny subset of
>> Internet table. For this I can mark such tiny subset of routes with
>> RTs, enable RTC and activate RT filtering on IPv4 session.
>
> After letting this thought get some of my background thinking time during a
> very nice vacation, I think you've identified a key argument.  When the
> expectation is you want to apply RT-C to an AF that isn't normally VPN-like
> (and we've identified we may want to generally do this), the routes may not
> be normally tagged with RTs.
>
> This suggests the behavior we want may be:
> - Permit a per-peer, per-AFI/SAFI knob to enable/disable RT-C processing.
>   JUNOS, e.g., filters VPN families by default.
> - Provide for exceptions to the rule and document them.
>
> That second point covers the MDT scenario.  It also suggests that IDR should
> probably make sure the other WGs using BGP as a transport for their VPNs or
> otherwise using RTs should be reminded that RT-C exists and their extensions
> had best document their interaction with it if they inconsistently RT tag
> their routes.
>
> -- Jeff