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

[Tony Przygienda <[e-mail]>]

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