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

Robert Raszuk <robert@raszuk.net> Sun, 06 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 CD67E1299CA for <idr@ietfa.amsl.com>; Sun, 6 Nov 2016 15:16:45 -0800 (PST)
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 biWHlrg8RvJL for <idr@ietfa.amsl.com>; Sun, 6 Nov 2016 15:16:44 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 E6A9A1299BF for <idr@ietf.org>; Sun, 6 Nov 2016 15:16:43 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id p190so151133265wmp.1 for <idr@ietf.org>; Sun, 06 Nov 2016 15:16:43 -0800 (PST)
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=JOagD5CR5w4brtIl23Tt8IsSNvlUKs+e8IZPCW3FNV8=; b=BAl44Dx7hmzYUtuJdkPtvRrWsT5292zL2T33AXFP1OYl0wzP1vywgBtUzZPDB8jj93 kmmWtrdkWKO4U75h4Y3Kv5hk71GcwH34Dh+w81wKCCowAXc/B9NxvthltDUI4yI2pXlH qfUjksalUMK0tcZ5YIEEO1Ig8MEhYVcvD2XloLt8eYVpvbcVLS6jEocjWfYUmpllxBnY c37sWxBc3GSsxSXXlb1/q7xaG1jkYbKGWC4yrfaQQRRkYkAl0aKNQV0GP5k1fzwDDp61 fLUUZOkSmKL9k8kxP4jldeeVUzmjn9zWfCoXFTdOUooxJrLtXgkaNfnxsmtnRH+6a4pj ArDQ==
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=JOagD5CR5w4brtIl23Tt8IsSNvlUKs+e8IZPCW3FNV8=; b=OuR0tVcp1QA1niGjF6ec3PxAtSaxv5brm3jxZbN4wUNfmIo7b0HYHdkM5FHhF2NrPs WcJGBe0zRzVyUYs3F1s2nLmrvCnWm6mXPluFrXHYsBC3i1FZ4LPCy+VYeZltBhjY1DoE 8v0x3moDMdFd7XUuN6RAK0WHTa6RoUaPfJvLd9Jte6BYEonM5T9AXHkbXhur8ZaEO6Zz w5W3hg38sR0IvYsDUk6WdX56oUchEhNStKbaW6vx+UHyLMFyc8vjE/0nEjxnpIHrji6N LESP5hkyD3Jv88fRD79PxAyIO8lJqDlXVRY65ZrRpURKG3j44Wt+A22iRtGpt8CsOawB qumw==
X-Gm-Message-State: ABUngve6nqnJzLJgep2RaEaUqBfSpzBk+4Q7Sa2BCNgL8/YhGZ26ez8NSmZlDF4iUPhkqDoluJyx/o9qtEHecg==
X-Received: by 10.194.26.133 with SMTP id l5mr3080405wjg.4.1478474202321; Sun, 06 Nov 2016 15:16:42 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Sun, 6 Nov 2016 15:16:41 -0800 (PST)
In-Reply-To: <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>
References: <CAH1iCiq6jNtnkta0Bt952EQ9zOKSGt=_cCySsT5XuOKuHYO2nQ@mail.gmail.com> <86860386-9C2B-4BD5-B457-2A6DA5446CF3@cisco.com> <17E646EF-4633-423B-9AC4-B53D49C90632@gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 7 Nov 2016 00:16:41 +0100
X-Google-Sender-Auth: WbQ8dv_PJVwbR-gO4aHSxHcwJ-8
Message-ID: <CA+b+ERk8NgT4RB9Hv_yrPRb2Gv2RVU9EjXUpdMc=mg0U7TeykQ@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Content-Type: multipart/alternative; boundary=089e0160a4d6a39b560540aa191e
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/nW-lE5D9KHahU4_a0xNEB97n6zc>
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: Sun, 06 Nov 2016 23:16:46 -0000

Hello Brian,

> The attributes changing will induce BGP churn as updates propagate.
> That churn may in fact trigger load-induced brown-outs and further
> induce churn.

BGP communities are not used in best path selection and their presence or
non presence have zero influence to change in bgp path selection hence no
direct relation to bgp churn what so ever (leave alone quote "permanent
instability to the global Internet").

If you are concerned that honoring by advertiser his own published
community will introduce BGP churn (as embedded actions may result in for
example AS_PATH prepend action) and that you are going to save the global
Internet by default filtering large communities  which otherwise may reach
the given's community advertising AS - it is your understanding on how BGP
works .. not mine.

Kind regards,
Robert.


On Sun, Nov 6, 2016 at 11:56 PM, Brian Dickson <
brian.peter.dickson@gmail.com> wrote:

>
>
> Sent from my iPhone
>
> > On Nov 5, 2016, at 4:13 PM, Jakob Heitz (jheitz) <jheitz@cisco.com>
> wrote:
> > 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.
>
> The following is my opinion, but I am confident that most operators concur
> with it:
>
> Large is not a "new" attribute per se.
> Large is providing parity for RFC1997, for use with 32-bit ASNs.
>
> For that reason alone, the only sane implementation approach is "off by
> default", so as to be consistent with the default for 1997.
>
> If someone does not use 1997 today, either choice would be okay.
>
> However, for those using 1997, all of their BGP peering configs are
> well-baked, and whatever they use for managing them has 1997 built into it.
>
> Those ASNs will be the early adopters and heaviest receive-side users
> (defining their name spaces in particular). When they ask for feature
> parity, that includes consistency with how they deploy and manage all types
> of communities.
>
> Changing the default behavior between 1997 and large would likely cause
> chaos, anger, and frustration.
>
> If anyone advocates for this change, it is clear they are not listening to
> operators, or do not understand what they want and why they want it.
> Operators who have 16-bit ASNs and use 1997, want to offer identical
> features as relates to 32-bit target ASNs. Operators with 32-bit ASN need
> this to do any 1997-type things, as clients (setting large communities) or
> as servers (receive-side handling). It augments 1997, and is not a new or
> different or separate thing.
>
> I will give an example. Suppose a largish ISP has 1000 customers and 500
> peers. They allow customers to send communities with only a standard
> config. However , they only send communities to a select few, and then only
> in highly customized configs. They don't send communities to peers, and do
> pass communities from customers up to their transit providers.
>
> Making the default "on" instead of "off", means large communities will
> leak everywhere. Filtering will happen, but not everywhere at once. This
> will make it harder to track down the places where filtering should be
> done, since whether large communities show up may depend on path selection
> at any given moment. The attributes changing will induce BGP churn as
> updates propagate. That churn may in fact trigger load-induced brown-outs
> and further induce churn.
>
> Note that all of the above occurs as soon as large communities are used,
> even if the ISP above was a 16-bit ASN with only 16-bit ASN peers.
>
> In other words, it is conceivable that an unintended consequence could be
> a long-duration or even permanent instability to the global Internet.
>
> The use case is, IMNSHO, not compelling, so please, let's keep the default
> the same as it is for 1997.
>
> (But by all means provide knobs for changing the default for a single
> router.)
>
> Brian