Subject: [GROW] Request WG Adoption for draft-sa-grow-maxprefix

From: Melchior Aelmans <[email-masked]>
Date: Thu, 25 Jul 2019 08:00:25 -0400

Hi WG,

We would like to request WG adoption for https://datatracker.ietf.org/doc/draft-sa-grow-maxprefix/

Thanks,
Melchior

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 25 Jul 2019 14:43:38 +0200

All,

I would like to raise three points in respect to this draft:

Point 1:

The topic of outbound prefix limit is not new :) It has been discussed
number of times within vendors and between vendors. But one requirement
when we are talking about outbound prefix limit is which prefixes should be
sent first - which are more important then others - so prefix
prioritization in update generation and update scheduling comes up. Are we
sure that this is not going to happen here ? Sure not in this draft, but
once you build the road emergency vehicles and regular vehicles will try to
use it. And while outbound prefix limit looks innocent the moment we start
to ask for prioritizing prefixes some bgp implementations may have a bit of
hard time.

Point 2:

The draft is still silent on the question I posted to the list regarding
this idea in respect to decision which limit is more important ? Locally
configured outbound limit or pushed by prefix limit ORF peers inbound limit
? What should be the action of the sender when those two numbers are not
equal ? I think this must be precisely spelled out here.

Point 3:

For inbound prefix limit the position if this should be pre or post policy
should be IMHO a local configuration decision. See if I decide to keep full
table in my Adj_RIB_In maybe just for BMP use no spec should prevent that.
Maybe it would be worth to add this explicitly to the draft in addition to
listing those two measurement insertion locations :)

Many thx
Robert

On Thu, Jul 25, 2019 at 2:00 PM Melchior Aelmans <[email-masked]>
wrote:

> Hi WG,
>
> We would like to request WG adoption for
> https://datatracker.ietf.org/doc/draft-sa-grow-maxprefix/
>
> Thanks,
> Melchior
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Job Snijders <[email-masked]>
Date: Fri, 26 Jul 2019 14:49:55 +0000

Dear Robert,

Thank you for your questions.

On Thu, Jul 25, 2019 at 02:43:38PM +0200, Robert Raszuk wrote:
> number of times within vendors and between vendors. But one
> requirement when we are talking about outbound prefix limit is which
> prefixes should be sent first - which are more important then others -
> so prefix prioritization in update generation and update scheduling
> comes up. Are we sure that this is not going to happen here ? Sure not
> in this draft, but once you build the road emergency vehicles and
> regular vehicles will try to use it. And while outbound prefix limit
> looks innocent the moment we start to ask for prioritizing prefixes
> some bgp implementations may have a bit of hard time.

We do not consider it a requirement to provide any guidance on which
prefixes should be sent first. Another draft can attempt to provide
guidance, or vendors can stick to their current approaches. You'll
notice from the draft that once the limit is reached a CEASE
Notification is sent; so I am not sure if the priority truly matters in
context of tearing down the session.

> Point 2:
> 
> The draft is still silent on the question I posted to the list
> regarding this idea in respect to decision which limit is more
> important ? Locally configured outbound limit or pushed by prefix
> limit ORF peers inbound limit ? What should be the action of the
> sender when those two numbers are not equal ? I think this must be
> precisely spelled out here.

Can you clarify what you mean with "pushed by prefix limit ORF peers
inbound limit"? As it currently stands it doesn't seem like
draft-keyur-idr-bgp-prefix-limit-orf is making a lot of head-way, so it
doesn't seem like there is a deployed mechanism we need to take into
consideration.

However, if I have to choose, I think I would prioritze the locally
configured limit as one could argue that local configuration supersede
instructions received from remote.

If you have specific suggestions what text and considerations should be
added to the draft I would welcome that.

> Point 3:
> 
> For inbound prefix limit the position if this should be pre or post
> policy should be IMHO a local configuration decision. See if I decide
> to keep full table in my Adj_RIB_In maybe just for BMP use no spec
> should prevent that.  Maybe it would be worth to add this explicitly
> to the draft in addition to listing those two measurement insertion
> locations :)

I agree that operators locally configure these limits and they
themselves choose to use no limits, pre-, post-, or a combination of
pre- + post- policy limits.

This Internet-Draft seeks to document that both exist, and formulate
things in such a way that when a vendor claims compliance with
draft-sa-grow-maxprefix, they indicate to support all of outbound,
pre-policy inbound, and post-policy inbound. A vendor could also
indicate they only have support for "draft-sa-grow-maxprefix section 2.2
type B", or only "type A".

My recommendation to BGP implementers would be to implement all three
types of prefix limits. My recommendation to operators is to configure
both pre-policy and post-policy limits, as each limit has different
advantages in context of Internet routing.

Kind regards,

Job

---

From: Claudio Jeker <[email-masked]>
Date: Fri, 26 Jul 2019 17:16:27 +0200

> > I would like to raise three points in respect to this draft:

...

> advantages in context of Internet routing.

For BGP implementation having more then just one Loc-RIB implementing a
post-policy check is more comples and the result will depend on which of
the RIBs the count is done. For this reasons OpenBGPD only does pre-policy
inbound limits and until now nobody ever complained about that being not
good enough.

-- 
:wq Claudio

---

From: Job Snijders <[email-masked]>
Date: Fri, 26 Jul 2019 15:44:48 +0000

On Fri, Jul 26, 2019 at 05:16:27PM +0200, Claudio Jeker wrote:
> > My recommendation to BGP implementers would be to implement all
> > three types of prefix limits. My recommendation to operators is to
> > configure both pre-policy and post-policy limits, as each limit has
> > different advantages in context of Internet routing.
> 
> For BGP implementation having more then just one Loc-RIB implementing
> a post-policy check is more comples and the result will depend on
> which of the RIBs the count is done. For this reasons OpenBGPD only
> does pre-policy inbound limits and until now nobody ever complained
> about that being not good enough.

In context of Internet routing the *pre* policy limit is the most
useful one; so I'm happy openbgpd has it. This is the feature that helps
protect against full route table leaks.

On the other hand, *post* policy limits are not entirely effective
against full table route leaks. I've explained the difference at the
IETF 104 GROW session.

The *post* policy limit is most useful if there are FIB size
restrictions (for instance on a layer-3 switch with constrained ASIC);
or if there are Loc-RIB memory constraints. Since the most common
deployment of OpenBGPD seems to be on 'server-based routers' and 'route
servers', I am not surprised so far the feature hasn't come up yet.

If OpenBGPD decides not to implement post-policy limits, that is fine,
it just means that OpenBGPD cannot claim compliance with the full
Internet-Draft. However, when the draft is published at RFC at least
openbgpd can reference *exactly* what is implemented.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Jul 2019 19:54:31 +0200

Hello Job,

You'll
> context of tearing down the session.

And I am not sure if CEASE matters in the context of BGP Persistence
efforts :)

> added to the draft I would welcome that.

I would suggest to just add a sentence that the actual number of prefixes
sent
without warning or error (session drop) should be a smallest number of
prefixes
either which were locally configured or pushed from the peer.

Thx,
R.

---

From: Job Snijders <[email-masked]>
Date: Fri, 26 Jul 2019 13:58:20 -0400

> And I am not sure if CEASE matters in the context of BGP Persistence

Good feedback. I’ll have to rely on the GROW and IDR WGs to help understand
how we view CEASE in this context and what must be done.

> either which were locally configured or pushed from the peer.

If closer to the time of publication of this draft there is another
standard that may impact decisions here, yes that would be prudent to
consider.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 26 Jul 2019 20:04:21 +0200

IMHO even if such standard appears *after* publication  of this draft
having that in apriori would be a pure plus :)

Cheers,
R.

On Fri, Jul 26, 2019 at 7:58 PM Job Snijders <[email-masked]> wrote:

> Good feedback. I’ll have to rely on the GROW and IDR WGs to help
> understand how we view CEASE in this context and what must be done.
>
>

---

From: Nathalie Trenaman <[email-masked]>
Date: Mon, 29 Jul 2019 11:16:18 +0200

I support WG adoption

> Op 25 jul. 2019, om 14:00 heeft Melchior Aelmans <[email-masked]> het volgende geschreven:
> 
> Hi WG,
> 
> We would like to request WG adoption for https://datatracker.ietf.org/doc/draft-sa-grow-maxprefix/ <https://datatracker.ietf.org/doc/draft-sa-grow-maxprefix/>
> 
> Thanks,
> Melchior

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 31 Jul 2019 01:21:04 +0000

In response to Robert's point on the IDR list related to draft-uttaro-idr-bgp-persistence:
If BGP session terminates unexpectedly - say when max prefix is reached - it is quite unclear on the operational consequences of such duet of features enabled together.

may I suggest that response to the outbound maximum prefix exceeded event should be a hard CEASE
as defined in https://tools.ietf.org/html/rfc8538. It already suggests to use a hard CEASE for an
inbound maximum prefix exceeded event.

Robert, will that satisfy your concern with persistence?

Regards,
Jakob.

From: GROW <[email-masked]> On Behalf Of Melchior Aelmans
Sent: Thursday, July 25, 2019 5:00 AM
To: [email-masked]
Subject: [GROW] Request WG Adoption for draft-sa-grow-maxprefix

Hi WG,

Thanks,
Melchior

---

From: Job Snijders <[email-masked]>
Date: Wed, 31 Jul 2019 01:30:28 +0000

On Wed, Jul 31, 2019 at 01:21:04AM +0000, Jakob Heitz (jheitz) wrote:
> In response to Robert's point on the IDR list related to
> draft-uttaro-idr-bgp-persistence: If BGP session terminates
> unexpectedly - say when max prefix is reached - it is quite unclear on
> the operational consequences of such duet of features enabled
> together.
> 
> may I suggest that response to the outbound maximum prefix exceeded
> event should be a hard CEASE as defined in
> https://tools.ietf.org/html/rfc8538. It already suggests to use a hard
> CEASE for an inbound maximum prefix exceeded event.
> 

While the question is addressed to Robert, I think this is a good idea
and am happy to incorporate text in the maxprefix Internet-Draft that
references the rfc8538 hard reset concept.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 31 Jul 2019 11:29:45 +0200

Yes thx both to Bruno and Jakob to bring the hard CEASE option as solution.

Subject draft is addressed. But we all need to watch for similar
assumptions and consequences when persistent bgp feature is enabled.

Best,
R.

On Wed, Jul 31, 2019, 03:21 Jakob Heitz (jheitz) <[email-masked]> wrote:

> draft-uttaro-idr-bgp-persistence:
>
> If BGP session terminates unexpectedly - say when max prefix is reached -
> it is quite unclear on the operational consequences of such duet of
> features enabled together.
>
>
>
> *From:* GROW <[email-masked]> *On Behalf Of * Melchior Aelmans
> *Sent:* Thursday, July 25, 2019 5:00 AM
> *To:* [email-masked]
> *Subject:* [GROW] Request WG Adoption for draft-sa-grow-maxprefix
>
>
>
> Hi WG,
>
>
>