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

[Robert Raszuk <[e-mail]>]

Just typo fix of the last paragraph ...

s/96 bit field would not be/96 bit field would be/

So it should read:

As to the encoding I would see that to be complaint with current
RFC4684 (96 bit field would 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 :)

Sorry,
r.

On Fri, May 30, 2014 at 4:29 PM, Robert Raszuk <[e-mail]> wrote:
> 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