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

[Martijn Schmidt]

I also support WG adoption. Especially the availability of a configurable 
Maximum Outbound Prefix Limit sounds like music to my operator ears.

Best regards,
Martijn Schmidt
i3D.net / Ubisoft / AS49544

From: GROW  on behalf of torunn.narves...@telenor.com 

Sent: 14 August 2019 08:53
To: melch...@aelmans.eu 
Cc: grow@ietf.org 
Subject: Re: [GROW] Request WG Adoption for draft-sa-grow-maxprefix


I support WG adoption of this draft.


I also support the suggestion regarding using Hard Reset for outbound maximum 
prefix limits. ​


- Torunn


-- Forwarded message -
From: Nathalie Trenaman mailto:natha...@ripe.net>>
Date: Mon, Jul 29, 2019 at 11:16 AM
Subject: Re: [GROW] Request WG Adoption for draft-sa-grow-maxprefix
To: Melchior Aelmans mailto:melch...@aelmans.eu>>
Cc: mailto:grow@ietf.org>>


I support WG adoption

Op 25 jul. 2019, om 14:00 heeft Melchior Aelmans 
mailto:melch...@aelmans.eu>> het volgende geschreven:

Hi WG,

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

Thanks,
Melchior
___
GROW mailing list
GROW@ietf.org<mailto:GROW@ietf.org>
https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Torunn.Narvestad]

I support WG adoption of this draft.


I also support the suggestion regarding using Hard Reset for outbound maximum 
prefix limits. ?


- Torunn


-- Forwarded message -
From: Nathalie Trenaman mailto:natha...@ripe.net>>
Date: Mon, Jul 29, 2019 at 11:16 AM
Subject: Re: [GROW] Request WG Adoption for draft-sa-grow-maxprefix
To: Melchior Aelmans mailto:melch...@aelmans.eu>>
Cc: mailto:grow@ietf.org>>


I support WG adoption

Op 25 jul. 2019, om 14:00 heeft Melchior Aelmans 
mailto:melch...@aelmans.eu>> het volgende geschreven:

Hi WG,

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

Thanks,
Melchior
___
GROW mailing list
GROW@ietf.org<mailto:GROW@ietf.org>
https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Job Snijders]

On Wed, Jul 31, 2019 at 01:21:04AM +, 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.
> 
> Robert, will that satisfy your concern with persistence?

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

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Nathalie Trenaman]

I support WG adoption

> Op 25 jul. 2019, om 14:00 heeft Melchior Aelmans  het 
> volgende geschreven:
> 
> Hi WG,
> 
> We would like to request WG adoption for 
> https://datatracker.ietf.org/doc/draft-sa-grow-maxprefix/ 
> 
> 
> Thanks,
> Melchior
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow



signature.asc
Description: Message signed with OpenPGP
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Robert Raszuk]

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

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

> On Fri, Jul 26, 2019 at 13:54 Robert Raszuk  wrote:
>
>> Hello Job,
>>
>> 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.
>>>
>>
>> And I am not sure if CEASE matters in the context of BGP Persistence
>> efforts :)
>>
>
> 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.
>
>
>> If you have specific suggestions what text and considerations should be
>>> 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.
>>
>
>
> 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
>
>>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Robert Raszuk]

Hello Job,

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

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

If you have specific suggestions what text and considerations should be
> 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.
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Job Snijders]

On Fri, Jul 26, 2019 at 13:54 Robert Raszuk  wrote:

> Hello Job,
>
> 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.
>>
>
> And I am not sure if CEASE matters in the context of BGP Persistence
> efforts :)
>

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.


> If you have specific suggestions what text and considerations should be
>> 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.
>


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

>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Job Snijders]

On Fri, Jul 26, 2019 at 05:16:27PM +0200, Claudio Jeker wrote:
> On Fri, Jul 26, 2019 at 02:49:55PM +, Job Snijders 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

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Claudio Jeker]

On Fri, Jul 26, 2019 at 02:49:55PM +, Job Snijders wrote:
> Dear Robert,
> 
> Thank you for your questions.
> 
> On Thu, Jul 25, 2019 at 02:43:38PM +0200, Robert Raszuk wrote:
> > I would like to raise three points in respect to this draft:
> > 



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

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

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Job Snijders]

Dear Robert,

Thank you for your questions.

On Thu, Jul 25, 2019 at 02:43:38PM +0200, Robert Raszuk wrote:
> 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.

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

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Robert Raszuk]

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 
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
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow