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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A2061297C1 for <>; Tue, 1 Nov 2016 07:41:17 -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 rwwTXOKkDvm2 for <>; Tue, 1 Nov 2016 07:41:16 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA959129705 for <>; Tue, 1 Nov 2016 07:41:15 -0700 (PDT)
Received: by with SMTP id n67so290084060wme.1 for <>; Tue, 01 Nov 2016 07:41:15 -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=hwebqIpT0aL2hm8o9uPnOBzNkeW/PMi6x/Ka60uCrSY=; b=gRTzwC+yOauxoYo8Fwim3QLas9Ek2+xT3g/yW7LQLrEwS+EOsrfDD0GXrRLZG2Vz79 qu6MM67hQVlAX3WrrWUrFN49PFtBvSGIahednaSlghcVXjzhoo2D+2eStzWJsJ7mk5Tm RM+Wz64zY59Io+vBYH+cl2aGfI/P/RamGAAkvPFzukloGzEeAqy3eU+oPv63EKJ7dezc Wl14W6Bpy7zVM05WdKrUHnj4tiJps+fcET7oiipmr5GXK4KiTOiJzfhsKhAf86lnz2xn SgR2P61ImLMYhxEZJJ9rbfnke+FqsfI7r/8mOhTe3qTxihdFLGWK9kPzPyAzOltXREDm sF3w==
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=hwebqIpT0aL2hm8o9uPnOBzNkeW/PMi6x/Ka60uCrSY=; b=my1LFhh2CbK9EOwOsdL6iszZ5bE5YKbl+/Z6xeg5IXBVlWEnSWLmCZArifZH11ZmYz ddpG/M8GG3PpU2n0ALIpMvu8OtScZ5w8ta8bKhCaKTM4x333YGjWvvLa56XIH+g/sPaz p/AXtGflyNjQykI00mbVOuvg42I25ERhNYI/MEYBExaqVrEWNMb5kbOrbkWXl+rbA2ey qcVS+dfKlbKR5LeLg7WUnYwHBdgSGtSicijSVQvzuZYRmJi2pix7wFxfUKGJraP2j5+P X6hWL+ABzsDmmxn2HiH/efiU1MAeLCSlzA087LkBIUWirTga8/VmCmn2f9wp9cJRcYYb DKWg==
X-Gm-Message-State: ABUngvcJmklF4+YagGT2wyOp0LPpL01QpkdSpHFczDrUL32jnSpAEjVhpU1ujEVhbLnUnXQM5HDkeUR/4lNjkw==
X-Received: by with SMTP id ex11mr25464883wjd.99.1478011274349; Tue, 01 Nov 2016 07:41:14 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 1 Nov 2016 07:41:12 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Robert Raszuk <>
Date: Tue, 1 Nov 2016 15:41:12 +0100
X-Google-Sender-Auth: QYVYvQBwBvj1FVjCogZUMJDF0OQ
Message-ID: <>
To: Job Snijders <>
Content-Type: multipart/alternative; boundary=047d7bfcedbefb53d605403e5024
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 14:41:17 -0000

> 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 ? ​

> 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.

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.

Kind regards,