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

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