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

See inline ...

On Fri, Jul 29, 2016 at 4:18 AM, Jakob Heitz (jheitz) <[e-mail]>
wrote:

> Just reading some of this.
>
> A limited refresh is NOT the same thing as "Apply the ORF then remove it".
>
> Suppose you want to refresh a subset of the routes.
>
> You send an ORF to permit only the subset.
>
> You receive the subset.
>
> Now you remove the ORF.
>
> You receive the whole table.
>
> NOT what you wanted.
>


​If this is what your implementation does then I recommend you fix it
first.

For Match = DENY ​REMOVE action should result in *only* advertisement of
previously filtered entries.

For Match = PERMIT REMOVE action should result in *only* the delta between
whole table and remaining ORF entries.

​In no case you get the whole table (other then removal of last ORF PERMIT
entry). ​




> Also, the use case is good.
>
> The receiver dropped some routes due to policy.
>
> The receiver changed the policy.
>
> Now it wants a repeat of the previously dropped routes.
>
> This is not a use case for ORF or RTC.
>
> The thing is that ORF or RTC were already passing those routes, so
> changing them is nonsense.
>


​For this case you use Enhanced Route Refresh. As result you get those
NLRIs which pass ORF or RTC the filters on a per AFI/SAFI basis.

You have to be able to handle it anyway as when you boot you will get.

If you pushed your prefix list with ORF then removing it will get you the
delta.

If you filtered based on import RT then advertising RT in ORF or RTC will
get you the delta.

So in what exact protocol cases you envision use case for this scoped one
time refresh ? And what exactly in your opinion should be the list of
parameters used to perform a query ?


Best,
R.