Re: [Idr] Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt

[Robert Raszuk <[e-mail]>]

Tony

Yes you have RD *prefix* not RD fixed value there which is a good progress
;).

But you just can not use RD to even query prefixes (of those SAFIS which
use it) in any automated way simply as your PE does not know it. Human
could use it but this is I hope not the main motivation of your draft.

So if you want to query say VPN safi you need RT + NLRI not RD. In those
query you would define and use the notion of ANY_RD flag implicitely or
explicitely.

Till someone at next ietf proposes new safi to auto discover all RDs in the
network which I hope will never happen use of RD for filtering or query
should be removed.

Best,
R.

On Jul 19, 2016 2:56 PM, "Tony Przygienda" <[e-mail]> wrote:

> OK, agreed in principle on 7.9.
>
> In fact, we were oscillating between RD (with or without prefix length)
> filter + address prefix filter and just 'NLRI filter' but given NLRI we
> need to add RD anyway in there. The RD filter allows you to wildcard the
> RD, i.e. you can e.g. request prefix/address update from your peer without.
>
> We can start to split hair as well that section 8.2.1 does NOT give you
> the flexibility to do anything else but structure the RD ...
>
> Overall, I think the Pandora's box is open and it's better to allow an RD
> filter to at least wildcard RDs ...
>
> --- tony
>
> On Tue, Jul 19, 2016 at 5:24 AM, Robert Raszuk <[e-mail]> wrote:
>
>> Tony,
>>
>> Section 7.9 only mentions that RD *MAY BE* structured to include VLAN ID
>> but equally well it says  that it may be locally generated.
>>
>> As someone pointed at this IETF term "MAY" = "MAY NOT" hence any actions
>> based on that is likely to fail.
>>
>> Said this while perhaps someone can use your RD type to manually query
>> the peer for subset of routes then for any automated action .. which is
>> what is really need say when you modify RT import list it will fail.
>>
>> Bottom line I think we should not add elements to protocols which are not
>> guaranteed to work if for nothing else then to reduce operational issues in
>> multi vendor environments.
>>
>> Thx
>> R.
>>
>
>
>
> --
> *We’ve heard that a million monkeys at a million keyboards could produce
> the complete works of Shakespeare; now, thanks to the Internet, we know
> that is not true.*
> —Robert Wilensky
>