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

From: "Gregg Schudel (gschudel)" <[email-masked]>
Date: Tue, 9 Apr 2013 14:57:47 +0000

Resending per request from Benoit.
Sorry if the earlier email missed the appropriate receipients.

Best regards
Gregg

Begin forwarded message:

> Resent-From: <[email-masked]>
> From: "Gregg Schudel (gschudel)" <[email-masked]>
> Subject: Re: [MIB-DOCTORS] draft-ietf-lisp-mib MIB doctor review
> Date: April 5, 2013 12:11:01 PM PDT
> Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
> To: Brian Haberman <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: Amit Jain <[email-masked]>, "Victor Moreno (vimoreno)" <[email-masked]>
> 
> 
> On Feb 22, 2013, at 10:11 AM, Brian Haberman <[email-masked]> wrote:
> 
>> Authors,
>>    Did you receive a copy of this review?  Will you be formulating a response to the questions/issues raised?
>> 
> 
> 
> Hi Brian - sorry for the delays.
> Our reply is included here.
> Thanks so much. 
> Cheers
> gregg/amit/victor
> 
> 
> 
> 
> 
>> Regards,
>> Brian
>> 
>> 
>> -------- Original Message --------
>> Subject: Fwd: [MIB-DOCTORS] draft-ietf-lisp-mib MIB doctor review
>> Date: Thu, 21 Feb 2013 15:06:03 +0100
>> From: Benoit Claise <[email-masked]>
>> To: [email-masked]
>> CC: 'Brian Haberman' <[email-masked]>
>> 
>> FYI.
>> I made a mistake in the initial email below
>> 
>> 
>> -------- Original Message --------
>> Subject: 	[MIB-DOCTORS] draft-ietf-lisp-mib MIB doctor review
>> Date: 	Thu, 21 Feb 2013 14:59:38 +0100
>> From: 	Benoit Claise <[email-masked]>
>> To: 	[email-masked], [email-masked], "MIB
>> Doctors (E-mail)" <[email-masked]>
>> CC: 	'Brian Haberman' <[email-masked]>
>> 
>> 
>> 
>> 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.
> 
> 
> 
> [reply] addressed below in the detailed section
> 
> 
> 
>> 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.
> 
> 
> [reply] addressed below in the detailed section
> 
> 
> 
>> 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?
> 
> 
> [reply] Thank you for this comment. We will clarify that text in the draft;
> it is not assumed, nor required to have a global mapping system. The
> MIB does provide support for LISP ITR, ETR, Map-Server, Map-Resolver, 
> Proxy-ITR, and Proxy-ETR devices. It is quite sufficient to deploy a small 
> set of map-servers and map-resolvers, depending on redundancy needs. These 
> devices have well-defined LISP control plane messaging and operational 
> characteristics covered by this MIB. There is no "single global mapping
> system" -- as several have been proposed (CONS, NERDS, EMACS, DHT, ALT, 
> DDT), and several have been implemented (ALT and DDT). LISP makes no 
> dependencies on any _one_ model and the components covered by this MIB 
> don't see any differences within their status or performance as a result
> either. In fact we expect new ones to be invented and used; we don't 
> want this MIB to have to change, however as a result of any of 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.
> 
> 
> 
> 
> [reply] These terms are defined across several LISP RFCs. Since the LISP
> MIB covers devices described across these various RFCs, it seemed 
> reasonable to aggregate them here for ease of reference. If there is 
> strong sentiment to remove them, then we can do this.
> 
> 
> 
>> 
>>   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
>> 
> 
> 
> [reply]  We will "clarify" the language. The tables includes two types
> of entries, each per-AF: (1) features that can possibly be enabled 
> and their current status (i.e. "true" if enabled or "false" if not), and 
> (2) configurable limits and their current values (or default values 
> if not modified).  Since a "device" can be "configured" to run any
> LISP function (i.e. a router can support ITR/ETR/PITR/PETR/MS/MR) 
> then the MIB will simply report all the features, and their status
> (enabled or not).
> 
> 
> 
> 
>>>   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.
> 
> 
> 
> [reply]  Agreed. We will reword this. Thanks.
> 
> 
> 
>> 
>>   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'.
>> 
> 
> 
> 
> [reply] Great point. Will change. Thanks. 
> 
> 
> 
> 
>>> 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?
> 
> 
> [reply] These three items are taken together - they form "one entity."
> How do we use 3 different objects without losing (a) context, and 
> (b) the generality of information?
> 
> 
> 
> 
>> 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.
>> 
> 
> 
> 
> 
> [reply] Are you saying that in our examples the result was always "1" and 
> so why not just "assume" it's always "1" and get rid of it?  Maybe they are 
> poor examples. We will clarify the example and language. (Not seeing "7"
> as the correct answer.)
> 
> 
> 
>> 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.
> 
> 
> [reply] Why is it a bad idea? How else do you want to get around this? 
> We have variable length objects.
> 
> 
> 
> 
>> 
>>> 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?
> 
> 
> 
> [reply] We do not know that today. It is always "possible" that this
> would be the case - no protocol could assume otherwise. Can you suggest 
> a way to allow for future extensibility?
> 
> 
> 
> 
>> 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.
> 
> 
> 
> [reply]  Our 4+ years of "operational hands-on research" (experience 
> gained in the LISP Beta Network) indicates that new functions are never
> "turned on or off" after a device is deployed. LISP is an architecture, 
> and so you decide what functionality a device needs to have and you
> deploy it. As for things like map-cache size, we've not observed any
> need for changes here either.  We have considered quite carefully whether 
> the LISP-MIB should be read-only or read/write.  The intent of the MIB 
> is to provide status of functions (what's configured) and functionality 
> is the function working and how well). 
> 
> 
> 
> 
>> 
>>> lispFeaturesInstanceID OBJECT-TYPE
>> 
>> The desciption deinfes a default. This should be in the DEFVAL clause.
>> 
>> DEFVAL { 0 }
> 
> 
> [reply]  Thanks. good suggestion.
> 
> 
>> 
>>>   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.
> 
> 
> [reply] We will review this and update it if this is incorrect. 
> 
> 
> 
>> 
>>> 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)
> 
> 
> [reply] Good suggestion. Will review and update.
> 
> 
> 
> 
>>> 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
>> lis! tpMappin gDtabaseTable. 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.
> 
> 
> 
> [reply] The index should be being computed correctly. This has to account
> for variable offsets into the data structures based on various combinations
> of Address Families for locators and eids. We will check the max length 
> (OID) as noted above.
> 
> 
> 
>>> 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
> 
> 
> 
> [reply] An integer is a well-defined value. Why should this be
> a TC? What advantage do you see 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?
> 
> 
> 
> [reply]  Because the first item has to be a timestamp and the others are 
> time-ticks. They are different kinds as described individually.
> 
> 
> 
>> 
>>     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.
>> 
> 
> 
> 
> [reply]  Can you please elaborate? Which 4 others are you referring to?
> 
> 
> 
>>   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.
> 
> 
> [reply] We really want this to be a read-only MIB. Thanks though.
> 
> 
> 
>> 
>> 
>>   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.
>> 
> 
> 
> [reply]  Ok - will review/modify. Thanks
> 
> 
> 
>> 
>> Harrie
>> [email-masked] <mailto:[email-masked]>
> 
> 
> [Amit][Gregg][Victor]  Thank you Harrie for the detailed review 
> and comments.!
> 
>> 
>> 
>> 
>> <Attached Message Part.txt>
> 
> 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
> --------------------------------------------------------------------
>