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

"Jakob Heitz (jheitz)" <> Sun, 06 November 2016 05:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2689C1294E9 for <>; Sat, 5 Nov 2016 22:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.017
X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qCuULSSOqCHB for <>; Sat, 5 Nov 2016 22:50:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB8E312949A for <>; Sat, 5 Nov 2016 22:50:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=21681; q=dns/txt; s=iport; t=1478411401; x=1479621001; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nzpoPY/qtJQdJw2ykMkbIdhasYPodU/4EoLINuYHm8Y=; b=QUJRZyCUJAPssDIYr1lioCQe78QN2KW1umqEDo4ERnm1abQfjKfMhViU E7+EGgvKCHt33lYe2MSU+osI1uHYa1k7Z0tVfcJ3yI/zvAoF8dGTcntFH 2f8Z1pfl5kkkCFIk8GAyOrCJpzdmAX2/8E1aBN7ToolJnON9QNx9qmv19 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAwD/wx5Y/5BdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy4BAQEBAR9YLU+NOJlehQiHUIUagggeAQqFewIagW8/FAECAQEBAQE?= =?us-ascii?q?BAWIohGIBAQQBAQEgSwsQAgEGAjUKAwICAh8GCxQRAgQOBRSIKgMXDpI7nT+CQ?= =?us-ascii?q?Ic3DYNuAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIY+gX0IglCCR4FzS4JGLYIvBZR?= =?us-ascii?q?HhSs1AYk/gwdEgzmBbheEWYM7hXeJCIQihAUBHjd6G4JbgjRyAYURgjoBAQE?=
X-IronPort-AV: E=Sophos;i="5.31,600,1473120000"; d="scan'208,217";a="170884077"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2016 05:50:00 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id uA65o0kf027223 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 6 Nov 2016 05:50:00 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 6 Nov 2016 00:50:01 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Sun, 6 Nov 2016 00:50:01 -0500
From: "Jakob Heitz (jheitz)" <>
To: Robert Raszuk <>
Thread-Topic: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)
Thread-Index: AQHSN546iba0WaPSYk6woE67Sz8aq6DLBUg9gABUdQCAABpB7Q==
Date: Sun, 6 Nov 2016 05:50:01 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_225A5668BE114575A81F115D9A03A96Cciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: heasley <>, "" <>
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: Sun, 06 Nov 2016 05:50:04 -0000

I cannot tell you that Robert.


On Nov 5, 2016, at 4:16 PM, Robert Raszuk <<>> wrote:

Hi Jakob,

Would you mind to elaborate how do you plan to address IOS XE BGP code base concerning the same topic ?


On Sun, Nov 6, 2016 at 12:13 AM, Jakob Heitz (jheitz) <<>> wrote:
IOS-XR does not send communities or extended communities to eBGP neighbors by default.
To send communities, you need to configure
Under the neighbor address-family.
To send extended communities, you need to configure

The reason is that many operators use communities internal to an AS for many reasons and we don't want these to accidentally leak out to the wider internet. If an operator intends to send communities outside of their own AS, then they need to make a conscious decision to do so. Along with that conscious decision, they should filter out all the internally used communities in a route-policy.

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.


On Nov 5, 2016, at 12:53 PM, Brian Dickson <<>> wrote:

On Sat, Nov 5, 2016 at 11:57 AM, Robert Raszuk <<>> 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-D?

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 peril.
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 extended).

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.

Idr mailing list<>