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

"Isidoros Kouvelas (kouvelas)" <kouvelas@cisco.com> Fri, 06 February 2015 15:19 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 EF9B21A1B34 for <lisp@ietfa.amsl.com>; Fri, 6 Feb 2015 07:19:14 -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 DMwvtA9uNDCM for <lisp@ietfa.amsl.com>; Fri, 6 Feb 2015 07:19:05 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E1271A1B2C for <lisp@ietf.org>; Fri, 6 Feb 2015 07:19:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7908; q=dns/txt; s=iport; t=1423235945; x=1424445545; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IYok3cE5vgP7BUiCP4xlGblOioyYNApa3jVNXx47UF8=; b=cf2OUyyKM/OxbSpeblCQHpSYT5iemYtN3k6TvadrKY4vk7bAY4+JAFPY 7AdM8JIFfsQ1mcXi1t4HWxxrZBNQrjYgxK2uTLs2/UhpJKGM9FNnVjlxn OQHV5DDObu4VTBpPTJsGPkGbnX/yPag8QPVordiXlabknx+FbQFX6wrnr Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A8BgCA2tRU/4sNJK1AGoMGUloEgn29OYImhXECHH1DAQEBAQF9hAwBAQEDASMRRQULAgEGAhgCAiYCAgIwFRACBA4FiCUIDTeiLJxslXwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGLJ4JZPBsHgmgugRMFhVKJSIksgReDA45SIoICDQ+BUG8BEXFBfgEBAQ
X-IronPort-AV: E=Sophos;i="5.09,529,1418083200"; d="scan'208";a="121171287"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP; 06 Feb 2015 15:19:04 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t16FJ4Oi010427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Feb 2015 15:19:04 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.12]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Fri, 6 Feb 2015 09:19:04 -0600
From: "Isidoros Kouvelas (kouvelas)" <kouvelas@cisco.com>
To: Brian Haberman <brian@innovationslab.net>
Thread-Topic: [Technical Errata Reported] RFC7052 (4256)
Thread-Index: AQHQQFxlnTg8pe7qO0ib4DaVqyuxIpzkBIuAgAAYCoCAAARKAIAAA3qA
Date: Fri, 06 Feb 2015 15:19:03 +0000
Message-ID: <F412925B-8EA0-414E-AC9B-263F51715059@cisco.com>
References: <20150204092419.B7DE3180092@rfc-editor.org> <54D4C0BB.3030906@innovationslab.net> <EDF4C663-E6D0-4D93-8117-203538C20C83@cisco.com> <54D4D87E.7060807@innovationslab.net>
In-Reply-To: <54D4D87E.7060807@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="utf-8"
Content-ID: <AB429E692CDEA94784B842DBFFECCBBE@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/seRvBzmO9iIWJaMGo3zLpdLlOOs>
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:19:15 -0000

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.

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.

regards
Isidor

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

> Hi Isidor,
>     I agree that the length fields are redundant, but vaguely remember
> during the MIB development someone indicating why they thought they were
> useful.  The description of lispEidRegistrationLastRegisterSender
> doesn't indicate a scenario where it could be unspecified.  If it is
> configured on the Map Server, would it make sense to use an address from
> the Map Server for the sender? Another option would be to encode a
> special IP address (255.255.255.255 or 0.0.0.0) as the unspecified address.
> 
>     I am concerned that the level of churn in the MIB of changing 13
> length constraints may be high and the length field was a discussion
> during the consensus call on the document.  Do others have an opinion?
> 
> Regards,
> Brian
> 
> On 2/6/15 9:51 AM, Isidoros Kouvelas (kouvelas) wrote:
>> Brian,
>> 
>> Yes you are right, the length fields that are paired with each use of
>> LispAddressType also have to have their minimum value adjusted. BTW
>> these length fields are redundant as the octet string encoding
>> contains the length so the value ends up being repeated in the OID.
>> You are also right that in all cases where the LispAddressType is
>> used as part of a key in a table, the address has to be specified and
>> therefore the enforced minimum length is not an issue. The only case
>> I believe where the type is used for an attribute is
>> lispEidRegistrationLastRegisterSender. A lispEidRegistrationEntry may
>> be configured on the Map-Server but not registered by an xTR in which
>> case the lispEidRegistrationLastRegisterSender will be unspecified.
>> 
>> regards Isidor
>> 
>> On Feb 6, 2015, at 15:25, Brian Haberman <brian@innovationslab.net>
>> wrote:
>> 
>>> Hi Isidor, I think we need to discuss this to really see if this is
>>> a problem. Can you give an example where the minimum length doesn't
>>> work?  I looked through all instances of LispAddressType and would
>>> expect NULL entries to still have some info needed in the
>>> LispAddressType variable. Additionally, it appears that all
>>> instances of a mib variable of type LispAddressType has an
>>> associated length field that is also constrained to values (5..39).
>>> If the LispAddressType TC needed to be changed to (0..39), wouldn't
>>> all those length fields need to change as well?
>>> 
>>> Regards, Brian
>>> 
>>> On 2/4/15 4:24 AM, RFC Errata System wrote:
>>>> The following errata report has been submitted for RFC7052, 
>>>> "Locator/ID Separation Protocol (LISP) MIB".
>>>> 
>>>> -------------------------------------- You may review the report
>>>> below and at: 
>>>> http://www.rfc-editor.org/errata_search.php?rfc=7052&eid=4256
>>>> 
>>>> -------------------------------------- Type: Technical Reported
>>>> by: Isidor Kouvelas <kouvelas@cisco.com>
>>>> 
>>>> Section: 7
>>>> 
>>>> Original Text ------------- REFERENCE "RFC 6830, Section 14.2
>>>> and LISP Canonical Address Format (LCAF), Work in Progress, March
>>>> 2013." SYNTAX OCTET STRING (SIZE (5..39))
>>>> 
>>>> 
>>>> Corrected Text -------------- REFERENCE "RFC 6830, Section 14.2
>>>> and LISP Canonical Address Format (LCAF), Work in Progress, March
>>>> 2013." SYNTAX OCTET STRING (SIZE (0..39))
>>>> 
>>>> 
>>>> Notes ----- The minimum octet string length of 5 specified for
>>>> the LispAddressType is incorrect. The smallest non-empty address
>>>> is an IPv4 address that is not using the LCAF format to include
>>>> an instance ID. This requires 8 octets (see example 1 above
>>>> keeping in mind that the AFI requires 2 octets). However, in many
>>>> places in the MIB definition the LispAddressType is used as the
>>>> type for attributes where “unspecified” is a valid return.
>>>> For example in lispEidRegistrationLastRegisterSender, an EID
>>>> prefix that is configured on a Map-Server may not have any active
>>>> registrations. To encode the absence of an address the minimum
>>>> length of zero should be allowed.
>>>> 
>>>> Instructions: ------------- This erratum is currently posted as
>>>> "Reported". If necessary, please use "Reply All" to discuss
>>>> whether it should be verified or rejected. When a decision is
>>>> reached, the verifying party (IESG) can log in to change the
>>>> status and edit the report, if necessary.
>>>> 
>>>> -------------------------------------- RFC7052
>>>> (draft-ietf-lisp-mib-13) -------------------------------------- 
>>>> Title               : Locator/ID Separation Protocol (LISP) MIB 
>>>> Publication Date    : October 2013 Author(s)           : G.
>>>> Schudel, A. Jain, V. Moreno Category            : EXPERIMENTAL 
>>>> Source              : Locator/ID Separation Protocol Area
>>>> : Internet Stream              : IETF Verifying Party     : IESG
>> 
>