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

heasley <> Mon, 07 November 2016 20:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C33A1295B8 for <>; Mon, 7 Nov 2016 12:25:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TnFKpJJwn_95 for <>; Mon, 7 Nov 2016 12:25:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AC5D912948C for <>; Mon, 7 Nov 2016 12:25:54 -0800 (PST)
Received: by (Postfix, from userid 7053) id 514FC7C640; Mon, 7 Nov 2016 20:25:54 +0000 (UTC)
Date: Mon, 7 Nov 2016 20:25:54 +0000
From: heasley <>
To: Brian Dickson <>
Message-ID: <>
References: <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <>
Cc: "" <>, Robert Raszuk <>
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Nov 2016 20:25:58 -0000

Sun, Nov 06, 2016 at 07:46:10PM -0800, Brian Dickson:
> > On Nov 6, 2016, at 4:12 PM, Robert Raszuk <> 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

> 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!