Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)

[heasley <[e-mail]>]

Sun, Nov 06, 2016 at 07:46:10PM -0800, Brian Dickson:
> > On Nov 6, 2016, at 4:12 PM, Robert Raszuk <[e-mail]> wrote:
> > 
> > 
> > Isn't the main motivation of LC to avoid overloading the target ASN with private ASN values to embed the action ? 
> 
> It may be the motivation for having 3 x 32-bits, but the MAIN motivation is support for 32-bit ASNs.

both of these are motivations for -large-; support 32-bit ASNs AND stop
over-loading.

> It might be the case that initial deployment could incorporate 16-bit ASNs in 32-bit fields, including private ASNs.

What?  is there a case where a 16bit ASN doesnt fit in 32bits?

> Those using 1997 might want to migrate to large-only, rather than continue supporting both large and 1997. That migration could start with accepting both (1997 and large-encoded 1997 of 0000ASN16:0000ASN16:0), having customers add or switch to large, and then dropping 1997 support.
> 
> So, let's consider the implications of having large be sent by default, vs not.
> 
> When customers add the large communities, they will go everywhere if they don't filter, i.e. if they aren't aware of the need to filter large communities.
> 
> So, why would that migration be expected or considered reasonable, if the long term goal of LC is GA:target:action? Because it is the simplest, cleanest, and safest path. 
> 
> Having 1997 and large simultaneously used means possible corner cases or inconsistencies can occur. 
> 
> Once the 1997 semantics are transliterated, only then can real LC be implemented on the receiving side.
> 
> That would involve two windows of overlap: 1997 to transliterated; and transliterated to "real" LC.
> 
> And in both windows, the 1997-semantics large communities can collide, just like the conflicting cases Jakob listed.
> 
> That issue is a non-issue if the default is "off".
> 
> > Besides both are applicable to their directly connected customers so really regardless of the default those should be dropped by policy after execution/application. 
> 
> I believe this is called "blaming the victim".
> 
> There is no easy way to tell how many such conflicts would be exposed by default "on".
> 
> 20 years of  RFC1997. All with default off. 20 years of industry consolidation, staff turnover, undocumented implementations. 

20 years in that implementation...

> Assuming that no migration will occur, isn't helpful. Changing the default behavior across such migration is the risk.
> 
> Having the same behavior for large guarantees zero incremental risk, which is why I am advocating for it.

given a BGP topology of AS1 - AS2 - AS3, where AS1 & 3 recognize LCs and
AS1 sends LC 3:n:n to affect their local-pref (or whatever), this will
potentially break when AS2 updates to an o/s that recognizes LCs.  surprise!