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

[Tony Przygienda <[e-mail]>]

inline

On Sun, Jul 24, 2016 at 4:22 PM, Robert Raszuk <[e-mail]> wrote:

> Dear Antoni,
>
> The point here is not about the question if query in BGP is good or bad or
> how easy or difficult it is to implement.
>
> The points to discuss are following:
>
> #1 What parameters are used to "query" ?
>
> #2 How does defined "query" work with existing BGP protocol and extensions
> ?
>
> #3 What protocol state machine change triggers "query" action ?
>
> - - -
>
> Ad 1 -
>
> Cool that we have already accomplished consensus to get rid of RD query.
> If you do not specify anything the automatic assumptions would be *ANY* RD
> anyway if you query by anything other then NLRI prefix. Query by NLRI is
> questionable too (see below Ad 3).
>
> Now let's talk about (in)famous EVPN route types you keep bringing as
> query parameter. Please observe that RFC7432 does not define BGP capability
> per route type and only negotiates 25/70 implicitly indicating support of
> all route types. Moreover RFC7432 is very clear that to accomplish
> filtering of routes on the sender side use of RTC is recommended.
>
>
I think I admitted that getting rid of RD query is reasonable (as long we
understand that any other query means "any RD")

If you think asking for a new route-type in EVPN via AFI/SAFI refresh and
being swamped with all MAC updates is a reasonable deployment option then
we simply disagree and the operational world will tell us what is
reasonable.


>
> Ad 2 -
>
> Assume operator is using RTC so list of RT filters is populated by the
> peer outbound towards querying bgp speaker. Now issuing query for anything
> needs to be evaluated against already supported Enhanced Route Refresh
> (RFC7313) which btw you are also obsoleting here where you get full
> filtered by RTC list of interesting NLRIs for specific AFI/SAFI.
>
> On the topic of obsoleting RFC2918 I must say that I hope this is just a
> huge oversight ... Your current draft says:
>
> "When the Route Refresh Options Capability has been negotiated by both
> sides of a BGP session, both peers MUST use message types 3, 4 and 5."
>
> And message type 3 clearly states that I must have at least one refresh
> option ... quote from the field of the msg: "One or more Route Refresh
> Options"
>
> That means that I no longer can ask for refresh of the entire AFI/SAFI -
> this is pretty bad.
>

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

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".


>
>
> Ad 3 -
>
> Now the crux of all of this ...
>
> Please enumerate on the list or in the draft what exact protocol state
> machine transitions will result in automated query for subset of given
> AFI/SAFI with and without prior use of RTC and ORF filters.
>

section 1.1. in the draft and to be extended


>
> In other words I do not buy general justifications explained before,
> quote:
>
> * "now I need the information again"
>
> * " The motivation for this work were scenarios where a single-shot
> refresh is needed, actually concurrent bunch of those based on
> configuration changes,
>
> --> You need per AFI/SAFI or per RT refresh
>
> " in policy changes, joining VPNs, EVIs and so on."
>
> --> You need per AFI/SAFI or per RT refresh
>

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. 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.

Extending ORF with new filters will lead due to the accept/reject
non-computable language to full walks of which you can have one in parallel
in ORF and you chose to not answer any of the "and then you'll get flooded
on change of ORF filter anyway" observations which leads overall to an
interesting, partial treatment of the subject.

Frankly, the arguments we are engaged in are becoming repetitive by now, we
should close this discussion and see whether implementation/acceptance by
major vendors given the pressure of deployment cases we listed will lead to
acceptance or the draft will linger ...

--- tony