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

[Xuxiaohu <[e-mail]>]

________________________________
发件人: Idr [[e-mail]] 代表 Robert Raszuk [[e-mail]]
发送时间: 2016年7月19日 21:06
收件人: Tony Przygienda
抄送: idr wg
主题: Re: [Idr] Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt


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.



[Xiaohu] In fact, this draft (https://tools.ietf.org/html/draft-xu-bess-l3vpn-prefix-orf-02) is just intended to achieve the above goal (i.e., requesting partial routes of a given VPN) .



Best regards,

Xiaohu



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]<mailto:[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]<mailto:[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