Subject: [MIB-DOCTORS] draft-ietf-lisp-mib MIB doctor review

From: Benoit Claise <[email-masked]>
Date: Thu, 21 Feb 2013 14:59:38 +0100

Dear draft-ietf-lisp-mib authors,

Here is the MIB doctor review, done by Harrie Hazewinkel

Regards, Benoit

-------- Original Message --------

Hereby my review of the LISP MIB. I could not find a full list to whom 
this all should have been addressed.
I hope you could forward it. In general I beleive the MIB is quit OK, 
but I have two concerns:

1)  a combination of a length value and a ListAddressType is there and 
they are also used as part of an INDEX.
2) The MIB is completely read-only while I believe this would not be 
neccessary and at various places a read-write
would be appropriate. Then with conformance statements a read-only 
version should be made.

Below are the more detailed concerns I found by section (the 'indented 
text is quoted from the draft).

    2 <http://tools.ietf.org/html/draft-ietf-lisp-mib-08#section-2>.
    Introduction

> Finally, while not specifically required, this document assumes the 
> existence of a database to store and propagate those mappings globally.

If it assumes the existance of a database, what does this MIB module do 
with that?

    4 <http://tools.ietf.org/html/draft-ietf-lisp-mib-08#section-4>.
    Definition of Terms

Are these not in other documents of LISP described? I wonder if it would
not be better just to reference those.

    5 <http://tools.ietf.org/html/draft-ietf-lisp-mib-08#section-5>.
    LISP MIB Objectives

>     The objectives for defining this LISP MIB module are as follows:
>
>     o  Provide a means for obtaining a list of enabled LISP features and
>        the current status of configuration attributes related to those
>        features.
I noticed that here the word 'enabled' is used. Does that mean ONLY 
those features
that currently work on the managed device, could be used on the managed 
device,
or a list of all features avaialble in LISP? Even more if I read section 
6.2 the first
described table. See below where 'representing the various features' is 
used.

            6.2
            <http://tools.ietf.org/html/draft-ietf-lisp-mib-08.html#section-6.2>.
            Overview of Defined Tables

>     lispMapCache -  This table represents the short-lived, on-demand
>        table on an ITR that stores, tracks, and is responsible for
>        timing-out and otherwise validating EID-to-RLOC mappings.
I do not understand the last sentence, but wonder if that is because 
'otherwise'
makes no sense.

    7
    <http://tools.ietf.org/html/draft-ietf-lisp-mib-08.html#section-7>.
    LISP MIB Definitions

TODO: use libsmi for machine-readable testing/verification.

> lispMIB MODULE-IDENTITY
> [snip]
>     DESCRIPTION
>              "Locator/ID Separation Protocol (LISP) MIB Textual
>               Conventions module. The LISP MIB is intended for
>               management of LISP routers.
I would argue that this is not a Textual Conventions Module and would 
suggest to use
'Managed Object module'.

> LispAddressType ::= TEXTUAL-CONVENTION
I understand the definition of the four-tuple, but do wonder is one 
should merge the
values as such. Why not using three different managed objects?

Then for the illustration of the use of such an object I do not see the 
link with the
lispMapCacheEidLength and the lispMapCacheEid.Also because you already have
defined a length 'part' in the four-tuple.

>               lispMapCacheEidLength  = 8
>               lispMapCacheEid = 1, 4, 192.0.2.0, 24
>               ... [skip] ...
>            Note that the lispMapCacheEidLength
>            value of 8 is used to compute the length of the fourth
>            (last) field in lispMapCacheEid to be 1 octet - as
>            computed by 8 - (2 + 1 + 4) = 1.
Why is the length 8? I would say 7.

Beyond that I believe it is a bad idea to have a lispAddressType that 
combines already
some data, but still must use an extra object for some length of a part 
of the
listpAddressType.

> lispFeaturesTable OBJECT-TYPE

I wonder if there will be never new features defined for LISP and how 
one foresees
this new feeature to include in this table?

Is it also the idea that this MIB is ONLY for information retrieval? I 
could imagine that
one would like to turn features on and off or change the map cache size.
In the last case, the MAX-ACCESS should be read-write and one should create
compliance statements where a read-only version is defined.

> lispFeaturesInstanceID OBJECT-TYPE

The desciption deinfes a default. This should be in the DEFVAL clause.

DEFVAL { 0 }

>     lispMappingDatabaseTable OBJECT-TYPE

Why is this a value between 5 and 259? The type for which this object 
provides
the length can only be between 5 and 39.

The value of 529 has also an impact of the index as an index and prefix 
of the
OID -sequence van only be 256 of length.

> lispMappingDatabaseTimeStamp OBJECT-TYPE

I would suggect a DEFVAL { 0 } to capture the situation in which is 
described that the
information was present during the re-initialization of the local 
management subsystem.
(This occurs more often in the MIB module)

> lispMapCacheTable OBJECT-TYPE

> lispConfiguredLocatorTable OBJECT-TYPE
> lispEidRegistrationTable OBJECT-TYPE
> lispUseMapResolverTable OBJECT-TYPE
> lispUseProxyEtrTable OBJECT-TYPE

I believe the index clause has the same 'length' problems as the
listpMappingDtabaseTable.
> lispMapCacheLocatorTable OBJECT-TYPE
> lispEidRegistrationEtrTable OBJECT-TYPE

I believe the index clause has the same 'length' problems as the
listpMappingDtabaseTable. Now even 2 times the combination of a
'length' and a 'LispAddressType'.

> lispEidRegistrationLocatorTable OBJECT-TYPE

And this one 3 times the 'length' and a 'LispAddressType' combination.
Also at this place there is a possibility that the OID exceeds the
maximum length of an OID.
.

> lispMapCacheLocatorRlocState OBJECT-TYPE

The SYNTAX defines 3 values, the description only defines 2 of them.
I suggest to align this.
>          SYNTAX     INTEGER {
>                        up (1),
>                        down (2),
>                        unreachable (3)
>                     }
I see various times the above INTEGER syntax. I would suggest to
define a TEXTUAL-CONVENTION for this

>          SYNTAX     INTEGER {
>                        siteself (1),
>                        sitelocal (2)
>                     }

I see various times the above INTEGER syntax. I would suggest to
define a TEXTUAL-CONVENTION for this

> lispIidToVrfName OBJECT-TYPE SYNTAX MplsL3VpnName MAX-ACCESS read-only 
> STATUS current DESCRIPTION "The identifier for each VPN that is mapped 
> to the given LISP Instance ID." ::= { lispIidToVrfEntry 2 } REFERENCE 
> "RFC 4382, Section 7." 
The reference clause is placed incorrectly.
> lispMapCacheLocatorRlocTimeStamp OBJECT-TYPE
> lispMapCacheLocatorRlocLastPriorityChange OBJECT-TYPE
> lispMapCacheLocatorRlocLastWeightChange OBJECT-TYPE
> lispMapCacheLocatorRlocLastMPriorityChange OBJECT-TYPE
> lispMapCacheLocatorRlocLastMWeightChange OBJECT-TYPE
> lispMapCacheLocatorRlocLastStateChange OBJECT-TYPE
Why is the First item a timestamp and others a time ticks?
Does it not make sense to have them algined wit the same type?

      8.1
      <http://tools.ietf.org/html/draft-ietf-lisp-mib-08.html#section-8.1>.
      MIB modules required for IMPORTS

This section is not complete.
The section refers to 1 imported module, but there are still 4 others as 
well
in the IMPORTS section.

    9
    <http://tools.ietf.org/html/draft-ietf-lisp-mib-08.html#section-9>.
    Security Considerations

Is is required that this MIB module is ONLY read-only? As mentioned earlier
I would sugget a read-write MIB module with a READ-ONLY compliance 
statement.
Is done more often in MIB modules.

    Appendix A
    <http://tools.ietf.org/html/draft-ietf-lisp-mib-08.html#appendix-A>.
    Open Issues

I would suggest that the inclusion (or better the choice for NOT including)
would be addres in the overview section or introduction.

Harrie
[email-masked] <mailto:[email-masked]>