From nobody Tue Oct 20 10:59:31 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE5B3A1236 for ; Tue, 20 Oct 2020 10:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vgk4lDGneUW for ; Tue, 20 Oct 2020 10:59:27 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538993A0E17 for ; Tue, 20 Oct 2020 10:59:27 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id b3so1636036vsc.5 for ; Tue, 20 Oct 2020 10:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BPO+3nwptwmVfYjq+Zb0NdV6R3HFtrxvhisT2+LuRDA=; b=viBm3LmEqDYltPsCq952TM8FuLDI39GCRuP147xzPK4mZh1ajUMpdIlbGv8blWScQ8 ej2ZjX7qc6c0+fhhC6yj/lEjphkv+TvjJNLdT9rtQPMUVN0NHLIn5sPepjlB4xJsoS8M M6r/jyPE9j3R9PxIzGOi2cdKD/BB3D+MiOyVzzZMAj8KxXN2vlbF4pFTaI7pBDC1esTR sOybWcwVO9ZOWnLeKuchn9WwSptYOiyIYplww7WXcsvZ7k4qu1oaPkkW5i9VneFysgFe bMgFmP5Ssux8OU1r7YzxBxnlzXU/takVBa50ewq//A+wrQEud6tV6h+0VnljM31rSeNB AXlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BPO+3nwptwmVfYjq+Zb0NdV6R3HFtrxvhisT2+LuRDA=; b=HyQ77bSeY9n1xLJGFyry5nRgf9ZOOSev+6wSG4b6BoMSMG1XJKKhlAdcksi/IvmNkA Uh/rLSK7Cg9mtn53MQ68d22FgKIARkxKGjguLYu8vX/TvBI4BA+z4oOIQC6e7YZ53NH1 aky7eDOOGY/1kVVZeZBdbIzLHkX+gCk3+yBOfQXRaIT4b2SAw11cV4nIMHL8a1DLevi/ gNdzaju8HY28ntlHnXkzBchBNhSpukz8IxcE9CGcAso+wZ8o8jW8l1adi6Vehdr2QtwK 9zRnMzTDF5PrbDbzywkOo+t+nXZKdoHGoaPC6roH1fFfU7TkUP22ZenWt0wm7v6fUchi CKyA== X-Gm-Message-State: AOAM531PbMN5unoxi3DGtNPque8Q3lHvxWyCqDDuQygmJwudMfnnRGOv lFIv3v0FTDetvUv1VPOlbeFNZ6+HuzJitDlQ3xgniD4u7c2bIw== X-Google-Smtp-Source: ABdhPJw6D4UCwVsiwzD3tssUdYq65LwOL3v/Zn9IjR08c7sRTMANZiCfZBDAZS1BZKws+miJXPSvkGVCb6JHiTZvBPw= X-Received: by 2002:a67:1986:: with SMTP id 128mr2816130vsz.20.1603216766305; Tue, 20 Oct 2020 10:59:26 -0700 (PDT) MIME-Version: 1.0 References: <160147241917.18722.10402627847451321205@ietfa.amsl.com> In-Reply-To: From: Gyan Mishra Date: Tue, 20 Oct 2020 13:59:14 -0400 Message-ID: To: Brian Dickson Cc: Melchior Aelmans , idr Content-Type: multipart/alternative; boundary="000000000000da898205b21dfd82" Archived-At: Subject: Re: [Idr] Fwd: I-D Action: draft-sas-idr-maxprefix-outbound-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 17:59:30 -0000 --000000000000da898205b21dfd82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Operators have in their toolbox a wide variety of filters to use from prefix list filters to as-path to custom community based filters and of course very coarse and granular filters. >From an operators POV, the maximum prefix feature is used only for special use cases, and used for specific types of peering points namely external connections outside of their administrative domain. I think context is really important as it relates to the usage of maximum prefix inbound or outbound. >From an operators perspective POV, the most widely used use case customer side of PE-CE connections for managed MPLS / SR service public or private or MPLS service that is provided by same administrative domain. The other most widely used use case is PE operator side for both public internet and private PE-CE =E2=80=9Cexternal=E2=80=9D connections leaving or entering an= administrative domain. The reason the maximum prefix command is important on customer side of PE-CE for MPLS service is case where the same ASN is used for all customer edges connected to the managed service. In such case the provider does an as-override towards the CE so the prefixes are not dropped from as-path check loop detection. In such a case as-path filters cannot be used on the customer side to permit interesting traffic so maximum prefix is required. The main issue to be subverted is AS the was inadvertently used by another customer and then with as-override on PE was hidden and a flood of prefixes we=E2=80=99re advertised by the PE from this rogue AS. The secondary issue= to be prevented is a flood of prefixes from the provider in the as-override case where accidentally an RT was provisioned to be imported on the customer VPN resulting in a flood. In this particular case reason for the clipping feature is on the customer side PE-CE private MPLS connection where the maximum prefixes is a =E2=80=9Cknown value=E2=80=9D and not random, however= disconnect of the peer would result in an outage for the customer. In this scenario the percent threshold with warning flag is not an option as that would not protect the customer of a =E2=80=9Cflood=E2=80=9D of prefixes based on the = use case described above. In this particular case which I think is a common case where you are connected to managed MPLS service or I house MPLS within same administrative domain both private MPLS use case where you know the exact maximum number of routes so you can set the maximum but if the maximum is exceeded from a flood you don=E2=80=99t want that to result in loss of serv= ice outage scenario - so it is this use case where clipping over the maximum is much better then being in a hard down outage situation. As Jacob mentioned if a flag or log message was generated stating clipping over the maximum that would alert the NOC that an event had occurred but at least an outage had been subverted and during a scheduled maintenance window the problem can be resolved. The maximum prefix command is as well used widely on the PE-CE public internet PE side see below use cases: Internet use case: Customer side PE-CE use case: The use cases for customers connected to the internet in general not used as most customers only accept a single default prefix and not the full internet table. Operator PE side PE-CE use case: Internet providers PE side gateway PE-CE connections would would generally set maximum prefix to disconnect if maximum prefix is reached. This is a secondary protection mechanism as the primary is prefix length and AS path checks. The routing loop would not occur as a result of this as the prefixes above the maximum would be dropped and those would be more then likely result of the flood of routes scenario so routes that should be filtered during the flood event. Even if some of interesting prefixes in the BGP update were not accepted at least the end result would not be an outage as with the peer disconnecting requiring manual intervention. This clip feature would be an option elected by the operator PE side or CE side to chose to use or not use. In general this would never be used by operator PE side and really would be an option on CE side for flexibility to prevent an outage. Their maybe special corner case on PE side if there are resource issues on the PE and maximum prefix is set per VPN is not enough and the operator on PE side decides it does not want to disconnect critical customers per their Ask to avoid an outage. I understand this is more of a GROW topic and I can take it up with that WG. Also as an aside, as this is a command feature implemented by most vendors and not anything intrinsic to BGP operation, I was surprised that their is a specification for maximum prefix. As this is a locally significant feature and does not require any interoperability could be something really addressed directly by vendors as well. Thanks Gyan On Wed, Oct 7, 2020 at 4:10 PM Brian Dickson wrote: > > > On Wed, Sep 30, 2020 at 7:53 AM Gyan Mishra 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 t= he >> routes above the upper limit and provide this option for both inbound an= d >> outbound directions. This was the PE resources are not impacted as well= as >> the customer peer still remains in an Up state. >> >> Thanks >> >> Gyan >> > > As most other folks responding have already said, this is a terrible idea= . > > At the very most, this sort of thing should only be an option for very > specific AFI/SAFI combos. > > Please do NOT permit this behavior on the AFI/SAFI for unicast IPv4 or > unicast IPv6 (i.e., "the internet"). > > Brian Dickson > (speaking for myself, but representing I hope the entirety of the GROW > community and internet operators everywhere, who have suddenly had a > strange feeling that something bad is happening somewhere.) > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000da898205b21dfd82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Operators have in their toolbox a wide var= iety of filters to use from prefix list filters to as-path to custom commun= ity based filters and of course very coarse and granular filters. =C2=A0

From an operators POV, the= maximum prefix feature =C2=A0is used only for special use cases, and used = for specific types of peering points namely external connections outside of= their administrative domain.

I think context is really important as it relates to the usage of= maximum prefix inbound or outbound. =C2=A0

From an operators perspective POV, the most widely used= use case customer side of =C2=A0PE-CE connections for managed MPLS / SR = =C2=A0service public or private or MPLS service that is provided by same ad= ministrative domain.=C2=A0 The other most widely used use case is PE operat= or side for both public internet and private PE-CE =E2=80=9Cexternal=E2=80= =9D connections leaving or entering an administrative domain.

The reason the maximum prefix command= is important on customer side of PE-CE for MPLS service is case where the = same ASN is used for all customer edges =C2=A0connected to the managed serv= ice.=C2=A0 In such =C2=A0case the provider does an as-override towards the = CE so the prefixes are not dropped from as-path check loop detection. In su= ch a case as-path filters cannot be used on the customer side to permit int= eresting traffic so maximum prefix is required.=C2=A0 The main issue to be = subverted is AS the was inadvertently used by another customer and then wit= h as-override on PE was hidden and a flood of prefixes we=E2=80=99re advert= ised by the PE from this rogue AS.=C2=A0 The secondary issue to be prevente= d is a flood of prefixes from the provider in the as-override case where ac= cidentally an RT was provisioned to be imported on the customer VPN resulti= ng in a flood.=C2=A0 In this particular case reason for the clipping featur= e is on the customer side PE-CE private MPLS connection where the maximum p= refixes is a =E2=80=9Cknown value=E2=80=9D and not random, however disconne= ct of the peer would result in an outage for the customer.=C2=A0 In this sc= enario the =C2=A0percent threshold with warning flag is not an option as th= at would not protect the customer of a =E2=80=9Cflood=E2=80=9D of prefixes = based on the use case described above.=C2=A0 In this particular case which = I think is a common case where you are connected to managed MPLS service or= I house MPLS within same administrative domain both private MPLS use case = where you know the exact maximum number of routes so you can set the maximu= m but if the maximum is exceeded from a flood you don=E2=80=99t want that t= o result in loss of service outage scenario - so it is this use case where = clipping over the maximum is much better then being in a hard down outage s= ituation.=C2=A0 As Jacob mentioned if a flag or log message was generated s= tating clipping over the maximum that would alert the NOC that an event had= occurred but at least an outage had been subverted and during a scheduled = maintenance window the problem can be resolved.

=
The maximum prefix command is as well used widely o= n the PE-CE public internet PE side see below use cases:

Internet use case:

Customer side PE-CE use case:

The use cases for customers connecte= d to the internet in general not used as most customers only accept a singl= e default prefix and not the full internet table.

Operator PE side PE-C= E use case:

Internet pro= viders PE side gateway PE-CE connections would would generally set maximum = prefix =C2=A0to disconnect if maximum prefix is reached. This is a secondar= y protection mechanism as the primary is prefix length and AS path checks.= =C2=A0

The routing loop = would not occur as a result of this as the prefixes above the maximum would= be dropped and those would be more then likely result of the flood of rout= es scenario so routes that should be filtered during the flood event.=C2=A0= Even if some of interesting prefixes in the BGP update were not accepted a= t least the end result would not be an outage as with the peer disconnectin= g requiring manual intervention.

This clip feature would be an option elected by the operator PE s= ide or CE side to chose to use or not use. =C2=A0
In general this would never be used by operator P= E side and really would be an option on CE side for flexibility to prevent = an outage. =C2=A0

Their = maybe special corner case on PE side if there are resource issues on the PE= and maximum prefix is set per VPN is not enough and the operator on PE sid= e decides it does not want to disconnect critical customers per their Ask t= o avoid an outage.

I und= erstand this is more of a GROW topic and I can take it up with that WG. =C2= =A0

Also as an aside, as= this is a command feature implemented by most vendors and not anything int= rinsic to BGP operation, =C2=A0I was surprised that their is a specificatio= n for maximum prefix.=C2=A0 As this is a locally significant feature and do= es not require any interoperability could be something really addressed dir= ectly by vendors as well.=C2=A0

Thanks=C2=A0

G= yan

On Wed, Oct 7, 2020 at 4:10 PM Brian Dickson <brian.peter.dickson@gmail.com> wrote:=
=

On Wed, Sep 30, 2020 at 7:53 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:
= Hi Authors=C2=A0


Would it be possible to modify the action so that we h= ave the option to not disconnect the peer and allow the peer to remain UP s= tate but clip the routes above the upper limit and provide this option for = both inbound and outbound directions.=C2=A0 This was the PE resources are n= ot impacted as well as the customer peer still remains in an Up state. =C2= =A0=C2=A0

Thanks=C2=A0

Gyan

As most other folks responding have already said, this is= a terrible idea.

At the very most, this sort of t= hing should only be an option for very specific AFI/SAFI combos.
=
Please do NOT permit this behavior on the AFI/SAFI for unica= st IPv4 or unicast IPv6 (i.e., "the internet").
=

Brian Dicks= on
(speaking for myself, but representing I hope the entirety of = the GROW community and internet operators everywhere, who have suddenly had= a strange feeling that something bad is happening somewhere.)=C2=A0
<= /div>
--
--000000000000da898205b21dfd82--