Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt

Enke Chen <enkechen@cisco.com> Thu, 23 March 2017 19:01 UTC

Return-Path: <enkechen@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 28D6B129890 for <idr@ietfa.amsl.com>; Thu, 23 Mar 2017 12:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qxOCY58qohDw for <idr@ietfa.amsl.com>; Thu, 23 Mar 2017 12:01:29 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ECA513162C for <idr@ietf.org>; Thu, 23 Mar 2017 12:01:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=553; q=dns/txt; s=iport; t=1490295674; x=1491505274; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=b5wXY5gi6iQLH2RaJAyxc5QaqmNBQBYiX9e1RDMmwko=; b=ItcnuEoaXkC+MreDAHsGnVctE9IbBiVf1w36FqLBZ6+Osnmir9zjvolL bnOi1Zwb8dZwqCmY8c1ADJlPIp1JoZ0M1WZWGggRlZG0dzKOCIqAEyH5Q ihIEsbxeoPNq0exUeZJAywKUCU2oeHn5yH1vgADfBm5YDddRrgWx/fPKD Y=;
X-IronPort-AV: E=Sophos;i="5.36,211,1486425600"; d="scan'208";a="402107558"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2017 19:01:13 +0000
Received: from [10.41.57.0] ([10.41.57.0]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2NJ1Cp9026843; Thu, 23 Mar 2017 19:01:12 GMT
To: Eric C Rosen <erosen@juniper.net>
References: <048701d29cd9$15204b80$3f60e280$@olddog.co.uk> <022201d29ce6$ffb2ba40$ff182ec0$@ndzh.com> <c369a60a-3ccc-bf7d-dd29-d289d7a6b67e@juniper.net> <02dc01d2a25b$a1eca590$e5c5f0b0$@ndzh.com> <3b9c229a-4573-c586-8627-3a8c38539ff8@juniper.net> <E40AC551-E802-4662-A2F5-2E8EDB3C746F@juniper.net> <c8804d0b-39e0-bb56-464c-fe1d051f2d91@juniper.net>
Cc: "John G. Scudder" <jgs@juniper.net>, Susan Hares <shares@ndzh.com>, idr@ietf.org, Enke Chen <enkechen@cisco.com>
From: Enke Chen <enkechen@cisco.com>
Message-ID: <0271cbf9-b892-463e-34b4-f3af7bea5bdf@cisco.com>
Date: Thu, 23 Mar 2017 12:01:11 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <c8804d0b-39e0-bb56-464c-fe1d051f2d91@juniper.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/4aqZRfpBWR_gYAcG85vwuU6alB4>
Subject: Re: [Idr] Thoughts on https://www.ietf.org/id/draft-hares-idr-bgp-registries-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 23 Mar 2017 19:01:31 -0000

Eric,

On 3/23/17 10:29 AM, Eric C Rosen wrote:
[snip]

> Ultimately all type fields will be two-octets long with FCFS registration; that's the
> ultimate solution to this particular red tape problem.

Not only the type fields, but also the length fields in TLVs.

Given the processing power and memory, there is hardly any reason for having
one-byte type or length fields in TLV definitions.  We have been burned too
many times.

This is something that should be high on the list of fixes if there is ever a
BGP-5.

Thanks.  -- Enke