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

Robert, fine, agreed to disagree. We see over next rev of the draft ...

We will extend section 1.1. further and frankly, I think it's sufficient
today (otherwise we wouldn't bother wasting our time writing/figuring that
out).

RD we need wildcard semantics, beside that I agree that there isn't
necessary enough justification for RD otherwise without assuming further
semantics overload of RDs (bad thing). So maybe not allowing and RD
options/filter and saying "RD is implied wildcard" is good enough. My
feeling tells me it's not but it can be added later.

I cannot parse the RTC comment you're making really. I suggest to
distinguish very tightly between "querying", "registering" and "filtering".

RTC is a intermixed "registration/filtering" mechanism, refresh is a
"querying" mechanism. I think we'll add RTs to the filters for the option
refresh and with that you can either "register via/filter RTCs" _or_
specifically request refresh for an RTC (which will be filtered by existing
RTCs since RTC is the "overall filtering").

registering is good if you want full refresh of something beside initial
open but the filters must be very orthogonal to do it efficiently and
decoupled from each other (transactional) while RTC is simply a accept/deny
language which is hard to closure compute (sorry, can't save the linear
programing vs. transitive closure algebra distinction here and if it's not
clear it will become painfully clear in implementation only).

filtering is the NOT of registering really and RTC is a ball-of-hair where
the deny are really "NOTs" and possibly filters rather then registers.
While empty RTC is a "register all" implicitly.

Refresh is querying. Something pretty different from "register". Semantics
is "I may have registered (implicitly) but I may have filtered on my side
for some reason and now I need the information again". Yes, one can play
great games with filtering/registering to emulate querying as one can
surely use screwdrivers to open tin cans. A very orthogonal algebra of
independent RTC filters would have been possibly equivalent to the route
refresh options but alas between the accept/reject/defer/immediate I would
always chose to have a clean "orthogonal filter transactional query"
architecture here ... (sorry, I speak databas'ish here since this is all
really a big partitioned/distributed/loosely synchronized database problem
and has nothing to do really with BGP carrying the bits).

Your answers to "on RTC change you'll get flooded with all the stuff again"
and "how do I get type-6 only without causing subsequent flooding when I
unwind the RTC filter" are still surepitiously missing.

If your  point "you never _query_ in BGP, we SHALL only register" then
route-refresh was the battle to be fought, this particular Rubicon has been
crossed long time ago as you know (and it took good many years until a
similar discussion I had a _looong_ time ago about "you need Begin
Transaction/End Transaction" and was ignored caused enough real pain to
lead to Extended Route Refresh).

no, to nastepnej wersi ;-) ;-)

--- tony

On Thu, Jul 21, 2016 at 9:22 AM, Robert Raszuk <[e-mail]> wrote:

> Tony,
>
> Sorry to be a bit stubborn here but I have not seen any valid reason for
> this work.
>
> Yes you have listed bunch if reasons in the original reply but non of
> those apply.
>
> Quoted below from your mail all below reasons require permanent filter not
> one time as you must not only get the NLRI once .. you MUST also get all
> updates to it when something changes supposedly also in subset way -
> otherwise you get all SAFI (all MACs which is what you are trying to avoid
> in the first place).
>
> That is critical which you seems to be missing.
>
> The debug thing is not sufficient justification.
>
> Moreover as you confirm this work is not compatible with RTC and as you
> confirmed you will not get anything over RTC filter in place. So to use one
> time refresh RTC needs to be effectively disabled.
>
> Your reasons:
>
> "The motivation for this work were scenarios where a single-shot refresh
> is needed, actually concurrent bunch of those based on configuration
> changes, peer having dropped received routes based on specs (A-D), in
> policy changes, joining VPNs, EVIs and so on. "
>
> 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