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

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.


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.


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.

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

- - - - - -

Conclusion:

Asking for subset of AFI/SAFI routes based on specific query does not in
any way allows to assure that you will get full set of routes which are
actually needed for correct operation.

BGP standardized use of Route Target Ext Community to filter routes both on
inbound as well as optimize it also outbound. If you modify RT import
policy say you add one RT I agree that asking for just that one RT may be
much better - but here RTC is exactly what comes as solution as generating
one update in SAFI 132 will result in getting such delta of routes.

It also needs to be stated that there is no overhead to add few RTs (one
per NLRI type) for those new address families which bring the concept of
NLRI types (EVPN, BGP-LS etc ...) hence the objectives of this work can be
easily achieved today with existing specifications.

Best regards,
Robert.