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

From: Robert Raszuk <[email-masked]>
Date: Mon, 1 Aug 2016 10:53:53 +0200

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 <
[email-masked]> 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 <[email-masked]> 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) <[email-masked]>
> 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 <[email-masked]> wrote:
>
> Hi Jakob,
>
> See inline ...
>
> On Fri, Jul 29, 2016 at 4:18 AM, Jakob Heitz (jheitz) <[email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>
>

---

From: Randy Bush <[email-masked]>
Date: Mon, 01 Aug 2016 20:37:30 +0900

> * How often do you apply prefix lists on a full eBGP feeds ?

every single one, every time.  bogons, default, longer than /24, a t1 in
the as path when the receiver is a t1 (ok, that's not a full feed), ...
welcome to routing in the real ugly world.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 1 Aug 2016 13:42:55 +0200

Randy,

Of course you have bogons, policies with AS_PATH .. tons of regex etc ...
but:

#1 you do not usually remove them

#2 if you modify them you just can't ask you peer for specific prefix and
assume your BGP got synced up correctly.

That's the bigger picture here.

Cheers
R.

---

From: Randy Bush <[email-masked]>
Date: Mon, 01 Aug 2016 20:48:34 +0900

> Of course you have bogons, policies with AS_PATH .. tons of regex etc
> ...  but:

your question was absolute.  i answered.

> #1 you do not usually remove them

bogon lists shrink as address space is allocated.  yes, v4 not so much
these days, but v6 yes.

> #2 if you modify them you just can't ask you peer for specific prefix
> and assume your BGP got synced up correctly.

we were not discussing 93 other possible mechanisms.  you asked a
question; i answered.  the goal was not to see how much you could
wiggle, despite it being election season.

randy

---

From: heasley <[email-masked]>
Date: Mon, 1 Aug 2016 22:56:03 +0000

> bogon lists shrink as address space is allocated.  yes, v4 not so much

ACLs, at various points in our network, change daily.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 2 Aug 2016 01:05:42 +0200

To make this time my question much more precise ...

It is very obvious that inbound eBGP policy changes very often for 94
reasons.

However the real point is how many of those policy changes can be mapped to
newly proposed scoped refresh vs just addressed with per SAFI enhanced full
route refresh.

If NOC folks will prove that upon policy adjustment automated query to
peers prefix by prefix is useful the only outstanding question will remain
how to deal with BGP inconsistencies as pointed out earlier in this thread.

Thx,
R.

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Aug 2016 09:08:38 +0900

> To make this time my question much more precise ...

you asked if we changed filters on full feeds.  the answer is yes.

> It is very obvious that inbound eBGP policy changes very often for 94

then why did you ask?

> However the real point is how many of those policy changes can be
> mapped to newly proposed scoped refresh vs just addressed with per
> SAFI enhanced full route refresh.

focusing on the full feeds about which you asked, what happens when i
update to accept prefixes from a new v6 /12 allocated by the iana?  do
i really need the load of a full refresh of the v6 table?  is it polite
to my upstreams?  will it be if v6 is actually widely deployed?

from my pov, route refresh is not a small hammer.  the trade-off is the
complexity, and concomitant bugs, of scoped refresh vs more bgp bouncy
bouncy.  i bow to heas's wisdom.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 2 Aug 2016 04:58:00 +0200

> you asked if we changed filters on full feeds.  the answer is yes.

What I really asked with context of this thread was if changes which are
being applied in inbound policy on full feeds can be represented by
parameters which are proposed to be used as query.

You answered yes for full v6 table of today's 30k routes some changes can
be mapped to a prefix. Cool.

> > It is very obvious that inbound eBGP policy changes very often for 94

As this is not policy change. This duscussion is about policy changes which
can be mapped to scoped refresh.

> to my upstreams?  will it be if v6 is actually widely deployed?

Please observe that with one time scoped refresh you still need to be able
to handle the full feed (ex. booting time). Let's also notice that since we
are now talking about being polite nothing (other then your local
configuration) forces you to drop everything which you do not need. You are
welcome to keep everything you receive in Adj_Rib_In and modify your policy
100 times a day with zero impact to your peers.

Kind regards,
Robert.