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

[Niloofar Fazlollahi <[e-mail]>]

Hi Robert,In response to your comment:"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 ? "
There is also the case that policy is enforced locally, nor ORF and neither RTC, e.g., route-map in with deny prefix-list.
Once the policy is removed, with cap 74, speaker can request refresh of only the previously denied prefixes.How to implement this optimization with ORF? 
Based on your previous email:"For Match = PERMIT REMOVE action should result in *only* the delta between whole table and remaining ORF entries. "

If we send a PERMIT ADD for those prefixes and then PERMIT REMOVE, we will be refreshed with the whole AFI/SAFI assuming no other ORF is added previously.

Regards,Niloofar
 

    On Friday, July 29, 2016 4:30 AM, Robert Raszuk <[e-mail]> wrote:
 

 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.








_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr