Re: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution

[Jeffrey Haas <[e-mail]>]

Sriram,

On Wed, Mar 31, 2021 at 05:16:47PM +0000, Sriram, Kotikalapudi (Fed) wrote:
> >You can thus just get a FCFS extended community from a
> >transitive space TODAY and
> >it'd probably do most of what you want.  One of the beneficial properties
> >that extended communities have is the transitivity is at least understood
> >and well deployed.
> 
> I was hoping for a confirmation of that nature. So, that is good to hear.
> 
> >That said, there's still no guarantee that some operator may choose to just delete them all at an ASBR.
> 
> Yep. It is not a perfect world. But are you suggesting that no community-based approach (EC or LC or ?) is worth pursuing? 

The point Jakob follows up with in this thread strongly suggests communities
are not a viable mechanism.

> >...the headache you're going through is trying to avoid the work of creating a new attribute. 
> 
> There is already a separate draft in IDR that has passed WGLC, and it uses a new transitive BGP Path Attribute 'Only to Customer (OTC)':
> https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-15
> We view that as a longer-term solution, while the EC/LC-based approach is meant to be deployed quickly.  

I've been caught napping on the changes in open policy and will have to go
read this.

> >A discussion I'd suggest is that we've had a need for a "BGP routing
> >security" attribute where we can put these various proposals:
> >- It's not a victim of existing community practices.
> >- Policy might still interact with it, but the baseline maintenance
>   expectations can be set for it.
> >- It can be extensible so new components can be added incrementally.
> 
> In the above, are you suggesting BGP Path Attribute or a new type of Community that comes with transitivity guarantees?

The biggest headache with getting new features into BGP as attributes is the
first bit of code point assignment.  If such a feature has an extension
mechanism, new things within that path attribute are usually much easier to
get deployed, and it helps their development and deployment velocity.

We're not exactly low on BGP Path Attribute code points.  But it'd be nice
if the incremental deployment story for bgp security features is better than
the incremental micro feature of the day.  Minimally, as Jakob notes, it'll
make the deployment story nicer for the service providers that have harmed
incremental deployment of new features by proactive filtering.

-- Jeff