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

[Tony Przygienda <[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?)

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.


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

-- tony