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

heasley <heas@shrubbery.net> Mon, 07 November 2016 20:25 UTC

Return-Path: <heas@shrubbery.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C33A1295B8 for <idr@ietfa.amsl.com>; Mon, 7 Nov 2016 12:25:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnFKpJJwn_95 for <idr@ietfa.amsl.com>; Mon, 7 Nov 2016 12:25:54 -0800 (PST)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5D912948C for <idr@ietf.org>; Mon, 7 Nov 2016 12:25:54 -0800 (PST)
Received: by guelah.shrubbery.net (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 <heas@shrubbery.net>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Message-ID: <20161107202554.GI62252@shrubbery.net>
References: <CAH1iCiq6jNtnkta0Bt952EQ9zOKSGt=_cCySsT5XuOKuHYO2nQ@mail.gmail.com> <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com> <6CAFC026-6102-42BF-97FA-779457D84ECE@cisco.com> <CA+b+ERm5VVz520OhgXYTFOt9_M6_=MHLE9M-=1T+wnfw7RY83Q@mail.gmail.com> <C2C26B2F-75A0-49FB-B947-4B957611A23E@cisco.com> <CA+b+ERkieHXpXQxjGnU+dGAz2nbNzWb6DxHG6vB7X5bp9VD3+Q@mail.gmail.com> <96108A84-8016-4A24-8D9D-C08F65D07572@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <96108A84-8016-4A24-8D9D-C08F65D07572@gmail.com>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
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: <https://mailarchive.ietf.org/arch/msg/idr/72haXKjeAzzsFbV1MKQkbij3hmc>
Cc: "idr@ietf.org" <idr@ietf.org>, Robert Raszuk <robert@raszuk.net>
Subject: Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=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 <robert@raszuk.net> 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!