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

[Robert Raszuk <[e-mail]>]

​Hey Tony,​


> I think I admitted that getting rid of RD query is reasonable (as long we
> understand that any other query means "any RD")
>

​Done.

Absolutely valid, albeit subtle point. "zero or more route refresh options"
> should be specified.
>

​Great.​

Obsoleting 70 when 74 is present is simplifying things. We can keep mixture
> of 70 and 74 but implementation will get pretty hairy when you talk
> details. We talked that through with Cisco co-authors @ length and actually
> changed from "you can do both in parallel" to "nah, 74 obsoleting 70 is
> much better/cleaner/easier".
>

​Yes one
​SAFI ​
is much cleaner, but you can't break per AFI/SAFI refresh. ​
​So now I consider this fixed. ​



> ok, then as I said, we agree to disagree and then we don't have currently
> a really practical solution to the cases mentioned in 1.1 and yes, RTC can
> be used for that if you're willing to maintain RTs for all possible sets
> you may need to refresh and the draft very explicitly acknowledges that
> already.
>

​Possible sets .. hmmm how about this to address route types:

1 RT per route type of a given AFI/SAFI ... not much burden at all - for
EVPN you burn 5-6 RTs for entire network. ​


> Given you know those sets upfront. If you deploy EVPN today and new route
> type gets introduced (type-6) you better go and reconfigure all your
> routers in the networks with this type-6-per-EVI=a new RT knowledge to
> satisfy the "I need now type-6 routes for the EVIs I configured for
> multicast" use case. Quite a lot of configuration there since it's
> combinatorial with every parameter.
>

​Not at all .. forgot that RTs can be applied on RR per route type of NLRI
on inbound. Your colleagues already defined that in the other work :) ​

Minimal configuration, existing protocols and all benefits.

Cheers,
R.