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

Robert Raszuk <> Tue, 01 November 2016 15:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DF3D127076 for <>; Tue, 1 Nov 2016 08:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XHeg7k3Z9Sx0 for <>; Tue, 1 Nov 2016 08:14:37 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B24601298D3 for <>; Tue, 1 Nov 2016 08:14:32 -0700 (PDT)
Received: by with SMTP id u144so16136335wmu.1 for <>; Tue, 01 Nov 2016 08:14:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vT0yF55fZkyhdgBP9FnP9bYABP2Zxra+FlWzpKBZ1jM=; b=dDlgLYNUKutQw3XGwgvKVx4jdqTWLqT6GP+qenqN2TD8p2+oVfOlZ44rkXaqYrSQXa IlFVnVtuwvF4ziHMXmmCIgngLRKdu+3x5YIsowT8heD6Fzca2suuv/2z2XSUrgEd2lii uVYkh4/I/dx4s9gyctBEiJOtHysr/U4VtPweuC83JmsuY5HNE6M1jFj5XR3wc3+gTRem UwK/C3g4uYBlZceHO1vEa3zmoPMbJgHvHLU7VPTinPGz83sbZTaCyljBjbCUBm60WLS+ 443zmAAgiVehZWww+hj0JRDnJS1UKJs24IWjC57S2UROL7zoEenzrUOdJDiwRV8XrxFq Yz+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vT0yF55fZkyhdgBP9FnP9bYABP2Zxra+FlWzpKBZ1jM=; b=Jx0XywuyvtraFrUVZQPDw0ldzY+A4ZjtR0SiGpXgKd7tgWqvRMb77R4XpTu0ELSqXC LFzRINU/0XUA2niZU4vzX8+oeYTqvoFf58c/Xh2Lk9qti4R8ENGBVsqyxKMEIRo5j3RQ z7fw8JBnrEO4qd6IK/p4nkTT2mPlr7Xp2z0nXQ/S4rDu+8tQxFwAcLeu3nUJnoWgq2Q+ NR+ZQP0S0cMq6+V6FRIN/q331Ibwfh6dtj81skbWCj5gGhMPTxNxY0bPXZLXyiIF/YOk haljab+W7NQo5BLR0YOgiBZrRbImacErJq+3SQ4lzi5bXlw1akkys7DkWLl6h8QNJKxU FHcg==
X-Gm-Message-State: ABUngvcm+8QCz/ZsVyZds6FLc1pInBT2dVYvRRkJftRJ5G8uDOzCwdjMp1DMGaD6LW8zE+ZOv2e8dRHGf+RBhg==
X-Received: by with SMTP id j194mr1895380wmf.73.1478013271226; Tue, 01 Nov 2016 08:14:31 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 1 Nov 2016 08:14:30 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Robert Raszuk <>
Date: Tue, 1 Nov 2016 16:14:30 +0100
X-Google-Sender-Auth: 7X5iVcULE3FK-fI9yPNrpPx77Kc
Message-ID: <>
To: Job Snijders <>
Content-Type: multipart/alternative; boundary=001a1148ebca01445105403ec8e3
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:14:39 -0000

> even if the implementation is compatible with said specification

Well I think this is completely different problem regardless on how the
types/codepoints will be allocated.

> 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

That was not what I have tried to express ... I suggested to assign all
detected points to the drafts they belong as early allocation rather then
to deprecate them. Result is the same - geo will not be allocated code
point which is already used.

So is 32 final code point for Large or early allocated one. If what LC got
is final one why geo would need to ask for early allocation vs final one :)


On Tue, Nov 1, 2016 at 4:01 PM, Job Snijders <> wrote:

> 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,
> Job