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

Brian Dickson <brian.peter.dickson@gmail.com> Sun, 06 November 2016 22:56 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 2D6EB129702 for <idr@ietfa.amsl.com>; Sun, 6 Nov 2016 14:56:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 8sBa3wLgHmb4 for <idr@ietfa.amsl.com>; Sun, 6 Nov 2016 14:56:27 -0800 (PST)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37521296F8 for <idr@ietf.org>; Sun, 6 Nov 2016 14:56:27 -0800 (PST)
Received: by mail-pf0-x22a.google.com with SMTP id d2so80982572pfd.0 for <idr@ietf.org>; Sun, 06 Nov 2016 14:56:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vzItWCt2gKNj+4u44s+uw2uVd7WMcIEbEfQC8NHXxgs=; b=JVwjpfxrbr/da2/7HjlPNh6xdfaNjiYpx2/r5yuXQK7dlhQ2xE4zyAmGfDHSBFwU2b wH0OxL3A7kZqup1swp27dJZcs97T7uUaRVsvmeKSqWkBaL3nSp4XNSW38kJoq+Fq6+jS OFLA5MtZF11Vbh7UGkxMDegTTLNkdiWP88LzAe4iVhIhy/mWU2PRqYhL2f+UNi45SVA6 qXLqxfby01Pn+rZm9CRNna/8w50R0QGdSNN2i3x9UN/32ZMngOwPbkcP/WqaUiT/MkPX sdQupDgeLF41Izp2gXUjUeKCCtFDwcjQ9mYIeUgkHeOmnOFH75sIHAgB+wCOy+yGGXjr YYFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vzItWCt2gKNj+4u44s+uw2uVd7WMcIEbEfQC8NHXxgs=; b=Fe6mnDF1ooubqEJpQqO/jp3+X98tRFhGvcITUexZ9Vy6DHPhT+u5FZTLCnrN8BV/E5 2esOHartr+6lIiEj0QtczegGw7qVcDE46GCmZtKlGLQu2JUIvO6I3vgfFp/6DiRRdrxN QYtl09bCrkFGKHHAK2bI0RHATB3t1gOxFLBZcWSBD9i4eY3mV7VEOEDBuqaCsKflt3D0 +8G+ku7hL2O+MWcu69xXWivFAZQJ/w+zw8N9FRcI44E2QnU0tBsyu0LJyzoDTVLeKPUY eTKxOrmmZPUXqYvMKYpbTUj3jH/FxIQ7Z+Y5Gak7tOkYCUeKCb1uYAfZys+Hxk4s5wbZ gjCA==
X-Gm-Message-State: ABUngvfpX3VxZc1wX/0311ceq+TaHbQo0cOpDQO5HI9jOG96X+9FB4PZudVVMGXSpde2Ng==
X-Received: by 10.99.115.65 with SMTP id d1mr6221088pgn.56.1478472987216; Sun, 06 Nov 2016 14:56:27 -0800 (PST)
Received: from [192.168.5.105] (c-73-92-109-167.hsd1.ca.comcast.net. [73.92.109.167]) by smtp.gmail.com with ESMTPSA id c5sm35008624pfj.71.2016.11.06.14.56.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Nov 2016 14:56:25 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Brian Dickson <brian.peter.dickson@gmail.com>
X-Mailer: iPhone Mail (14B100)
In-Reply-To: <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com>
Date: Sun, 6 Nov 2016 14:56:24 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>
References: <CAH1iCiq6jNtnkta0Bt952EQ9zOKSGt=_cCySsT5XuOKuHYO2nQ@mail.gmail.com> <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/tJ3-wcbLUQCLmotv3ieZivhbjwo>
Cc: heasley <heas@shrubbery.net>, "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: Sun, 06 Nov 2016 22:56:29 -0000


Sent from my iPhone

> On Nov 5, 2016, at 4:13 PM, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:
> In my large-community code, I have lumped them under send-community-ebgp. At this point, I am very open to suggestions for configuration. Once the code is released, it gets much harder to change configs.

The following is my opinion, but I am confident that most operators concur with it:

Large is not a "new" attribute per se.
Large is providing parity for RFC1997, for use with 32-bit ASNs.

For that reason alone, the only sane implementation approach is "off by default", so as to be consistent with the default for 1997.

If someone does not use 1997 today, either choice would be okay.

However, for those using 1997, all of their BGP peering configs are well-baked, and whatever they use for managing them has 1997 built into it.

Those ASNs will be the early adopters and heaviest receive-side users (defining their name spaces in particular). When they ask for feature parity, that includes consistency with how they deploy and manage all types of communities.

Changing the default behavior between 1997 and large would likely cause chaos, anger, and frustration.

If anyone advocates for this change, it is clear they are not listening to operators, or do not understand what they want and why they want it. Operators who have 16-bit ASNs and use 1997, want to offer identical features as relates to 32-bit target ASNs. Operators with 32-bit ASN need this to do any 1997-type things, as clients (setting large communities) or as servers (receive-side handling). It augments 1997, and is not a new or different or separate thing.

I will give an example. Suppose a largish ISP has 1000 customers and 500 peers. They allow customers to send communities with only a standard config. However , they only send communities to a select few, and then only in highly customized configs. They don't send communities to peers, and do pass communities from customers up to their transit providers.

Making the default "on" instead of "off", means large communities will leak everywhere. Filtering will happen, but not everywhere at once. This will make it harder to track down the places where filtering should be done, since whether large communities show up may depend on path selection at any given moment. The attributes changing will induce BGP churn as updates propagate. That churn may in fact trigger load-induced brown-outs and further induce churn.

Note that all of the above occurs as soon as large communities are used, even if the ISP above was a 16-bit ASN with only 16-bit ASN peers.

In other words, it is conceivable that an unintended consequence could be a long-duration or even permanent instability to the global Internet.

The use case is, IMNSHO, not compelling, so please, let's keep the default the same as it is for 1997.

(But by all means provide knobs for changing the default for a single router.)

Brian