Subject: [Idr] Adoption call for draft-sas-idr-maxprefix-inbound-04.txt (3/10 to 3/24)

From: "Susan Hares" <[email-masked]>
Date: Thu, 10 Mar 2022 10:49:22 -0500

This begins a 2 week WG adoption call (3/10/2022 to 3/24/2022) 

For draft-sas-idr-maxprefix-inbound-04.txt 

https://datatracker.ietf.org/doc/draft-sas-idr-maxprefix-inbound/

The authors state: 

  This document describes mechanisms to limit the negative impact of

   route leaks [RFC7908] and/or resource exhaustion in BGP [RFC4271]

   implementations.

The draft proposes changes to RFC4271 state machine to add 

Inbound prefix limits (pre-policy and post-policy) 

as part of events that MAY generate an 

"automatic stop" state machine change. 

It also defines a NOTIFICATION CEASE Code. 

There are 4 implementations that do both 

pre-policy and post-policy inbound limits

(JunOS, BIRD, Arista EOS, and Huawei VRPv8).

3 implementations that only do pre-policy inbound prefix-limits

(Huawei VRRP v5,  Nokia SR OS, OpenBSD OpenBGPD),

and 2 implementations that do post-policy inbound prefix limits

(Cisco IOS XR, Cisco IOS XE). 

Please consider in your adoption comments: 

1) Does this addition to RFC4271 

for an optional knobs for inbound maxprefix

(pre-policy and post-policy) help operators? 

2) Are there any concerns with deploying this 

Optional knob? 

3) Are there any errors in the text regarding the 

FSM description? 

Please note with the number of implementations 

this specification will transition rapidly to a 

WG LC? 

Cheers, Sue 

(Shepherd)

---

From: Melchior Aelmans <[email-masked]>
Date: Thu, 10 Mar 2022 20:36:34 +0100

Hi WG,

I support the adoption as a co-author.

Thanks!
Melchior

On Thu, Mar 10, 2022 at 4:50 PM Susan Hares <[email-masked]> wrote:

> “automatic stop” state machine change.
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 10 Mar 2022 15:20:58 -0500

Sue,

One brief note:

On Mar 10, 2022, at 10:49 AM, Susan Hares <[email-masked]> wrote:

> It also defines a NOTIFICATION CEASE Code. 

This cease subcode was defined by RFC 4486.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Mar 2022 21:29:06 +0100

I think Sue meant to say:

It also *renames* a NOTIFICATION CEASE Code

:)

Thx,
r.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 10 Mar 2022 15:37:21 -0500

> On Mar 10, 2022, at 3:29 PM, Robert Raszuk <[email-masked]> wrote:
> 
> It also renames a NOTIFICATION CEASE Code  

I'd like to hear from the authors that this is their intent.  At the moment, they don't cite the current point of registration.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Mar 2022 21:43:56 +0100

I see this and it seems pretty clear to me:

6 <https://datatracker.ietf.org/doc/html/draft-sas-idr-maxprefix-inbound-04#section-6>.
IANA Considerations

   This memo requests that IANA updates the name of subcode "Maximum
   Number of Prefixes Reached" to "Threshold exceeded: Maximum Number of
   Prefixes Received" in the "Cease NOTIFICATION message subcodes"
   registry under the "Border Gateway Protocol (BGP) Parameters" group.

On Thu, Mar 10, 2022 at 9:37 PM Jeffrey Haas <[email-masked]> wrote:

> I'd like to hear from the authors that this is their intent.  At the
> moment, they don't cite the current point of registration.
>
> -- Jeff
>
>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 10 Mar 2022 15:54:51 -0500

> On Mar 10, 2022, at 3:43 PM, Robert Raszuk <[email-masked]> wrote:
> 
> 6 <https://datatracker.ietf.org/doc/html/draft-sas-idr-maxprefix-inbound-04#section-6>.  IANA Considerations
> 

Aha... inattentional blindness.  Thanks, Robert.

Clearly I'm low on caffeine.

-- Jeff

---

From: Melchior Aelmans <[email-masked]>
Date: Thu, 10 Mar 2022 22:11:02 +0100

Thanks Robert for pointing Jeff to that section. It is indeed our intention
to update the name.

*hands Jeff coffee*

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 10 Mar 2022 17:32:47 -0500

Jeff: 

Thank you for raising this issue on the list.

I was going to ask whether the authors wanted to use CEASE NOTIFICATION
subcode 1 or  a unique subcode for inbound prefixes. 

There is benefit in using a new Cease NOTIFICATION subcode. 

Sue 

From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Thursday, March 10, 2022 3:21 PM
To: Sue Hares
Cc: [email-masked]
Subject: Re: [Idr] Adoption call for draft-sas-idr-maxprefix-inbound-04.txt
(3/10 to 3/24)

Sue,

One brief note:

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 10 Mar 2022 17:33:35 -0500

+1 - on hearing from the authors. 

From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Thursday, March 10, 2022 3:37 PM
To: Robert Raszuk
Cc: Sue Hares; idr@ietf. org
Subject: Re: [Idr] Adoption call for draft-sas-idr-maxprefix-inbound-04.txt
(3/10 to 3/24)

I'd like to hear from the authors that this is their intent.  At the moment,
they don't cite the current point of registration.

-- Jeff

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 11 Mar 2022 02:06:24 -0500

Hi Sue

I support WG Adoption and expedited transition to WGLC given the number of
implementations.

Yes it helps and having the pre policy as well really helps as well as a
lot of operators use the pre policy for NOC troubleshooting

Optional knob?

 No

FSM description?

 No

WG LC?

 Yes agreed this draft is ready to progress

Kind Regards

Gyan

On Thu, Mar 10, 2022 at 5:34 PM Susan Hares <[email-masked]> wrote:

> +1 – on hearing from the authors.
>
>
>
> *From:* Jeffrey Haas [mailto:[email-masked]]
> *Sent:* Thursday, March 10, 2022 3:37 PM
> *To:* Robert Raszuk
> *Cc:* Sue Hares; idr@ietf. org
> *Subject:* Re: [Idr] Adoption call for
> draft-sas-idr-maxprefix-inbound-04.txt (3/10 to 3/24)
>
>
>
>
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 24 Mar 2022 11:42:30 +0100

support

the option to keep on going why dropping excess should really have an all
caps warning along the lilnes of "not only you but others will have a very
bad hair day if you do that" ;-)

-- tony

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 24 Mar 2022 06:48:32 -0400

Tony: 

I’m pleased to see you respond to this call.   
I hope others will review this draft regarding inbound max prefix. 

Sue 

PS – Bad hair day – ha-ha.. smile. 

From: Idr [mailto:[email-masked]] On Behalf Of Tony Przygienda
Sent: Thursday, March 24, 2022 6:43 AM
To: Susan Hares
Cc: idr wg
Subject: Re: [Idr] Adoption call for draft-sas-idr-maxprefix-inbound-04.txt (3/10 to 3/24)

support 

the option to keep on going why dropping excess should really have an all caps warning along the lilnes of "not only you but others will have a very bad hair day if you do that" ;-) 

-- tony 

The authors state: 

   implementations.

Optional knob? 

FSM description? 

WG LC? 

Cheers, Sue 

(Shepherd)

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Thu, 24 Mar 2022 21:14:24 +0000

Support.

>the option to keep on going why dropping excess should really have an all caps warning along the lilnes of "not only you but others will have a very bad hair day if you do that" ;-)

+1.

I always wondered about why such a procedure (silently discarding prefixes on reaching threshold, and causing possible inconsistencies) was documented as a possible approach. I think it may be good if we can deprecate the existing knobs that cause this possible routing inconsistencies. Unless operators find it useful in some manner that I cannot think of.

9.5.2 in https://datatracker.ietf.org/doc/html/draft-sas-idr-maxprefix-inbound-04#section-4 looks much useful.

Thanks
Kaliraj
From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Thursday, March 24, 2022 at 3:49 AM
To: 'Tony Przygienda' <[email-masked]>
Cc: 'idr wg' <[email-masked]>
Subject: Re: [Idr] Adoption call for draft-sas-idr-maxprefix-inbound-04.txt (3/10 to 3/24)
[External Email. Be cautious of content]

Tony:

Sue

support

-- tony

On Thu, Mar 10, 2022 at 4:50 PM Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
This begins a 2 week WG adoption call (3/10/2022 to 3/24/2022)
For draft-sas-idr-maxprefix-inbound-04.txt
https://datatracker.ietf.org/doc/draft-sas-idr-maxprefix-inbound/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-sas-idr-maxprefix-inbound/__;!!NEt6yMaO-gk!X7uKvT3YkukGReJbL-TY0KYiPk12OtGZm_o4YQZsEBMZvcDYkFr_mulJVieK7Obg$>

The authors state:

Cheers, Sue
(Shepherd)

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!X7uKvT3YkukGReJbL-TY0KYiPk12OtGZm_o4YQZsEBMZvcDYkFr_mulJVi-ZQTci$>

Juniper Business Use Only

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 24 Mar 2022 23:19:53 +0100

Kaliraj,

I always wondered about why such a procedure (silently discarding prefixes
> on reaching threshold, and causing possible inconsistencies) was documented
> as a possible approach. I think it may be good if we can deprecate the
> existing knobs that cause this possible routing inconsistencies. Unless
> operators find it useful in some manner that I cannot think of.
>

"When you are given a knife you can cut and hurt yourself or you can use it
to slide bread to feed your family. "

First it would be very bad if any implementation is silent about such drops
irrespective if they happen pre or post policy. Syslog msg should be
generated in all cases.

Now in respect to routing inconsistencies for EBGP please observe that you
can drop any route by policy today. So max-prefix could be seen as special
type of policy.

This type of tools work as protection measure. If your customer declares
that it will advertise only 10 prefixes and suddenly he injects 1000 I
think it is good to drop those 990 and not be that much worried about
routing inconsistency. Of course in the same time NOC should and will be
alerted and proper actions taken.

Also I think you are asking if pre-policy makes sense.. Well on one hand
for EBGP you are always forced to have a policy so your policy may allow
just those 10 routes explicitly and drop rest - then max prefix becomes
redundant. But it is not always easy to keep such accurate list of allowed
prefixes from each customer edge.

So bottom line yes max prefix with no session tear down is a rope - no
doubt. But as long as you know how to use it - it may tight your network
better.

Cheers,
R.

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Fri, 25 Mar 2022 01:54:03 +0000

Syslogs do help, but may not provide enough info to debug why a specific route is missing. Bug in sender or receiver? Or because of max-prefix threshold.

So there is a prolonged duration of ambiguity for the lifetime of the session, until it is manually cleared.

I agree, it keeps things operational for a few prefixes. Hopefully those are the important ones (there’s no guarantee), otherwise we are undergoing all this ambiguity and complexity for no apparent benefit.

I think it is not same as import-policy, where we know exactly what we are dropping.

I guess it is the difference between grey failures and dark failures. Which one you want to debug, and the tradeoff.

Thanks
Kaliraj
From: Robert Raszuk <[email-masked]>
Date: Thursday, March 24, 2022 at 3:19 PM
To: Kaliraj Vairavakkalai <[email-masked]>
Cc: Susan Hares <[email-masked]>, Tony Przygienda <[email-masked]>, idr wg <[email-masked]>
Subject: Re: [Idr] Adoption call for draft-sas-idr-maxprefix-inbound-04.txt (3/10 to 3/24)
[External Email. Be cautious of content]

Kaliraj,

"When you are given a knife you can cut and hurt yourself or you can use it to slide bread to feed your family. "

First it would be very bad if any implementation is silent about such drops irrespective if they happen pre or post policy. Syslog msg should be generated in all cases.

Now in respect to routing inconsistencies for EBGP please observe that you can drop any route by policy today. So max-prefix could be seen as special type of policy.

This type of tools work as protection measure. If your customer declares that it will advertise only 10 prefixes and suddenly he injects 1000 I think it is good to drop those 990 and not be that much worried about routing inconsistency. Of course in the same time NOC should and will be alerted and proper actions taken.

Also I think you are asking if pre-policy makes sense.. Well on one hand for EBGP you are always forced to have a policy so your policy may allow just those 10 routes explicitly and drop rest - then max prefix becomes redundant. But it is not always easy to keep such accurate list of allowed prefixes from each customer edge.

So bottom line yes max prefix with no session tear down is a rope - no doubt. But as long as you know how to use it - it may tight your network better.

Cheers,
R.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 25 Mar 2022 01:05:41 -0400

Maximum prefix has been around for a long time implemented by most vendors.

But now with this standardization for interoperability it is directional
with an inbound and an outbound  specification, as well as it updates RFC
4271 for the cease notification as well as now employs pre and post maximum
prefix with the same actions that have existed historically by vendor
implementations with clamp down of peer or threshold for syslog message.

Goal of this feature is to protect customer or provider side from a flood
of routes - no change

Inbound
https://datatracker.ietf.org/doc/html/draft-sas-idr-maxprefix-inbound-04

Outbound -> I believe this was abandoned
https://datatracker.ietf.org/doc/html/draft-sas-idr-maxprefix-outbound-02

Kind Regards

Gyan

On Thu, Mar 24, 2022 at 9:54 PM Kaliraj Vairavakkalai <kaliraj=
[email-masked]> wrote:

> Syslogs do help, but may not provide enough info to debug why a specific
> route is missing. Bug in sender or receiver? Or because of max-prefix
> threshold.
>
>
>
> I agree, it keeps things operational for a few prefixes. Hopefully those
> are the important ones (there’s no guarantee), otherwise we are undergoing
> all this ambiguity and complexity for no apparent benefit.
>
>
>
> I guess it is the difference between grey failures and dark failures.
> Which one you want to debug, and the tradeoff.
>
>
>
> Thanks
>
> Kaliraj
>
> *From: *Robert Raszuk <[email-masked]>
> *Date: *Thursday, March 24, 2022 at 3:19 PM
> *To: *Kaliraj Vairavakkalai <[email-masked]>
> *Cc: *Susan Hares <[email-masked]>, Tony Przygienda <[email-masked]>,
> idr wg <[email-masked]>
> *Subject: *Re: [Idr] Adoption call for
> *[External Email. Be cautious of content]*
>
>
>
> Kaliraj,
>
>
>
> First it would be very bad if any implementation is silent about such
> drops irrespective if they happen pre or post policy. Syslog msg should be
> generated in all cases.
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 25 Mar 2022 09:04:27 +0100

Kaliraj,

Max-prefix should also log prefixes which we are dropping and reason for
it. So yes UPDATES should be parsed before being dropped - otherwise it
would be a mess.

I guess your assumption is that pre policy means pre-parsing - but that
would be fatal as we could miss also withdraws for previously "legally"
received routes - so no - that would be not the right model. Better to kill
the session in such cases.

Thx.
R/

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Sun, 27 Mar 2022 15:52:33 +0000

I was not assuming pre-parse. I imagined syslogging every dropped prefix may not scale well. So I don’t consider that as a viable production option.

Thanks
Kaliraj

Date: Friday, March 25, 2022 at 1:03 AM

Kaliraj,

Max-prefix should also log prefixes which we are dropping and reason for it. So yes UPDATES should be parsed before being dropped - otherwise it would be a mess.

I guess your assumption is that pre policy means pre-parsing - but that would be fatal as we could miss also withdraws for previously "legally" received routes - so no - that would be not the right model. Better to kill the session in such cases.

Thx.
R/

On Fri, Mar 25, 2022 at 2:54 AM Kaliraj Vairavakkalai <[email-masked]<mailto:[email-masked]>> wrote:
Syslogs do help, but may not provide enough info to debug why a specific route is missing. Bug in sender or receiver? Or because of max-prefix threshold.

Thanks
Kaliraj
From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 24, 2022 at 3:19 PM
To: Kaliraj Vairavakkalai <[email-masked]<mailto:[email-masked]>>
Cc: Susan Hares <[email-masked]<mailto:[email-masked]>>, Tony Przygienda <[email-masked]<mailto:[email-masked]>>, idr wg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Adoption call for draft-sas-idr-maxprefix-inbound-04.txt (3/10 to 3/24)
[External Email. Be cautious of content]

Kaliraj,

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 27 Mar 2022 18:20:51 +0200

Kaliraj,

I am afraid you MUST pre-parse everything before dropping even if you do
not have inbound policy. What if you get UPDATE MSG with already accepted
prefix ? What if you get WITHDRAW to an already accepted prefix ? You can't
just look at the counter reached, close the door and blindly start dropping
whatever else is coming.

As far as logging what you drop I am afraid it is a MUST. Otherwise you
can't even troubleshoot when someone calls in to ask what is going on.
However syslog is just one option. BMP could be another one etc...

Thx,
R.

On Sun, Mar 27, 2022 at 5:52 PM Kaliraj Vairavakkalai <[email-masked]>
wrote:

> I was not assuming pre-parse. I imagined syslogging every dropped prefix
> may not scale well. So I don’t consider that as a viable production option.
>
>
>
> Thanks
>
> Kaliraj
>
>
>
> *Date: *Friday, March 25, 2022 at 1:03 AM

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 28 Mar 2022 01:04:57 -0400

Dear Authors

I noticed in the  Abstract and Introduction that the draft states that the
this maximum prefix feature is being used to limit the impact of a a route
leak.

In general the maximum prefix is used on C2P PE-CE attachment circuit, but
can also be used on provider lateral and transit peering to mitigate route
leaks.

I think it would be good to mentioning the mitigation of flood of prefixes
from PE-CE edge peering as the maximum prefix feature is used predominantly
by operators as defacto standard on PE-CE edge peering for protection.

Also as this draft update RFC 4271 section 6 for the BGP FSM automatic stop
event when the maximum prefix limit is reached, I think this draft could
also take the opportunity to standardize the pre policy adj-rib-out which
has been implemented by many vendors similar to the maximum prefix which
now we are updating the standard so it would be good to add pre policy to
the RFC 4271 update.

Thoughts?

Kind Regards

Gyan

On Sun, Mar 27, 2022 at 12:20 PM Robert Raszuk <[email-masked]> wrote:

>> On Fri, Mar 25, 2022 at 2:54 AM Kaliraj Vairavakkalai <
>> [email-masked]> wrote:
>>
>> I always wondered about why such a procedure (silently discarding
>> prefixes on reaching threshold, and causing possible inconsistencies) was
>> documented as a possible approach. I think it may be good if we can
>> deprecate the existing knobs that cause this possible routing
>> inconsistencies. Unless operators find it useful in some manner that I
>> cannot think of.
>>
>>
>>
>> Now in respect to routing inconsistencies for EBGP please observe that
>> you can drop any route by policy today. So max-prefix could be seen as
>> special type of policy.
>>
>>
>>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Mon, 28 Mar 2022 18:15:35 +0000

Robert, you mis-understood.

> I was not assuming pre-parse.

This means, I was not assuming dropping prefixes before parse. :-)

I was assuming post parse, and pre-import-policy only.

Thanks
Kaliraj
Date: Sunday, March 27, 2022 at 9:20 AM

Kaliraj,

I am afraid you MUST pre-parse everything before dropping even if you do not have inbound policy. What if you get UPDATE MSG with already accepted prefix ? What if you get WITHDRAW to an already accepted prefix ? You can't just look at the counter reached, close the door and blindly start dropping whatever else is coming.

As far as logging what you drop I am afraid it is a MUST. Otherwise you can't even troubleshoot when someone calls in to ask what is going on. However syslog is just one option. BMP could be another one etc...

Thx,
R.

On Sun, Mar 27, 2022 at 5:52 PM Kaliraj Vairavakkalai <[email-masked]<mailto:[email-masked]>> wrote:
I was not assuming pre-parse. I imagined syslogging every dropped prefix may not scale well. So I don’t consider that as a viable production option.

Thanks
Kaliraj

Kaliraj,

Thx.
R/

Thanks
Kaliraj

Kaliraj,

Cheers,
R.