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

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. Also
existing Enhanced Route Refresh should work with ORF too.

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
>