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

heasley <> Sat, 05 November 2016 18:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FB161294BA for <>; Sat, 5 Nov 2016 11:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F8y2G1qY85OF for <>; Sat, 5 Nov 2016 11:35:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1D42F12947D for <>; Sat, 5 Nov 2016 11:35:18 -0700 (PDT)
Received: by (Postfix, from userid 7053) id AC1CD74E03; Sat, 5 Nov 2016 18:35:17 +0000 (UTC)
Date: Sat, 5 Nov 2016 18:35:17 +0000
From: heasley <>
To: Robert Raszuk <>
Message-ID: <>
References: <20161104201631.GA35942@Vurt.lan> <> <20161104221030.GD37681@Vurt.lan> <> <20161104230536.GJ37681@Vurt.lan> <> <20161105103526.GM952@Vurt.local> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <>
Cc: "" <>
Subject: Re: [Idr] 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 18:35:19 -0000

Sat, Nov 05, 2016 at 06:55:22PM +0100, Robert Raszuk:
> 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 ?

rfc4360 also does not make such a recommendation about a 'send-community
extended' (in cisco-ese) feature.  As I recall, it is one vendor who started
that, though I can not recall why, and many who copy their CLI have followed
suit.  One vendor has no such knob that I know of; communities are always
sent unless removed by RPL.  And, I believe there are a few open
implementations that also send communities by default.

I do wish that implementations that have this feature would default to
enabled/send, rather than disabled/filter.

However, given the heated discussion about prescribing a canonical
representation for -large-communities, is this a subject for an IDR rfc?
Isn't it a subject for a customer-vendor meeting?  Is changing the language
about propagating recognized transitive attributes going to change these
vendor's defaults?