Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt

Jeffrey Haas <> Thu, 19 September 2013 14:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2830A21F937E for <>; Thu, 19 Sep 2013 07:11:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.499
X-Spam-Status: No, score=-101.499 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iZ6HYAgyW7lg for <>; Thu, 19 Sep 2013 07:11:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 122D521F944C for <>; Thu, 19 Sep 2013 07:11:28 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 24958C395; Thu, 19 Sep 2013 10:11:13 -0400 (EDT)
Date: Thu, 19 Sep 2013 10:11:13 -0400
From: Jeffrey Haas <>
To: Susan Hares <>
Message-ID: <20130919141113.GK8137@pfrc>
References: <025b01ceb0b4$01682f50$04388df0$>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <025b01ceb0b4$01682f50$04388df0$>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: idr wg <>,, "'John G. Scudder'" <>, 'Yakov Rekhter' <>
Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Sep 2013 14:11:32 -0000

On Fri, Sep 13, 2013 at 03:03:59PM -0400, Susan Hares wrote:
> Just in case the last message on this topic got caught in August doldrums,
> we are extending the WG last call for 1 more week: 
> IANA Registries for BGP Extended Communities
> draft-ietf-idr-extcomm-iana-00.txt

As usual, I'm behind in my email.  However, I strongly support the last call
on this draft.

The life of the extended communities feature has been somewhat muddled
across its lifetime from original I-D to its RFC state.  A significant
portion of its lack of clarity has been the appearance, even though not
actually stated in the draft or other I-Ds or RFCs that add related code
points, that things are far more structured than they're really specified.

Examples as a young BGP implementor had included presuming the transitivity
bit is simply a bit rather than defining a separate code space.  The same
thing holds for the IANA bit.

Additional points of confusion have tended to include the sub-type field
which is effectively in many implementations a "format type", is shown that
this is explicitly only so for specific types - and that it may be distinct
depending on the I or T bits.

Finally, the issues surrounding allocation policy were significantly
tightened up as the original extended community drafts went from I-D to RFC,
this document further normalizes the "experimental" space as having long
lived code points in it, such as the RFC 5575 flowspec redirect-to-vrf

In my opinion, this work is not only long overdue, but strongly necessary to
help avoiding further semantic drift in the extended community registries
and related accidentally incorrect implementations.

Did I mention I support this document? :-)
(And if you haven't chimed in but have a BGP implementation, you should do
so as well.)

-- Jeff