BGP Path Attribute Filtering, YES or NO?

Wed Jan 8 13:06:45 UTC 2020

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>