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

[Robert Raszuk <[e-mail]>]

Hi Eric,

I think the crux of your question and this topic sits really in
AFI/SAFI specifics.

Let's consider SAFI 128 - how good does it serve to inject to the RRs
in the network say 1M of VPN routes without any RT attached to it -
which perhaps by some bug or other action got into VPNv4 BGP table on
any of the PEs.

Take also another example of someone using RTC for SAFI 1. What good
does the RTC there serves to receive all routes - including those with
no RT attached when need is to only get just few procent on them.
Would we need to fall back to prefix ORF there ?

I am not negating that on the other side for MDT SAFI it may very well
turn useful.

So I would vote for defining NULL-RT while the default should be not
to send any routes without intersecting RT attached or we could
perhaps allow the default to be SAFI specific.

As to the encoding I would see that to be complaint with current
RFC4684 (96 bit field would not be) yet backwords compatible we can
use all Fs in all 8 octets of the RT field. It will be backwards
compatible as per RFC4360 it will never be a legal RT value (T flag is
0 for example :)

Regards,
R.


On Fri, May 30, 2014 at 3:04 PM, Eric Rosen <[e-mail]> wrote:
>
>> For that matter, I'm not convinced that it's obvious that there's a real
>> WG consensus on the proposed behavior.
>
> I think everyone agrees that it should be possible to enable RTC on a
> particular AFI/SAFI, while allowing "RT-less routes" (routes with no RTs) of
> that AFI/SAFI to be distributed.
>
> I don't know whether there is consensus on the following question:  should
> it be possible to enable RTC on a particular AFI/SAFI, while causing
> "RT-less" routes to be filtered?
>
> If we want to say that RT-less routes should always be distributed, no new
> protocol constructs are needed, just a "clarification" of the existing
> text.  I like this approach, but perhaps it won't achieve consensus.
>
> If we want to use RTC to declare dynamically whether RT-less routes are to
> be distributed or whether they are to be filtered, then we need the
> "null-RT" construct.  We would then have to decide whether (assuming RTC is
> enabled for a given AFI/SAFI):
>
> 1. RT-less routes get distributed unless we advertise null-RT,
>
> 2. RT-less routes get distributed only if we advertise null-RT.
>
> I like 1. myself (if we even need to have an option for filtering RT-less
> routes).
>
> If we need the null-RT construct, we need to specify how to code it.  Now we
> get into a backwards compatibility issue.  Perhaps it can be coded as a
> 96-bit NLRI, where the RT part looks like a transitive IPv4-address-specific
> route target with all zero in the global and local administrator fields.
> The hope is that this looks like a real RT to existing implementations, but
> won't actually match any RT.  So it would be a no-op to existing
> implementations, and newer implementations would recognize it as a null-RT.
> (An alternative would be to code null-RT as, say, an eight-bit prefix of all
> zeroes, and to use a Capability to make sure that your peer can process it.)
>
> Comments?
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr