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

Brian Dickson <brian.peter.dickson@gmail.com> Sat, 05 November 2016 19:52 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 805D81294BD for <idr@ietfa.amsl.com>; Sat, 5 Nov 2016 12:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id u7wwPe_A9tHD for <idr@ietfa.amsl.com>; Sat, 5 Nov 2016 12:52:52 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 57F01129569 for <idr@ietf.org>; Sat, 5 Nov 2016 12:52:52 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id p190so111764962wmp.1 for <idr@ietf.org>; Sat, 05 Nov 2016 12:52:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=NVnTvBj+sdfEdLf1nw+iG/2Cn9p1z3h//RdWAMuSVeE=; b=o7W2DPs8Ud8IhHGBFwwWAlt7aVqR7imHuqwMmmxIW98nVPvmlmWixEMG0RnLERfzsb 4c4kJkBLBwsFhWLsJaZ/JBJquqUhPDnHv3ChBpWK6HJ6T7IC19V4N6LcP8tp7O2Jivga WDxwHDfH4JzuSl5xowH37DsdCN68cic0xaWc4vSs7y5gPKMXdBu9CMKfUpL3q5CeKkst bD1OkGZJDlJrYgSmbikdC03q3NRlckQHT4QANLmA5zObKUGjZWgYpcv0nHS22Sr4yHa8 cnj+LvR4VAk2Sg7daD8BWGumZeqb6slsbDEKrmZEHVROw5EdKVVFcqfuELdcRLSCf3Jz jitg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=NVnTvBj+sdfEdLf1nw+iG/2Cn9p1z3h//RdWAMuSVeE=; b=duDIwbHkMNHCMYsj1GoJweCGMDLCXiAonve/1rjKncInDSP3w7gAwliZdKdMVS+J9O ljjhMHr6G/YKFNnpJDb5SfXbRMfKSUBjCHN2Pt4RwVDUvgtIM7M5GJFSsLAH9LI8VP7r W1+pjilD0jHSuR9jj6e1KYK3/CleCpoYuLW0aZHq2khidhtaxBaUFyi3bN1ZBiKErGwo X3YVA1bow+X922+YPxI2UC5941fWOaDJ6KAvmKMv+AtNVsw0mWsE8Ux9vv0Qh5yQTwgt anRDMKfRa8+c1b4rZbBV2wcp+oCUlxjacaV0xvyhWL7CStYv8XLwjYkgBHiAs5IcRoQT 8Hzw==
X-Gm-Message-State: ABUngvcheFzYeBkgcj5i58hYprx3q8GEVSp1fF565nm1kXoHFHR4gnjfPzivUE+kzAooJwCSfHdM+okBzegt9A==
X-Received: by with SMTP id a206mr2536014wmh.84.1478375570908; Sat, 05 Nov 2016 12:52:50 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 5 Nov 2016 12:52:50 -0700 (PDT)
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Sat, 5 Nov 2016 12:52:50 -0700
Message-ID: <CAH1iCiq6jNtnkta0Bt952EQ9zOKSGt=_cCySsT5XuOKuHYO2nQ@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Content-Type: multipart/alternative; boundary=001a114b16b8bfabb605409322cd
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/8VLUskeL4cgZtWtbMG2cjanJopE>
Cc: heasley <heas@shrubbery.net>, "idr@ietf.org" <idr@ietf.org>
Subject: [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: Sat, 05 Nov 2016 19:52:54 -0000

On Sat, Nov 5, 2016 at 11:57 AM, Robert Raszuk <robert@raszuk.net> wrote:

> ​​
>> ​​
>> However, given the heated discussion about prescribing a canonical
>> representation for -large-communities, is this a subject for an IDR rfc?
> ​IMO it is. Reason being that RFC will be read by someone who is tasked to
> implement it and unless spec clearly at least recommends​ one way we will
> have a mix of behaviors.
How about this: convert "Make it work exactly how you do RFC 1997" into an

> I really do not recall any EBC where customer were successful in asking
> vendor to change any deployed defaults. Defaults once set during
> implementation usually stay for a long time.

My experience has been, unexposed defaults can clearly only be changed by
the vendor.
Mixing versions of code, which contain DIFFERENT defaults is fraught with
No sane customer would EVER ask a vendor for different unexposed defaults.

What I have always done is, ask/tell vendor: "Expose defaults explicitly in
configs. Give us knobs to change defaults globally."  Having knobs to
change defaults based on customer-provided values, solves the
consistent-defaults problem while giving the customer control over what
that default is.

While I am sure many customers ask several vendors for this, it has not
generally happened.

(Feel free to convey this back to your management, BTW.)

>> Is changing the language
>> ​
>> about propagating recognized transitive attributes going to change these
>> vendor's defaults?
> ​Well I believe so. Notice that as much as folks likes large to be "like"
> 1997 it is not 100%. Even by your cisco example .. there is already
> send-community standard vs extended knob. Large ​will be new addition and
> in addition to "both" they will likely add also "all" keyword.

That is a vendor design decision issue.

There is nothing to prevent a vendor from implementing large, by making
large lock-step with 1997. For example, the implementation which supports
large, could apply different semantics to "send community" to send BOTH
1997 AND large communities, without changing the syntax.
(Such a change in semantics would probably be well advised to allow
optional parameters to provide knobs for "1997-only", "large-only",
"wide-only", "extended-only", or any combination of 1997, large, wide, and

> As to why we have this knob in the first place from the early days I
> recall it was based on ISPs who wanted to have RFC1997 local within their
> AS only by default - such that they do not need any extra policy in order
> not to propagate it over eBGP. Does the same design applies to Large ?

I don't recall any explanation for the default being the way it was. IMHO,
vendors are free to change THEIR default, but SHOULD apply the same default
to both 1997 and large.

Also IMHO, the "principal of least surprise" is something that vendors
should adhere to.
I cannot tell you how severely undisclosed and uncontrolled changes to
defaults across upgrades have adversely affected networks I built and ran,
and those of my compatriots.

Please, stop trying to make "better" defaults. Just give us the knobs.

> Note that I am not suggesting large must be propagate by default. But I
> think it would be good to have mandated by the spec consistency across BGP
> implementations - propagate or do not propagate.
Until the knobs are universally in place across vendors: No, and please
stop trying to advocate for this sort of thing.