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

Brian Dickson <> Mon, 07 November 2016 20:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C8C012948A for <>; Mon, 7 Nov 2016 12:38:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FittRNpntTjz for <>; Mon, 7 Nov 2016 12:38:47 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56B88129543 for <>; Mon, 7 Nov 2016 12:38:47 -0800 (PST)
Received: by with SMTP id f82so142243021wmf.1 for <>; Mon, 07 Nov 2016 12:38:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IcBWRZipju/VKAzlMtxKMNKNxdnxLZcweuDZe0AMt3U=; b=XJTizCDDNPyLflzH82yUXEoJe5Jk2lNQ+WfGlb3gvCiwa/0MdJYcB6lSZlebk73TV2 qjE3u+KWXMIj4kjEEarYTeARgi7onoUVbHPdiv5StDuB2VrmvueHpzOEN+Fvunp8w+hI +s9gDefZ4u+M2dc9t3myG01GrTjo6KKYQL663Uri7DfycJj0IqvuQwTYfWxtv5RRDIkL bqt1KWMICgVuy3uM+0aH8w3VetzxOdCVPcHuBsScFbPxtFgT37ikOlaAk2jB7J6cBk14 5pQGPsPELhZI6iScsOp7tpJCbwEUQ56N5AaWqOZsis7ol/PbmXUervLbHX3Vnbg+6trq gLxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IcBWRZipju/VKAzlMtxKMNKNxdnxLZcweuDZe0AMt3U=; b=cUngf36ZwlC3dlHL969g5/brkB91TEqHFGCMJIbmh5b25v0Ocxva0PFhYT4VMCS86G FKcuxvPgfM+bUdT2b2CfvZovqd/FCC5a+SD66U496aQ8XoS/hWvRx/7LgwHYVcyWj4r0 pXM2b72FTst33DjBYsv7TjFclR6rVJvltl0tAgoBH47aqZP8bpgwNPZ2QjKjTxVwqdhZ nGgylbYE2RjMhFTM2XJETALeNhhVjhbklLTX8HwyOgZS0RAct96fzuRe+0HAtPkqd5OM FWpOa+tlg3Ykt0CwTeKB3w/G1yy9PgkhdeYoqNnX5o19tgZhHVP2o2nbNXc7xGm6MaEp yH6Q==
X-Gm-Message-State: ABUngvf+jrnHwEWv1J88NMYaDGSHwjnclzMkYANpHyPt6CzjlwP48MyYuvtnBnRu4vjeIq7ITfAA97zMr7davg==
X-Received: by with SMTP id cx10mr7229697wjb.140.1478551125901; Mon, 07 Nov 2016 12:38:45 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 7 Nov 2016 12:38:44 -0800 (PST)
In-Reply-To: <022901d2391f$928dc660$>
References: <> <> <> <> <> <> <> <022901d2391f$928dc660$>
From: Brian Dickson <>
Date: Mon, 7 Nov 2016 12:38:44 -0800
Message-ID: <>
To: "t.petch" <>
Content-Type: multipart/alternative; boundary=047d7beb9340a448600540bc0203
Archived-At: <>
Cc: IETF IDR <>, Peter Hessler <>
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:38:49 -0000

On Mon, Nov 7, 2016 at 9:40 AM, t.petch <> wrote:

> ----- Original Message -----
> From: "Peter Hessler" <>
> To: <>
> Sent: Monday, November 07, 2016 10:23 AM
> > In OpenBGPD our default is to propagate communities; normal, extended,
> > and large.
> >
> > We have no intention on changing that default.
> >
> [snip]
> > This is implementation specific, and has nothing to do with the
> > standardization process.
> Peter
> I think that that is spot on.
> Customers will expect consistent behaviour from a supplier (and equally
> should be prepared for change if and when they change supplier).
> Of course, it may not always be that straightforward as implementations
> need to interoperate, first and foremost; but if they have been doing
> that, albeit not following the precise specification of a transitive
> attribute, then I think that consistency is what is needed.
What I think need to be (re-)emphasized, and which is the reason I started
this thread:
Interoperability is an issue, both INTRA-ASN as well as INTER-ASN.

Incremental deployability in a heterogenous environment, of an incremental
method for supporting an existing function, is something that requires
operator control.

So, while defaults matter, knobs to control those behaviors matter more.

Say someone has a network with vendors X, Y, and Z. Say they use RFC1997
communities substantially, and want to deploy LC.

Doing so requires incrementally upgrading some subset of routers, with
several iterations. Some of those upgrades are likely to be "some of X
only", etc.

Without a knob to disable (or possibly enable) propagation of LC, when
doing an upgrade to a version where LC is understood (on a single router),
the behavior will depend entirely on what vendor X's upgraded code does.

I don't consider that sufficiently constrained behavior for an incremental
upgrade. Not having a knob means either "random behavior", or "flag day"
(requiring simultaneous upgrades to all routers of all vendors).

What matters to me, as an operator, is that I can control all my routers,
especially if the default behavior of each router "flavor" differs, and
most especially if that behavior differs across software versions.

Most of the discussion has presumed homogenous ASNs, which is not
universally the case (and in my experience is seldom the case these days.)

The fact that LC will be incrementally deployed alongside 1997, makes the
issue much more significant, IMHO.

Maybe folks from various vendors (including open source implementations)
could chime in on the availability of knobs for changing global (default)
behavior on 1997 and LC, and whether those traditionally have the same
default and/or are controlled by one knob (versus two)?