[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

BGP Path Attribute Filtering, YES or NO?




On 8/Jan/20 14:44, adamv0025 at netconsultings.com wrote:

> Would like to gather current views of a wider community on BGP Path
> Attribute Filtering (discarding selected attributes in particular, not
> treat as withdraw) as an addition to the long list of standard
> conditioning tools like max as-path length limit, limiting number of
> communities all the way to running iBGP infrastructure to carry
> Internet prefixes separate to the one carrying customersâ?? L3/L2VPN
> prefixes.
>
>  
>
> And I appreciate the topic is somewhat contentious and thereâ??s no
> simple yes or no answer either.
>
>  
>
> My view is that in a stub AS there should be no harm in discarding
> unused BGP path attributes,
>
> On transit AS-es Iâ??d expect two opposing views:
>
> One might be: â??I have a business to run and donâ??t care about some
> university experiments, so unless any of my customers specifically
> asks for some attribute Iâ??ll drop all reserved, unassigned and
> deprecated ones and might even drop some not widely used ones just to
> be on the well-trodden bug free pathâ??
>
> Other  might be: â??These experimental work is of great value to the
> community and thereâ??s a process now to announce and manage these
> experiments, what about net neutrality, and besides modern BGP
> implementations should handle well formatted attributes and if itâ??s
> not the case its good that these flaws are being exposed and fixed.â??
>
>  
>
> Please let me know your thoughts.
>

>From our side, on peering links, re-write all MED to 0 and scrubs all
communities, and replace them with our own.

On customer links, we re-write MED to 0. While we don't scrub our
customer's specific communities, we do ensure they cannot use our own,
unauthorized internal communities beyond what we've allowed them to.

Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200108/01b6be95/attachment.html>