IETF Logo Mail Archive

Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT)

"Alvaro Retana (aretana)" <aretana@cisco.com> Wed, 01 February 2017 09:47 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD65129A1C; Wed, 1 Feb 2017 01:47:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.719
X-Spam-Level:
X-Spam-Status: No, score=-17.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 oYO9Vep4V-yc; Wed, 1 Feb 2017 01:47:12 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C7212896F; Wed, 1 Feb 2017 01:47:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12204; q=dns/txt; s=iport; t=1485942431; x=1487152031; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1J3SsXJsbnVzKAQ0/ejtDTpg8MCAC7XAdzdShIYqZwo=; b=RvHHYbtyXouJuSScHum0JQToj5hqSnwefvxJuQ4z8Y+k1fiqZUxb668t kDt36x+b8inx4DXuAFLxVY891/qtgtCZFy1y6P8OxKsZOVqljaAictVbd aR0FxRNMbeGoAI0fiY2WSITVKMZUj8qj4789RAx2LbnBxf6ga6I+THklF 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CyAQCCrZFY/4wNJK1dGQEBAQEBAQEBAQEBBwEBAQEBgm9kYYEJB4NQigmRaJApgxyCD4INhiICGoIqPxgBAgEBAQEBAQFiKIRqBiNIDhACAQgkGwMCAgIwFBECBAENBYlyrEWCJSuLCAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GS4IFCIJih1MugjEFlUWGFgGSApB7kwABHziBSxVMAYQxHBmBSHWHEYEMAQEB
X-IronPort-AV: E=Sophos;i="5.33,319,1477958400"; d="scan'208,217";a="378404334"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Feb 2017 09:47:10 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v119kV9f014846 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Feb 2017 09:47:10 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 1 Feb 2017 03:47:05 -0600
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 1 Feb 2017 03:47:05 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, The IESG <iesg@ietf.org>
Thread-Topic: Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT)
Thread-Index: AQHSe0JHF3IUDVpxIkSQ7eReJZcjSqFRfwYAgACmHiCAAJG4AIAAWw+AgADonQA=
Date: Wed, 01 Feb 2017 09:47:05 +0000
Message-ID: <48328C3E-80F9-4374-9B18-F6009D3F56AB@cisco.com>
References: <148581276904.29896.13476859309389809794.idtracker@ietfa.amsl.com> <d2faebdd-4d79-9be3-be9d-6647f92e57f1@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933009DEB012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <497B4C1B-CAB6-469B-8467-F7A7A08847FF@cisco.com> <787AE7BB302AE849A7480A190F8B933009DEB2F4@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DEB2F4@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1e.0.170107
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.3]
Content-Type: multipart/alternative; boundary="_000_48328C3E80F943749B18F6009D3F56ABciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/uIu2XwDk7y32oFaRsp4WQQUfpxk>
Cc: "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>, "draft-ietf-lisp-type-iana@ietf.org" <draft-ietf-lisp-type-iana@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>
Subject: Re: [lisp] Alvaro Retana's Discuss on draft-ietf-lisp-type-iana-04: (with DISCUSS and COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Feb 2017 09:47:18 -0000

Thanks Med!

Alvaro.

On 1/31/17, 9:54 AM, "mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:


About the text you proposed below…  The LISP Packet Type Registry (4.1, not 5.1) has only 15 possible values, 7 of which are assigned/reserved by this document, rfc6833bis assigns 3 more values, and this document mentions 5 potential extensions (“new message types are proposed in [I-D.ietf-lisp-ddt], [I-D.zhao-lisp-mn-extension], [I-D.boucadair-lisp-bulk], [I-D.ermagan-lisp-nat-traversal], or [I-D.boucadair-lisp-subscribe]” [*])…bringing the total up to 15.  Even if not all these new drafts make it, the LISP Packet Type Registry will soon have no more values to assign.  The result will be that the Sub-Types (in the LISP Shared Extension Message Type) will be used for production [1].

[Med] Agree.

IOW, I don’t think you need a transition mechanism.  Instead, I think you need to recognize that the Sub-Types will be used for production deployments.  Suggestion:  consider changing the registration policy from FCFS to something where part of the space requires Standards Action, or maybe RFC Required or even Expert Review.  The result of FCFS is that anyone can request a value and get it: “There is no substantive review of the request, other than to ensure that it is well-formed and doesn't duplicate an existing assignment.” [rfc5226]

[Med] The motivation for using FCFS is to avoid imposing heavy constraints on designers to register their extensions. Also, given that we have 4096 sub-type values, the full range cannot be consumed completely even with a FCFS policy. That’s said, I agree with you it might be more safe to secure a range for assignments via Standards Action (e.g., 0-1023) and leave the 1024-4095 for FCFS. I can make such change.

v2.23.0 | Report a Bug | By Email