Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129

Job Snijders <> Tue, 01 November 2016 15:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67D6212973E for <>; Tue, 1 Nov 2016 08:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.432
X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bu1SDVlHg-HN for <>; Tue, 1 Nov 2016 08:01:51 -0700 (PDT)
Received: from ( [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3235E127076 for <>; Tue, 1 Nov 2016 08:01:51 -0700 (PDT)
Received: by with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1c1aZR-0004O0-Uh (; Tue, 01 Nov 2016 15:01:50 +0000
Date: Tue, 1 Nov 2016 16:01:48 +0100
From: Job Snijders <>
To: Robert Raszuk <>
Message-ID: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <>
Cc: IETF IDR Working Group <>
Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129
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: Tue, 01 Nov 2016 15:01:52 -0000

On Tue, Nov 01, 2016 at 03:41:12PM +0100, Robert Raszuk wrote:
> > Am I to understand that you consider deployment problems not to be
> > technical problems?
> You stated clearly that Large is not subject to suffer from deployment
> problems. So what other deployment problems you envision if those types
> would be moved to early allocation by IANA?

You might misunderstand what I intended to convey, my apologies for not
being able to articulate myself better.

Large BGP Communities was assigned BGP Path attribute, by IANA according
to the Early Allocation rules (value 30 - 2016.09.26). Turns out that an
implementor had already used that codepoint. This proved to cause issues
during an experimental deployment of Large BGP Communities. Large BGP
Communities had to back to the WG, the chairs and then IANA assigned a
new codepoint (value 32 - 2016.10.26). So, today, Large BGP Communities
does not suffer from the squatted '30' codepoint, because a renumbering
effort was undertaken. The above is a description of a deployment
problem and its resolution. 

In short: any new (early) allocations should not come from tainted
codepoints. To ensure this, IANA needs instruction not to do so (that is
the draft at hand).

Maybe a pragmatic example will help clarify the situation: If IANA
assigns Path Attribute 30 as early allocation of
draft-chen-idr-geo-coordinates-03, I suspect the
draft-chen-idr-geo-coordinates effort will encounter considerable
deployment problems. This would be a waste of time for the authors and
implementors of draft-chen-idr-geo-coordinates.

> > BGP Path attribute codepoints are a global, shared resources. As
> > Internet community we have vested IANA with the authority to assign
> > resources from this pool. The social contract is that we abide by the
> > rules related to IETF and IANA. The same rules we write ourselves.
> Few days back You and others complained that Wide was not implemented
> by anyone for so many years. Now when we see it actually was
> implemented at least by few BGP code basis it is again bad.

You might not view it this way, but I am actually looking out for Wide's
chances of deployment. At this point it is not known which version of
the wide draft was implemented, or even if the implementation is
compatible with said specification. It really is in -wide-'s best
interest to _not_ use attribute 129.

> So to me the problem we need to solve is how to allow early
> implementations for any proposal on the table especially now when we
> have no two but at least 8 production BGP implementations (and
> growing). Forbidding it does not seems to me like a solution to the
> main problem.

But isnt the solution simple? I think early implementors should just
request an Early IANA Allocation and follow that process!

Kind regards,