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

[Eric Rosen <[e-mail]>]

> 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?