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

Robert Raszuk <robert@raszuk.net> Sat, 05 November 2016 23:16 UTC

Return-Path: <rraszuk@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 09546129604 for <idr@ietfa.amsl.com>; Sat, 5 Nov 2016 16:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
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: 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 5aGkXz9B7AmS for <idr@ietfa.amsl.com>; Sat, 5 Nov 2016 16:16:07 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 D075C129608 for <idr@ietf.org>; Sat, 5 Nov 2016 16:16:06 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id f82so54224894wmf.1 for <idr@ietf.org>; Sat, 05 Nov 2016 16:16:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.194.188.83 with SMTP id fy19mr71586wjc.227.1478387765074; Sat, 05 Nov 2016 16:16:05 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Sat, 5 Nov 2016 16:16:04 -0700 (PDT)
In-Reply-To: <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com>
References: <CAH1iCiq6jNtnkta0Bt952EQ9zOKSGt=_cCySsT5XuOKuHYO2nQ@mail.gmail.com> <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sun, 6 Nov 2016 00:16:04 +0100
X-Google-Sender-Auth: _66vAMBCNSlGonKmAXCITSrifBs
Message-ID: <CA+b+ER=xm2bqEekLUV396Lxqxacb64E5uDFwtwDDM=2CAnGiuQ@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Content-Type: multipart/alternative; boundary=047d7bdc19d093f652054095f99b
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zesiDPebDtWKdPNLSWX_zvih_5o>
Cc: heasley <heas@shrubbery.net>, "idr@ietf.org" <idr@ietf.org>
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: 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 ?

Thx,
R.


On Sun, Nov 6, 2016 at 12:13 AM, Jakob Heitz (jheitz) <jheitz@cisco.com>
wrote:

> 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 <brian.peter.dickson@gmail.com>
> wrote:
>
>
>
> 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-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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>