Re: [Idr] Review of draft-ietf-large-community-06.txt

Robert Raszuk <robert@raszuk.net> Sat, 05 November 2016 17:55 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 817BB1294D8 for <idr@ietfa.amsl.com>; Sat, 5 Nov 2016 10:55:28 -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 nwFTlIs8nPX8 for <idr@ietfa.amsl.com>; Sat, 5 Nov 2016 10:55:26 -0700 (PDT)
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 B57BC1294F8 for <idr@ietf.org>; Sat, 5 Nov 2016 10:55:25 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id a197so108322795wmd.0 for <idr@ietf.org>; Sat, 05 Nov 2016 10:55:25 -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=rzNF8z6bVN1+xyZEWlVEyOpcLYowyZ69iDN2yOTdkik=; b=BgkPy64ddmbXq63+W8DVskIwDmYe63tDBdphSLNlSIkcaUskjFFy11eL/ftbWG/YSP gEnpY/Svybo2sgp8eYeKH5tGPWIGBpjlaKQlBcH5g+4Qib6UCWpQxbNctwx8Q1I31tNe kORTY2SCYdU+a32qKr7FEWF2S9osTHpoP/Dm4XF2SLrOTb3dH8L7mR4kiVkbUFxDE0QV uoEBvmgPHWeCokKJJDCU5u0d8IUpVo7jXhKfsK+4I4KoV7Db8KrkdblCKCqZcskMv6VO +rgQdraPtNHtdjJvR/P+MW7s3G9CLG0CCSD/jLHmg3xvTe2NR6fAO597LpzZECbggS7Q JU6w==
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=rzNF8z6bVN1+xyZEWlVEyOpcLYowyZ69iDN2yOTdkik=; b=FN2zoThpkjaJlvWczTbqfsSyZ65Tenh6h4vTcN1fAlhHEGBx42Ymr7Aa1pvlHq+Nmn 5qyh0XTQ2172rl6NZCA6luiUGCBUgfMXz+RPZbsKBU9aFuC9ibATtEVr0PEzmDi2PxVy KJyJKm/h/NSHo5pCcAcAil/2+Usclc3r+RsFED+dKWqwoOiZGbMCho+oezvk+aoqCz8m u31OsyCIlnYS1drRmdopxtzrU5WkCJEpq5JfdBtw+yZOZv3os3mS8WhJfnIMdWxslm52 I0MDoCMSvOkshsGU48R8rYeT/QKUC6xI9XPuaaFu3JkiOObuUCu/giXTnaYvvs104mMP aUEw==
X-Gm-Message-State: ABUngvfKT0cwD0PDZHACfhFe3PPnbhuSWnf0BnIDiBvYDGL0+/E58oS5qcFrw78+fTcS7u/Q1zerRsJb9st2hw==
X-Received: by 10.194.187.103 with SMTP id fr7mr9260092wjc.99.1478368524218; Sat, 05 Nov 2016 10:55:24 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.80.137.69 with HTTP; Sat, 5 Nov 2016 10:55:22 -0700 (PDT)
In-Reply-To: <20161105174229.GG98782@shrubbery.net>
References: <95F42982-7DCF-46A9-A26C-71EF70DB3C59@apnic.net> <20161104195346.GK961@Vurt.local> <20161104201631.GA35942@Vurt.lan> <8a293ce4fc134657aa98134b5017d92e@XCH-ALN-014.cisco.com> <20161104221030.GD37681@Vurt.lan> <0919e676e12d49d1a2ba30f4acc3b273@XCH-ALN-014.cisco.com> <20161104230536.GJ37681@Vurt.lan> <19AB2A007F56DB4E8257F949A2FB9858C87AFC6E@NKGEML515-MBX.china.huawei.com> <20161105103526.GM952@Vurt.local> <CA+b+ERnRJ5Ko9XXF+_wxRUeWVGV5NuwmewSo0nGg-cCyBQNx2g@mail.gmail.com> <20161105174229.GG98782@shrubbery.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 5 Nov 2016 18:55:22 +0100
X-Google-Sender-Auth: e4OElIA3sW78D5eISDRg2O8h63A
Message-ID: <CA+b+ER=jvwh02+MauOqaGt=S-65CWVEDeg_PwUxm2qx6OURdOQ@mail.gmail.com>
To: heasley <heas@shrubbery.net>
Content-Type: multipart/alternative; boundary=047d7bd6bc9cbbb8080540917eea
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1q1WuMdmF0PM2s7PYC_Vj7t2gQA>
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] 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 17:55:28 -0000

Heas,

All true .. I posted my question as perhaps it really makes sense to modify
the defaults for both 1997 and large.

To share the experience from a lot of global deployments of SAFI 128
propagation of extended communities was the biggest pain for 100s customers
to keep remembering to enable send-community extended|both knob on each
session.

And as you know SAFI 128 is pretty useless without RTs so keeping such
defaults there on both IBGP and EBGP sessions was just wrong.

Here in the case of Large Communities folks clearly indicated need to use
it across multiple ASNs. And that is cool. Except you have zero control how
peer of your provider will handle it.

So today non upgraded eBGP router will propagate it. When new OS is loaded
(maybe for completely different reason) which can recognize LC attribute
unless the knob is in place it will be dropped.

Perhaps it make sense to spell this out in the draft that large communities
attribute should be propagated by default unless otherwise suppressed by
policy ?

Thx,
r.


On Sat, Nov 5, 2016 at 6:42 PM, heasley <heas@shrubbery.net> wrote:

> Sat, Nov 05, 2016 at 06:18:36PM +0100, Robert Raszuk:
> > Hi Job,
> >
> > > By default, the BGP speaker does not send/transmit community
> > > > attributes. Even if the COMMUNITIES path attribute is an optional
> > > > transitive attribute. This is the current reality application.
> > >
> > > *​​Then change your default!*
> > >
> >
> > ​Are you making a recommendation here ​that BGP implementations should
> now
> > be modified to send BGP communities to EBGP (and obviously IBGP) peers by
> > default ?
> >
> > Do you mean that only for large communities or also for standards and
> > extended communities ?
> >
> > I think Shunwan's point is very valid and it seems by making above
> > recommendation to modify the BGP implementations default you agree with
> it.
> > If so draft should reflect this as this is no longer market nor EBGP
> peers
> > agreement.
>
> I do not believe Job made either recommendation.  He merely said that
> Shunwan as an implementer (I am assuming) could change their
> implementation's
> default.
>
> Job did write that it was adventageous for -large- to have similar
> properties
> as rfc1997.  neither docs make recommendations about the feature to which
> Shunwan is referring.
>