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

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