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, in the draft there are enough of first examples, I repeated several
times other ones we were seeing outside the idr room and later and each
time it seems it is being dismissed and discussion goes into abstract
"let's do publish-subscribe because it's better". So I won't repeat all
that again. I suggest we will update the draft with more and more of stuff
we saw and justified talking about it.

You didn't respond to any of the "what to do with type-6 refresh" or "how
will I make one ORF filter update multiple subsets [possibly disjoint] I
need to refresh without getting flooded to death with the AFI/SAFI stuff"
and "how will I implement ORF except a full walk on any change" which
happen to be pretty massive issues if you want decent BGP convergence on
more and more AFI/SAFIs, routes, types & other zoo sneaking upon BGP ...

sorry if I'm a tad acerbic ...

--- tony

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

> Tony,
>
> You have nicely summarized various discussed this week sub threads
> happening bith on and off the list.
>
> Except .. you did not list the most important .. to enumerate real
> protocol level use cases which would justify this addition.
>
> If we start with the problem (rather then just starting with "when we need
> subset of routes") then perhaps it will be easy to adopt this work or we go
> back and fix protocol encoding which are root cause of the problem you are
> trying to patch with solutions like selective overlapping route refresh
> messages.
>
> Best,
> R.
>
> On Jul 21, 2016 5:42 PM, "Tony Przygienda" <[e-mail]> wrote:
>
> Read the "longish" thread by now and between all this "let's do
> filter/let's do pull (refresh)" I try to take a step back to see the forest:
>
> a) To validate Niloo's point: 'f an implementation chooses to drop things
> based on configuration/policy (multicast EVPN routes) extending ORF will
> cause a complete refresh of EVPN (including type-2 MACs) unless you go and
> "install filter type-2, then refresh, then remove-filter-2" and after
> requesting type-6  (you can't defer remove-filter-2 step, otherwise you
> won't receive type-2 updates anymore!) floods you with all MACs. Pub-sub
> with a single "filter-list" is simply NOT a good model to request arbitrary
> pieces of routes missing (which is where the world is going, BGP database
> is sharding to the point specs are recommending to "drop when you don't
> need it" and we have the need to ask for very specific sets @ given points
> in time [as the use cases describe]).
>
> b) A much _bigger_ problem IMO is the fact that ORF language does not seem
> to be an algebra, it's a program and you can only build a closure of
> procedural programs by running them normally (not good to restrict sets you
> process). In less abstract terms a refresh with filters that are OR'ed and
> AND'ed (first order logic transitive closure) determines the cone you need
> to walk on the RIB very easily (people implementing heavy-duty BGP will
> know precisely what that means) whereas any change to the filter will cause
> a full walk on the RIB possibly (in case of arbitrary mix of accepts and
> rejects) without a lot of possibly hard logic to write (I didn't think
> fully through it but I think it may be actually possible to write something
> delivering closure from a generic ORF filter so it's an interesting
> discussion). Even if you can build the closure, you can only run one at a
> time (one ORF filter) unless the peer does some crazy state-ful query
> optimization language to do wonders to squeeze multiple queries it needs
> into a single ORFs it's doing (SQL query optimizers are _really_ complex
> beasts) while the "you can put a filter on something to suppress it on
> refresh but you can hammered with it anyway the moment you remove it"
> persists.
>
> For that 2 cases my take  is that it's better to move towards the model
> proposed by a "filtered refresh" (independently of being co-author) rather
> than a 'pub-sub'.
>
> As ultimate, wider angle view of the world.
>
> BGP will be offered more cycles to run (it already is ) but not in the
> form of a single faster and faster CPU anymore but in form of multiple
> cores/machines. A set of filtered refreshes can be parallelized fairly
> easily when requested. A single ORF filter being manipulated on/off will as
> described in a) possibly cause huge spurious refreshes and in b) a single
> threat of execution serializing the synchronization between peers.
>
> I hope that all can be parsed ...
>
> Very good discussion overall no matter which way it goes ...
>
> --- tony
>
>
> On Wed, Jul 20, 2016 at 3:14 PM, Robert Raszuk <[e-mail]> wrote:
>
>> Hi Keyur,
>>
>> On the EVPN topic which defines BGP protocol extensions without any IDR
>> WG review the more I hear about cases like you bring below (and this is not
>> the first one btw) the more I think it is really quite badly designed.
>>
>> And such bad protocol extensions should not be a justification to
>> introduce even more questionable knobs in BGP.
>>
>> In this specific case just get all SAFI refreshed modulo to RTC or ORF
>> filters and you are done. Case solved :).
>>
>> Best,
>> R.
>>
>>
>> On Wed, Jul 20, 2016 at 11:05 PM, Keyur Patel (keyupate) <
>> [e-mail]> wrote:
>>
>>> Hi Robert,
>>>
>>> One interesting use case is with EVPN address family where a new
>>> route-type is introduced without a capability.  A PE may have had safi
>>> enabled but not have accepted its route-type (or set of route-types) all
>>> mapping to a same RT. A transactional filter attempts to solve it.
>>>
>>> We can clarify in the next revision of the draft.
>>>
>>> One more comment inlined #Keyur
>>>
>>> From: Robert Raszuk <[e-mail]>
>>> Date: Tuesday, July 19, 2016 at 3:29 PM
>>> To: Keyur Patel <[e-mail]>
>>> Cc: "Dongjie (Jimmy)" <[e-mail]>, idr wg <[e-mail]>
>>> Subject: Re: [Idr] Fwd: Slot request in IDR to present
>>> https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt
>>>
>>> Hi Keyur,
>>>
>>> The missing part seems to be justification if we really need
>>> "transaction based filters" as opposed to simply having permanent ones.
>>>
>>> What real problem "transaction based filters" solve ? IMO the draft
>>> needs to state it clearly.
>>>
>>> The other point is that "permanent" are not really permanent anyway ..
>>> they are installed from update to withdraw of a given filter - regardless
>>> what filtering mechanism you choose (ORF, RTC, XYZ ...). And if you go with
>>> the notion that permanent are sufficient the entire aparatus allowing you
>>> to have concurrent route refresh requests in flight goes away :)
>>>
>>> #Keyur: Ack your right. My reference to a permanent filter was in
>>> context of a session life time and I agree with you that it could be
>>> modified or withdrawn at any given time. I was trying to differentiate it
>>> from transactional filters.
>>>
>>> Regards,
>>> Keyur
>>>
>>> Thx,
>>> r.
>>>
>>>
>>> On Wed, Jul 20, 2016 at 12:18 AM, Keyur Patel (keyupate) <
>>> [e-mail]> wrote:
>>>
>>>> Robert, Dongjie,
>>>>
>>>> Comments inlined #Keyur
>>>>
>>>> From: Robert Raszuk <[e-mail]>
>>>> Date: Tuesday, July 19, 2016 at 2:52 PM
>>>> To: "Dongjie (Jimmy)" <[e-mail]>
>>>> Cc: idr wg <[e-mail]>
>>>> Subject: Re: [Idr] Fwd: Slot request in IDR to present
>>>> https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt
>>>>
>>>> Hi Jie,
>>>>
>>>> To me what is perhaps missing is just a new draft to define *Route
>>>> Type* ORF to address some of those EVPN new NLRI encodings.
>>>>
>>>> #Keyur: ORFs are permanent filters. We wanted to decouple the
>>>> transaction based filters (one time per refresh) from the permanent filters
>>>> and hence chose to modify refresh message as opposed to an ORF.
>>>>
>>>> I am not that much convinced if one time ORF is needed as you are free
>>>> to INSTALL and REMOVE ORF effectively producing one time behavior.
>>>>
>>>> #Keyur: Ack.
>>>>
>>>> Also existing Enhanced Route Refresh should work with ORF too.
>>>>
>>>> #Keyur: There are modifications needed if the refresh is going to be
>>>> for selective prefixes only. Furthermore, if we want to support multiple
>>>> concurrent selective refreshes then the changes needed are very much along
>>>> the lines of the solution suggested in the draft.
>>>>
>>>> Regards,
>>>> Keyur
>>>>
>>>>
>>>>
>>>> Many thx,
>>>> R.
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jul 19, 2016 at 11:47 PM, Dongjie (Jimmy) <[e-mail]>
>>>> wrote:
>>>>
>>>>> Hi Tony,
>>>>>
>>>>>
>>>>>
>>>>> Please see some comments inline with [Jie]:
>>>>>
>>>>>
>>>>>
>>>>> *From:* Idr [mailto:[e-mail]] *On Behalf Of *Tony
>>>>> Przygienda
>>>>> *Sent:* Tuesday, July 19, 2016 6:04 PM
>>>>> *To:* Robert Raszuk; idr wg
>>>>> *Subject:* [Idr] Fwd: Slot request in IDR to present
>>>>> https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt
>>>>>
>>>>>
>>>>>
>>>>> Resending ...
>>>>>
>>>>>
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: *Tony Przygienda* <[e-mail]>
>>>>> Date: Mon, Jul 11, 2016 at 3:04 PM
>>>>> Subject: Re: [Idr] Slot request in IDR to present
>>>>> https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt
>>>>> To: Robert Raszuk <[e-mail]>
>>>>> Cc: idr wg <[e-mail]>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 11, 2016 at 1:47 PM, Robert Raszuk <[e-mail]>
>>>>> wrote:
>>>>>
>>>>> Hi Tony,
>>>>>
>>>>>
>>>>>
>>>>> Hey Robert, thanks for chiming in. Good questions. I speak here for
>>>>> myself, other authors of the draft may have differing opinions.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Can you clarify what is the expected behaviour as far as per peer
>>>>> filter-list when you negotiate both Refresh with options, ORF and RTC ?
>>>>> Note that ORF also includes recent extension as described in RFC7543 -
>>>>> would all of those be always a logical AND towards a peer which pushed
>>>>> those ?
>>>>>
>>>>>
>>>>>
>>>>> We didn't discuss that one through but the only logical conclusion for
>>>>> me is that the ORF/CP-ORF installed are respected (i.e. it's an implicit
>>>>> AND). I see ORF as statefull, remote-pushed policy on the peer that is not
>>>>> being flipped around all the time (albeit AFAIR there were some attempts @
>>>>> non-persistent, one shot ORF but that ended up expiring?)
>>>>>
>>>>>
>>>>>
>>>>> [Jie] I think the attempts you mentioned here are the one-time ORF
>>>>> drafts: draft-zeng-idr-one-time-prefix-orf  and
>>>>> draft-dong-idr-one-time-ext-community-orf. After several revisions, these
>>>>> drafts got expired due to lack of requirements at that time. If people
>>>>> found some new use cases of these kinds of mechanisms, the authors would be
>>>>> happy to bring them back to discussion.
>>>>>
>>>>>
>>>>>
>>>>> 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. Putting ORF on a
>>>>> peer, refresh and remove ORFs is significantly heavier process that may
>>>>> interfere on top with normal update process going on and needs to be done
>>>>> one-by-one (since you have to wait for single BoRR/EoRR pair) unless one is
>>>>> very smart about combining ORF possibly & playing with the
>>>>> DEFER/IMMEDIATEs. As we indicated, if the AFI/SAFI is covered by RTC and
>>>>> RTC is supported & one is willing to configure RTs for each subset of
>>>>> routes that may need refreshing, RT will be doing the same job just fine.
>>>>>
>>>>>
>>>>>
>>>>> [Jie] The motivations look similar to what we described for the
>>>>> one-time ORF drafts.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Would you always carry ORF with separate Refresh_ID value ?
>>>>>
>>>>>
>>>>>
>>>>> Yes, Refresh-ID# is strictly monotonic so there is never a
>>>>> misunderstanding WHAT the BoRR belongs to. Observe that the draft does NOT
>>>>> mandate that a request MUST be followed by according BoRR, only that BoRRs
>>>>> must follow same sequence as requests (i.e. are also strictly monotonic).
>>>>> However, we should probably specify that options _and_ ORF can NOT be mixed
>>>>> in the same type #3 message but it's either one or the other (and anything
>>>>> else is error). This will allow ORF operations like today + benefit of the
>>>>> Refresh ID#  on the BoRR so the IMMEDIATE can go on @ the same time as
>>>>> another request with higher Refresh ID# (de facto we allow multiple
>>>>> parallel refreshes as you see).  In case of DEFER there will be simply no
>>>>> BoRR for it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> If one requests full Adj_RIB_Out in the new model and sends refresh
>>>>> message with new refresh_id and no options however there are ORF entries
>>>>> already installed in the past would he get just the subset of routes
>>>>> against all ORF entries ? In other words I think the draft should state
>>>>> that Refresh_IDs have no impact to ORF ADDs or REMOVE actions - don't you
>>>>> think ?
>>>>>
>>>>>
>>>>>
>>>>> I agree. Yes, ORF is kind of  "permanent filter" on the peer while the
>>>>> intent of this draft is to have bunch of "small refreshes" going on @ same
>>>>> time possibly (if you request the refreshes from a good implementation
>>>>> while low-end implementations may serialize the requests to simplify
>>>>> internal logic ;-).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> As far as current types why not add regular/extended community ?
>>>>>
>>>>>
>>>>>
>>>>> Discussion came up. Feeling was it's an immediate encroach on RT
>>>>> territory. I argued for it ;-)  Ultimately, taking a more relaxed view, we
>>>>> chose to wait and see what the response is and most pressing use cases
>>>>> people bring to it and then we start to define bits and bytes of the
>>>>> options supported, possibly borrowing to an extent from the ORF specs ;-)
>>>>>  As in "most sincere form of flattery" and such ... ;-)
>>>>>
>>>>>
>>>>>
>>>>> [Jie] Actually before the one-time ORF drafts were submitted, we
>>>>> initially considered to make it a “selective route refresh” mechanism. Then
>>>>> we realized that the filters will be quite similar to the ones already
>>>>> defined for ORF. In order to reuse the ORF filters, we then decided to
>>>>> define this mechanism as new “one-time” ORF types.  Just to provide some
>>>>> background information since you also plan to reuse the format of the
>>>>> existing ORF types.
>>>>>
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Jie
>>>>>
>>>>>
>>>>>
>>>>> -- tony
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *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
>>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>>
>
>
> --
> *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
>
>
>


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