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

Jakob,

I did not make any judgement who is right and who is wrong. You did so let
me explain where you are missing it.

#1 - As someone wisely said at the last IETF MAY = MAY NOT hence if spec
contains MAY it equally well could be interpreted in the opposite way.
Enough to say this is not a base to make any right or wrong judgement.

#2 - This entire thread as well as this draft in question is all about
optimization. I must repeat that there is no problem in the first place so
receiving all routes in a given SAFI modulo ORF or RTC filter is just fine.
During policy change you issue Enhanced Route Refresh.

However If this is not fine then I recommend to fix those inefficient
implementations which are generating excess of messages in the BGP UPDATE
rather then putting another layer of questionable band-aid on top of it.

Thx,
R.

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

> Wrong. RFC 5291 says:
>
> The speaker MUST re-advertise all the routes that have been
>    affected by the ORF entries carried in the message, but MAY also re-
>    advertise the routes that have not been affected by the ORF entries
>    carried in the message.
>
>
> Thanks,
> Jakob.
>
>
> On Jul 29, 2016, at 12:45 AM, Robert Raszuk <[e-mail]> wrote:
>
> 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.
>
>
>
>
>
>