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



Search RFCs
Advanced Search
×