Re: [Idr] Fwd: I-D Action: draft-sas-idr-maxprefix-outbound-00.txt

[Job Snijders <[e-mail]>]

Dear Jakob, Warren, Ben, Gyan, others,

I agree that for Internet routing purposes it probably is very
undesirable to keep a connection up and 'clip' when the Maximum Prefix
Limit is reached. However, RFC 4271 explicitly permits this type of
behavior, RFC 4271 Section 6.7:

    "A BGP speaker MAY support the ability to impose a
    locally-configured, upper bound on the number of address prefixes
    the speaker is willing to accept from a neighbor.  When the upper
    bound is reached, the speaker, under control of local configuration,
    either (a) discards new address prefixes from the neighbor (while
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    maintaining the BGP connection with the neighbor), or (b) terminates
    the BGP connection with the neighbor."

I think Jakob's suggestion to add warning text is the best path forward,
I don't think this *clarification* RFC is the place to undefine this
type of (potentially problematic) functionality.

Kind regards,

Job

On Wed, Oct 07, 2020 at 12:36:16AM +0000, Jakob Heitz (jheitz) wrote:
> Or at least add some warning text to the option to the effect of:
> 
> If the max-prefix limit causes excess prefixes not to be announced
> rather than a session termination, then the prefixes that are not announced
> are unknown. Differing unknown sets of prefixes not being advertised
> by multiple routers can cause forwarding loops.
> 
> Or specify the option for session non-termination for external BGP sessions only.
> 
> Regards,
> Jakob.
> 
> -----Original Message-----
> From: Idr <[e-mail]> On Behalf Of Warren Kumari
> Sent: Tuesday, October 6, 2020 1:19 PM
> To: Gyan Mishra <[e-mail]>
> Cc: idr <[e-mail]>
> Subject: Re: [Idr] Fwd: I-D Action: draft-sas-idr-maxprefix-outbound-00.txt
> 
> <no hats>
> On Wed, Sep 30, 2020 at 10:53 AM Gyan Mishra <[e-mail]> wrote:
> >
> > Hi Authors
> >
> >
> > Would it be possible to modify the action so that we have the option to not disconnect the peer and allow the peer to remain UP state but clip the routes above the upper limit and provide this option for both inbound and outbound directions.
> 
> Errrr... how sure are you that this is the behavior that you *want*?
> If you have tripped the max-prefixes limit it's almost always:
> 1: things have been slowly growing over time, you've tripped your
> warning limit. The right thing to do here is carefully look at the
> prefixes, make sure they are what you expect, and bump it up by a bit.
> 2: you've just borked your filters and are now trying to leak full
> tables to your peers. The right thing to do here is tear the session
> down and go do penance...
> 
> I strongly suggest taking this question to GROW / NOGs before adding a
> "send as many as you can and then start filtering" option; tripping
> the hard limit should be the same as a circuit breaker, not a
> resistor.
> 
> W
> 
> > This was the PE resources are not impacted as well as the customer peer still remains in an Up state.
> >
> > Thanks
> >
> > Gyan
> >
> > On Wed, Sep 30, 2020 at 9:34 AM Melchior Aelmans <[e-mail]> wrote:
> >>
> >> Hi IDR,
> >>
> >> As suggested in earlier WG meetings (both in GROW and IDR) we have split the Maximum Prefix Limits draft into Maximum Prefix Limits Outbound and Maximum Prefix Limits Inbound.
> >> The authors are looking for your feedback and input on both.
> >>
> >> Thanks,
> >> Melchior
> >>
> >> ---------- Forwarded message ---------
> >> From: <[e-mail]>
> >> Date: Wed, Sep 30, 2020 at 3:27 PM
> >> Subject: I-D Action: draft-sas-idr-maxprefix-outbound-00.txt
> >> To: <[e-mail]>
> >>
> >>
> >>
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>         Title           : Revised BGP Maximum Prefix Limits Outbound
> >>
> >>
> >>         Authors         : Melchior Aelmans
> >>
> >>
> >>                           Massimiliano Stucchi
> >>
> >>
> >>                           Job Snijders
> >>
> >>
> >>         Filename        : draft-sas-idr-maxprefix-outbound-00.txt
> >>
> >>
> >>         Pages           : 9
> >>
> >>
> >>         Date            : 2020-09-30
> >>
> >>
> >>
> >>
> >>
> >> Abstract:
> >>
> >>
> >>    This document updates RFC4271 by adding a control mechanism which
> >>
> >>
> >>    limits the negative impact of outbound route leaks (RFC7908) in order
> >>
> >>
> >>    to prevent resource exhaustion in Border Gateway Protocol (BGP)
> >>
> >>
> >>    implementations.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >>
> >>
> >> https://datatracker.ietf.org/doc/draft-sas-idr-maxprefix-outbound/
> >>
> >>
> >>
> >>
> >>
> >> There are also htmlized versions available at:
> >>
> >>
> >> https://tools.ietf.org/html/draft-sas-idr-maxprefix-outbound-00
> >>
> >>
> >> https://datatracker.ietf.org/doc/html/draft-sas-idr-maxprefix-outbound-00
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of submission
> >>
> >>
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >>
> >>
> >>
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >>
> >>
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >>
> >> I-D-Announce mailing list
> >>
> >>
> >> [e-mail]
> >>
> >>
> >> https://www.ietf.org/mailman/listinfo/i-d-announce
> >>
> >>
> >> Internet-Draft directories: http://www.ietf.org/shadow.html
> >>
> >>
> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >> Idr mailing list
> >>
> >> [e-mail]
> >>
> >> https://www.ietf.org/mailman/listinfo/idr
> >>
> > --
> >
> >
> > Gyan Mishra
> >
> > Network Solutions Architect
> >
> > M 301 502-1347
> > 13101 Columbia Pike
> > Silver Spring, MD
> >
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr
> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr