On 8/Jan/20 14:44, adamv0...@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.
