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

From: RFC Errata System <[email-masked]>
Date: Wed, 4 Feb 2015 01:24:19 -0800 (PST)

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 <[email-masked]>

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

---

From: Brian Haberman <[email-masked]>
Date: Fri, 06 Feb 2015 08:25:15 -0500

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 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:
> -------------

---

From: "Isidoros Kouvelas (kouvelas)" <[email-masked]>
Date: Fri, 6 Feb 2015 14:51:15 +0000

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

---

From: Brian Haberman <[email-masked]>
Date: Fri, 06 Feb 2015 10:06:38 -0500

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
> 
>> 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
>> 
>>> -------------------------------------- You may review the report
>>> below and at: 
>>> -------------------------------------- Type: Technical Reported
>>> by: Isidor Kouvelas <[email-masked]>
>>> 
>>> 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) -------------------------------------- 
>>> 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
>

---

From: "Isidoros Kouvelas (kouvelas)" <[email-masked]>
Date: Fri, 6 Feb 2015 15:19:03 +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

---

From: Brian Haberman <[email-masked]>
Date: Fri, 06 Feb 2015 10:44:02 -0500

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

---

From: "Isidoros Kouvelas (kouvelas)" <[email-masked]>
Date: Fri, 6 Feb 2015 15:48:33 +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

---

From: "Gregg Schudel (gschudel)" <[email-masked]>
Date: Fri, 6 Feb 2015 17:58:10 +0000

> I can't find any reference to discussions on the lower limit.  Authors?

going back to check Brian - it was a while ago.

thanks!

Best regards,
Gregg

--------------------------------------------------------------------
.:|:.:|:. | gregg schudel (ccie#9591) LISP technical marketing engr
  cisco   | mobile: +1 571 332 2222   email: [email-masked]
--------------------------------------------------------------------
cisco corporate legal statement: 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------------------------------------------------------------