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

[Gyan Mishra <[e-mail]>]

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 “external” 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’re 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 “known value” 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 “flood” 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’t want that to 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 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 <[e-mail]>
wrote:

>
>
> On Wed, Sep 30, 2020 at 7: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.  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.)
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD