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

Hello Niloofar,

Requesting just the prefix which previously got dropped due to inbound
policy (no ORF no RTC) is very elegant.

However let's observe few points here:

* How often do you apply prefix lists on a full eBGP feeds ? The most
prefix lists dropping prefixes inbound are either to your customers (and
this is mainly permits not denys) and customers do not give you full routes
but just a tiny subset. Full refresh there for a given SAFI is not an
issue.

* If you are doing eBGP prefix drops as DDoS mitigation you are helping the
attacker as effectively you are cutting reachability to your customer's
destinations. Use of more granular policy is recommended to hold specific
attack at the data plane (rfc5575).

* Last let's notice that during discussions on introducing Enhanced Route
Refresh 3 years back your colleagues strongly highlighted that getting
periodic full table from a peer is a real necessity in BGP due to possibly
random state inconsistencies. Now it is interesting that the very same
folks no longer remember it :)

Ref: https://goo.gl/I6m3OS

Cheers,
Robert.


On Mon, Aug 1, 2016 at 8:19 AM, Niloofar Fazlollahi <
[e-mail]> wrote:

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