RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (3)

RFC 7052, "Locator/ID Separation Protocol (LISP) MIB", October 2013

Source of RFC: lisp (int)

Errata ID: 4256

Status: Verified
Type: Technical

Reported By: Isidor Kouvelas
Date Reported: 2015-02-04
Verifier Name: Brian Haberman
Date Verified: 2015-09-14

Section 7 says:

    REFERENCE
        "RFC 6830, Section 14.2 and
         LISP Canonical Address Format (LCAF), Work in Progress,
         March 2013."
    SYNTAX OCTET STRING (SIZE (5..39))

It should say:

    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.

Errata ID: 4235

Status: Verified
Type: Technical

Reported By: Isidor Kouvelas
Date Reported: 2015-01-17
Verifier Name: Brian Haberman
Date Verified: 2015-02-03

Section 7 says:

       Example 3: As an example where LCAF is used, suppose
       that the IPv4 EID-Prefix stored is 192.0.2.0/24 and it
       is part of LISP Instance ID 101.  In this case, the values
       within lispMapCacheEntry would be:

          lispMapCacheEidLength  = 11
          lispMapCacheEid = 16387, 7, 2, 101, 1, 192.0.2.0, 24
          ... [skip] ...

       where 11 is the total length in octets of the next object
       (lispMapCacheEID of type LispAddressType).  Then, the value
       16387 indicates the LCAF AF (see the
       IANA-ADDRESS-FAMILY-NUMBERS-MIB), the value 7 indicates that
       the LCAF AF is 7 octets in length in this case, 2 indicates
       that LCAF Type 2 encoding is used (see the LCAF document), 101
       gives the Instance ID, 1 gives the AFI (per the
       IANA-ADDRESS-FAMILY-NUMBERS-MIB) for an IPv4 address, 192.0.2.0
       is the IPv4 address, and 24 is the mask-length in bits.  Note
       that the lispMapCacheEidLength value of 11 octets is used to
       compute the length of the last field in lispMapCacheEid to be 1
       octet -- as computed by 11 - (2 + 1 + 1 + 1 + 1 + 4) = 1.

It should say:

       Example 3: As an example where LCAF is used, suppose
       that the IPv4 EID-Prefix stored is 192.0.2.0/24 and it
       is part of LISP Instance ID 101.  In this case, the values
       within lispMapCacheEntry would be:

          lispMapCacheEidLength  = 14
          lispMapCacheEid = 16387, 10, 2, 101, 1, 192.0.2.0, 24
          ... [skip] ...

       where 14 is the total length in octets of the next object
       (lispMapCacheEID of type LispAddressType).  Then, the value
       16387 indicates the LCAF AF (see the
       IANA-ADDRESS-FAMILY-NUMBERS-MIB), the value 10 indicates that
       the LCAF AF is 10 octets in length in this case, 2 indicates
       that LCAF Type 2 encoding is used (see the LCAF document), 101
       gives the Instance ID, 1 gives the AFI (per the
       IANA-ADDRESS-FAMILY-NUMBERS-MIB) for an IPv4 address, 192.0.2.0
       is the IPv4 address, and 24 is the mask-length in bits.  Note
       that the lispMapCacheEidLength value of 14 octets is used to
       compute the length of the last field in lispMapCacheEid to be 1
       octet -- as computed by 14 - (2 + 1 + 1 + 3 + 2 + 4) = 1.

Notes:

The Instance ID within the type 2 LCAF is 24 bits and requires 3 octets (incorrectly calculated as 1)
The AFI within the LCAF type 2 requires 2 octets (incorrectly calculated as 1)

Errata ID: 4304

Status: Verified
Type: Technical

Reported By: Isidor Kouvelas
Date Reported: 2015-03-17
Verifier Name: Brian Haberman
Date Verified: 2015-09-14

Section 7 says:

   lispEidRegistrationLastRegisterSenderLength OBJECT-TYPE
       SYNTAX     Integer32 (5..39)
       MAX-ACCESS read-only

It should say:

   lispEidRegistrationLastRegisterSenderLength OBJECT-TYPE
       SYNTAX     Integer32 (0..39)
       MAX-ACCESS read-only

Notes:

The lispEidRegistrationLastRegisterSender is the only use of the LispAddressType in a readable attribute. In order to be able to encode an unspecified address, the minimum length must be lowered to zero. For more information see errata 4256.

Report New Errata