Re: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt

["Dongjie (Jimmy)" <[e-mail]>]

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]<mailto:[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]<mailto:[e-mail]>>
Cc: idr wg <[e-mail]<mailto:[e-mail]>>



On Mon, Jul 11, 2016 at 1:47 PM, Robert Raszuk <[e-mail]<mailto:[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