Re: [Idr] Early allocations and other ways to avoid squatting on code points

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Tue, 01 November 2016 16:44 UTC

Return-Path: <jheitz@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78431294BC for <idr@ietfa.amsl.com>; Tue, 1 Nov 2016 09:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Level:
X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VlZqyTIScRJ for <idr@ietfa.amsl.com>; Tue, 1 Nov 2016 09:44:26 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FCF1294A3 for <idr@ietf.org>; Tue, 1 Nov 2016 09:44:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3330; q=dns/txt; s=iport; t=1478018665; x=1479228265; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PCbPbGY8nElqLoAKTC5pwDvHcmbXCZDEHhR3SrLaJZo=; b=cA/gMAqiTxxsW41ZFa3pD/DEScxHS/OfLMLJBAj4hPlv9ykmMoOfw559 0u5IbGx9ND1ZEp9JBKHwhhk0DQc/dka0ZdXt2TthA+QtEu7PqZIgjkj0L lIRNeCTF9LWL3NUbibhL+MfZvLX2Am54maoNweEdZGoSZKgYguiJ9k+QH Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DBAQAgxhhY/5pdJa1dGQEBAQEBAQEBAQEBBwEBAQEBgyoBAQEBAR9YfAcBjS6XAZRFggcdC4V6AhqBdj8UAQIBAQEBAQEBYiiEYQEBAQQBAQEgEToLDAQCAQgRBAEBAQICIwMCAgIlCxQBCAgCBAENBQgTiDkOqiyMeAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFgQeFNoRVhBkRAYMgglwFmhoBhjCJfYF1iCiFcI0ThAMBHjZghRNyhTCBIAGBCwEBAQ
X-IronPort-AV: E=Sophos;i="5.31,580,1473120000"; d="scan'208";a="341027724"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2016 16:44:25 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uA1GiP19000698 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Nov 2016 16:44:25 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 1 Nov 2016 11:44:24 -0500
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Tue, 1 Nov 2016 11:44:24 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: "John G. Scudder" <jgs@juniper.net>, Robert Raszuk <robert@raszuk.net>
Thread-Topic: [Idr] Early allocations and other ways to avoid squatting on code points
Thread-Index: AQHSNFFYQbYshjrfZESTJ2mO+uOKraDEVFbA
Date: Tue, 01 Nov 2016 16:44:24 +0000
Message-ID: <c10ad1e738a442eba50440803befbc8c@XCH-ALN-014.cisco.com>
References: <169A4C1A-302E-4FE0-841A-ADA63E812E1F@juniper.net> <20161101133240.GK1581@hanna.meerval.net> <CA+b+ERnh8MMDgCoviLDRvOxbOky=8pBtHC8Z-WCQr6xFF_ZzGQ@mail.gmail.com> <20161101141229.GK1589@hanna.meerval.net> <CA+b+ERmfW0vVXgqrxqNajZhJS3aDXD6kG7xzMFjsuk4bBNLvnQ@mail.gmail.com> <20161101142807.GL1589@hanna.meerval.net> <CA+b+ERkKicRi2qAcm=t3LHyVcqe5J1=Ba=QLsFuCGUv+oMRwFg@mail.gmail.com> <89B7215E-505D-4EEF-94E6-DB9B7CC23A8D@juniper.net>
In-Reply-To: <89B7215E-505D-4EEF-94E6-DB9B7CC23A8D@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.107.151.35]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ld6NNmoJVerpUzFWBq13iYmdcFU>
Cc: IETF IDR Working Group <idr@ietf.org>
Subject: Re: [Idr] Early allocations and other ways to avoid squatting on code points
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Nov 2016 16:44:28 -0000

I support an early attribute code allocation for wide communities.
I'm happy for it to have 129 if that's what it's been using.
Of course, it's not my call to make, just my opinion.

Thanks,
Jakob.


> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder
> Sent: Tuesday, November 01, 2016 8:05 AM
> To: Robert Raszuk <robert@raszuk.net>
> Cc: IETF IDR Working Group <idr@ietf.org>
> Subject: [Idr] Early allocations and other ways to avoid squatting on code points
> 
> I have changed the subject line to reflect the fact we are off on a tangent and no longer relevant to adoption of
> the draft in question.
> 
> On Nov 1, 2016, at 10:41 AM, Robert Raszuk <robert@raszuk.net> wrote:
> > ​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.
> 
> I'm not sure what you mean by "it is again bad" but see the message I just sent -- we were not asked for an
> allocation for the code base in question (not sure what other code bases you are including in "few", I think one was
> reported).
> 
> When the question of early allocation for wide came up recently (I don't recall if it was on the list, in private
> email, in conversation or what, sorry) my feedback was to ask whether wide satisfies the stability requirement given
> in RFC 7120 Section 2 (c). Certainly if there is need for an allocation for wide and it can satisfy the RFC 7120
> requirements, let's do it. If it can't satisfy the requirements, read on:
> 
> > 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.
> 
> I expect we will be discussing this at our upcoming meeting, although that's no reason not to continue the
> conversation on the list right now, on the contrary. Jeff has also written a draft that tries to address the problem,
> he posted a pointer to it yesterday, https://datatracker.ietf.org/doc/draft-haas-idr-extended-experimental/
> 
> Thanks,
> 
> --John
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr