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

Robert Raszuk <> Sat, 05 November 2016 23:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 09546129604 for <>; Sat, 5 Nov 2016 16:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 5aGkXz9B7AmS for <>; Sat, 5 Nov 2016 16:16:07 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D075C129608 for <>; Sat, 5 Nov 2016 16:16:06 -0700 (PDT)
Received: by with SMTP id f82so54224894wmf.1 for <>; Sat, 05 Nov 2016 16:16:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=SuCQRcgRIUCLxucHG6jkPvtPZYcibW6zoa61pDw2tNA=; b=mpfvrmSEezdOhZ85pzReIM9zPBB/lbRqGlGNialvITbbAl/h1nrKPNZZQE8bAU1GtF xXWoBns30WasEz4jU63FworkPJ+DJyiqA7ob0KHVmSinurPNZvfWORHEdS6CMC+QGMAw uiLF0H6KbhtCLDpNglF0cqv4d+T8iOPrlz3MojqwHfnsd4VQhjGMXJ8RK+ns6mMYG+JO zy/6ReQGooShCT7hNzs0cXHcIFCHRfmwClpmZeiVmip1WNqkymPwHEfRKEPCq9aVzwEr mZAiVzFprd8QQF/9qxZoueoYnKWZtI0hsGP5KStfF3wcTXnpu+zmfAZ89/Ba0bepDxCR bRow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=SuCQRcgRIUCLxucHG6jkPvtPZYcibW6zoa61pDw2tNA=; b=TH9qvRylaOoX7TX3zCFqumdoD6zepur4NYUxccIujOH6P3vDebtiRjSsy+gLo/7Uiw WXkFQUd8M1MQKIUQ3CrO5jbg/Ok6XMkwdjxj/+GPJ/61mgmixY54T/a46gYWWW942fal fTg0Goxf7yPCQ9oOpwjI6isB7fyJr1lp5hmEU9Nm6QMIuzdj8gCmBZzqngPxSV411Exx Bg++LOflO6/7ZQtS28gjx2RIkQPWGtw/ceBmHhH9vUE2gisDWqYB1qreanjsRljyy/dH 9A3y7jnshpqV+5oF9os8ZDsxMVIkF7dgOl4ePqMbAHEbQQ70Oo32jv21TRP8K1T1j2Wc 0kMg==
X-Gm-Message-State: ABUngvcjEK9rwbyQDjqR+Kr0C4ruTOD1VALAbw1wNfHiUoneb03zcQ6RK1tJY9XAc6SPtVv3OK1FPPZBljKmaQ==
X-Received: by with SMTP id fy19mr71586wjc.227.1478387765074; Sat, 05 Nov 2016 16:16:05 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 5 Nov 2016 16:16:04 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Robert Raszuk <>
Date: Sun, 6 Nov 2016 00:16:04 +0100
X-Google-Sender-Auth: _66vAMBCNSlGonKmAXCITSrifBs
Message-ID: <>
To: "Jakob Heitz (jheitz)" <>
Content-Type: multipart/alternative; boundary=047d7bdc19d093f652054095f99b
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: Sat, 05 Nov 2016 23:16:10 -0000

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) <>

> IOS-XR does not send communities or extended communities to eBGP neighbors
> by default.
> To send communities, you need to configure
>   send-community-ebgp
> Under the neighbor address-family.
> To send extended communities, you need to configure
>   send-extended-community-ebgp
> 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.
> Thanks,
> Jakob.
> 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.
> Brian
> _______________________________________________
> Idr mailing list