Re: [lisp] [Technical Errata Reported] RFC7052 (4256)

"Isidoros Kouvelas (kouvelas)" <kouvelas@cisco.com> Fri, 06 February 2015 15:48 UTC

Return-Path: <kouvelas@cisco.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAC61A1BDA for <lisp@ietfa.amsl.com>; Fri, 6 Feb 2015 07:48:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 P-MVciVuMyVp for <lisp@ietfa.amsl.com>; Fri, 6 Feb 2015 07:48:35 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81321A1BAF for <lisp@ietf.org>; Fri, 6 Feb 2015 07:48:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1814; q=dns/txt; s=iport; t=1423237714; x=1424447314; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ps1oECA7l2eu7k4GHrQSPo08EcdjT7CcveslrMS2xLk=; b=aFzLEo0mPtrAkvvhY12tChGZLsXUDO9Nk+DuAiJQXShED22H2gQZtDLF i4OiN+7lM0CiIlVpNz/IRqQE68D/SXIPhuAY5VRO5+H3H5BggGzBa7Y6C sUYP/lyLLqs4H97PdS0+5NtICwOj9cFz800Hko6etpGOsMS82kbRG2lo3 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A1BgAs4dRU/4MNJK1agwaBLATANogXAoEZQwEBAQEBfYQMAQEBAwE6PwULAgEIGB4QMiUCBA4FiCUI1W4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXjEiCWSQzB4MWgRMBBI8aiSyBF44Xgz4iggIND4FQb4EDQX4BAQE
X-IronPort-AV: E=Sophos;i="5.09,529,1418083200"; d="scan'208";a="121161329"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 06 Feb 2015 15:48:34 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t16FmXUK021504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Feb 2015 15:48:34 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.12]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Fri, 6 Feb 2015 09:48:33 -0600
From: "Isidoros Kouvelas (kouvelas)" <kouvelas@cisco.com>
To: Brian Haberman <brian@innovationslab.net>
Thread-Topic: [Technical Errata Reported] RFC7052 (4256)
Thread-Index: AQHQQFxlnTg8pe7qO0ib4DaVqyuxIpzkBIuAgAAYCoCAAARKAIAAA3qAgAAG+QCAAAFFgA==
Date: Fri, 06 Feb 2015 15:48:33 +0000
Message-ID: <91124685-79A3-4781-A87A-65029EE70219@cisco.com>
References: <20150204092419.B7DE3180092@rfc-editor.org> <54D4C0BB.3030906@innovationslab.net> <EDF4C663-E6D0-4D93-8117-203538C20C83@cisco.com> <54D4D87E.7060807@innovationslab.net> <F412925B-8EA0-414E-AC9B-263F51715059@cisco.com> <54D4E142.6020409@innovationslab.net>
In-Reply-To: <54D4E142.6020409@innovationslab.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.198.67]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0CD3CB62D80CB546AA45FE201356F753@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/y99S-YYCyC2ZwUzrEMyu0InpFpk>
Cc: "lisp@ietf.org" <lisp@ietf.org>, "ted.lemon@nominum.com" <ted.lemon@nominum.com>
Subject: Re: [lisp] [Technical Errata Reported] RFC7052 (4256)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Fri, 06 Feb 2015 15:48:36 -0000

Brian,

I would rather see all the uses of LispAddressType have the lower limit of the associated length fields changed to zero but given your concern on the number of changes to the document I think just changing lispEidRegistrationLastRegisterSenderLength would satisfy the current requirement.

thanks
Isidor

On Feb 6, 2015, at 17:44, Brian Haberman <brian@innovationslab.net> wrote:

> Isidor,
> 
> On 2/6/15 10:19 AM, Isidoros Kouvelas (kouvelas) wrote:
>> Brian,
>> 
>> I am not sure what the minimum length of 5 could correspond to given
>> the minimum length of an IPv4 address will be 8 octets (including two
>> for AFI, one for the internal length field and one for the mask
>> length). So I would be interested in the discussion context you refer
>> to.
> 
> It turns out that the discussion during review was with the upper limit.
> I can't find any reference to discussions on the lower limit.  Authors?
> 
>> 
>> Regarding the unspecified address specification I think that making
>> it explicit (zero length) would be cleaner than encoding a special
>> address. To limit the number of changes to the MIB we could only fix
>> the LispAddressType octet string definition as well as
>> lispEidRegistrationLastRegisterSenderLength.
>> 
>> Regarding the example below, the normal case is that all EID prefixes
>> are configured on the Map-Server and then registered by the xTRs.
>> Reporting the MS as the RegisterSender of the EID prefixes that have
>> not been registered would not work.
> 
> So, is your suggestion to change the lower limit on the TC and the lower
> limit for just the lispEidRegistrationLastRegisterSenderLength?
> 
> I would still like some input from others in the WG on this issue.
> 
> Regards,
> Brian
>