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

["Jakob Heitz (jheitz)" <[e-mail]>]

And to clarify, that means all routes permitted after the ORF message is processed MUST be re-advertised. It doesn't matter whether the action was add or remove.

Also, when you remove the last permit, you get nothing. It's like after session establishment: if the ORF capability was negotiated, nothing is sent until the first permit is received.

Thanks,
Jakob.


On Jul 29, 2016, at 3:12 AM, Jakob Heitz (jheitz) <[e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:

Hi Jakob,

See inline ...

On Fri, Jul 29, 2016 at 4:18 AM, Jakob Heitz (jheitz) <[e-mail]<mailto:[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.