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

yep, sorry, I missed that I only answered ORF and not RTC

As example look at 7432 section 7.9. Box of Pandora has been opened a while
ago, route type being the other one ...

On Tue, Jul 19, 2016 at 3:03 AM, Tony Przygienda <[e-mail]>
wrote:

> 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?)
>
> 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
>
>
>
>
> --
> *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
>



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