Subject: Re: [OSPF] MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt

From: "Joan Cucchiara" <[email-masked]>
Date: Fri, 7 Mar 2008 12:37:07 -0500

Hello,

I do also have one other question.  There seems to be
quite a bit of overlap between RFC4750 (OSPFv2 MIB)
and this draft.  While I understand that there are obvious
differences between IPv4 and IPv6 addresses, and also
some differences in OSPFv2 vs. OSPFv3, I still see many
of the same MIB objects in the 2 MIB Modules, did the
authors consider using OSPFv2 MIB and doing AUGMENTS
for OSPFv3?

Please give me some background/history on why a completely
separate MIB Module was done for OSPFv3.

Thank you,
   Joan

----- Original Message ----- 
From: "Joan Cucchiara" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>; "Acee Lindem" 
<[email-masked]>; <[email-masked]>; "MIB Doctors (E-mail)" 
<[email-masked]>
Cc: "Ronald Bonica" <[email-masked]>; "Abhay Roy" <[email-masked]>; 
"Ross Callon" <[email-masked]>; "Vishwas Manral" 
<[email-masked]>; "Dan Joyal" <[email-masked]>; "Bert Wijnen" 
<[email-masked]>; "David Ward" <[email-masked]>
Sent: Friday, March 07, 2008 2:37 AM
Subject: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt

>
> Hi Folks,
>
> First is the output from the MIB tools.
> Followed by some General Comments, and then followed by
> fairly specific comments/questions on the MIB.
>
> Thanks,
>   Joan
>
>
> SMICNG results:
> ----------------
>
> E: f(OSPFV3-MIB.txt), (2523,21) Item "ospfv3AreaAggregateRouteTag"
> in sequence "Ospfv3AreaAggregateEntry" has conflicting syntax specified
>
> E: f(OSPFV3-MIB.txt), (756,31) Index item "ospfv3AsLsdbLsid"
> must be defined with syntax that includes a range
>
> E: f(OSPFV3-MIB.txt), (904,31) Index item "ospfv3AreaLsdbLsid"
> must be defined with syntax that includes a range
>
> E: f(OSPFV3-MIB.txt), (1066,31) Index item "ospfv3LinkLsdbLsid"
> must be defined with syntax that includes a range
>
> E: f(OSPFV3-MIB.txt), (2647,31) Index item "ospfv3VirtLinkLsdbLsid"
> must be defined with syntax that includes a range
>
>
> smilint
> ------------
> severity level requested 6
>
> line  severity  problem
> --------------------------
>
> 2844 5 warning: `InetAddress' object should have an
>                accompanied preceding `InetAdressType' object
> (Please see comments below wrt Notifications)
>
>
>
> ID NITS (== 1 warning)
> --------
>
> == The copyright year in the IETF Trust Copyright Line does not match the
>     current year
>
>
>
>
> General Comments
> -----------------
>
> 1) Need to have a read-only conformance.
>
> 2) I would like to understand the use of the single
> DiscontinuityTime object for all the counters in the
> MIB.  My thoughts are that having a few more discontinuity
> objects (specifically in tables) would be more beneficial,
> so please give me some feedback on this, so I can understand
> why only one Discontinuity object is used.
>
> 3) Throttling of notifications and Polling Event Counters.
> I think more details of this need to be in the MIB itself.
> Please expand some of these DESCRIPTIONS.
>
> 4) Please note that many of my comments apply to the entire MIB, although
> I only commented on the first few objects.  Please be sure to check the
> entire MIB for an issue.  For example, please rename any RowStatus object
> with xxxRowStatus, please spell out Interval, etc.
>
> 5) The MIB did not extract using mstrip (MIB tool).
> If possible, could this be fixed?
>
>
> Comments in Order of the document
> ----------------------------------
>
> 1) (NIT) Header should say:
> Proposed Status: Standards Track
>
>
> 2) (NIT) Expiration date has incorrect year.
>
>
> *) (NIT) please be consistent with using
> RFCXXX vs. MIB tree assignment, so for example
>
>             DESCRIPTION
>                 "The MIB module for OSPF version 3.
>
>                 Copyright (C) The IETF Trust (2007).
>                 This version of this MIB module is part of
>                 RFC XXXX;  see the RFC itself for full legal
>                 notices."
>
>             REVISION "200709171200Z"
>             DESCRIPTION -- RFC Editor assigns RFC XXXX
>                 "Initial version, published as RFC XXXX"
>
>             ::= { mib-2 YYY } -- to be assigned by IANA
>
>
>
>
> *)Ospfv3UpToRefreshIntervalTc
>
>  *) Please change to use TC (in caps) so, Ospfv3UpToRefreshIntervalTC
>
>  *)  Could  DISPLAY-HINT "d" be used instead?
>
>  *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.)
>
>  *) Please add a reference
>
> *) Ospfv3DeadIntRangeTc
>  *) Please spell out Interval and change Tc to TC,
>      i.e. Ospfv3DeadIntervalRangeTC
>
>  *) Could  DISPLAY-HINT "d" be used instead?
>
>  *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.)
>
>  *) Please add a reference
>
> *) Ospfv3RouterIdTC
>
>  *) Please use TC, Ospfv3RouterIdTC
>
>  *) Could  DISPLAY-HINT "d" be used instead?
>
>  *) Please add a reference
>
> *) Ospfv3AreaIdTc
>
>  *) Please use TC, Ospfv3AreaIdTC
>
>  *) Could  DISPLAY-HINT "d" be used instead?
>
>
>  *) Please add a reference
>
>
> *) Ospfv3IfInstIdTc
>
>  *) Please Tc to TC, i.e. Ospfv3IfInstIdTC
>
>  *) Could  DISPLAY-HINT "d" be used instead?
>
>  *) Should be Unsigned32 (see rfc4181.txt section 4.6.1.1.)
>
>  *) Please add a reference
>
>
> *) ospfv3RouterId
>
> Isn't this a 32-bit unsigned integer?
> Please add REFERENCE clause.
>
>
> *) ospfv3AreaBdrRtrStatus
>
> Please indicate the value of the flag
> when the router is an area border router.
> (i.e. when the value of this object is true(1)...)
>
> *) ospfv3AsScopeLsaCksumSum
>
>  *) should be Unsigned32
>
>
> *) ospfv3DemandExtensions
>
> Same comment as with the previous object that has SYNTAX of TruthValue,
> please specify, when this object has the value of true(1), then
> the router supports demand circuits...
>
> *) ospfv3ReferenceBandwidth
>
> -Please add UNITS
> -Please add DEFVAL
> - Please add REFERENCE
>
>
> *) ospfv3RestartSupport
>
> -Is there a value which could be considered a DEFVAL for
> this object?
> (In general, please review all the read-write objects
> and add DEFVALs if appropriate).
>
> *) ospfv3RestartInterval
> -Is there a value which could be considered a DEFVAL for
> this object?
>
>
> *) ospfv3RestartStrictLsaChecking
>
> Please indicate what true(1) means in the DESCRIPTION
> (Please do this for all objects which contain a
> TruthValue)
>
> *) ospfv3RestartExitRc
>
> What does the Rc stand for, could this be spelled out?
>
> Are any additional objects needed to tell when the
> value of this object changed?
>
> *) ospfv3NotificationEnable
>
> Why is this object needed?  Or,in other words, why
> can't RFC3413 be used.
>
> *) ospfv3StubRouterAdvertisement
>
> Need to add DEFVAL
> Please add a REFERENCE
>
> *) ospfv3AreaTable
>
> - This table has a combination of both objects to configure
> areas and statistics for areas.  Could this be devided into
> 2 tables one for configuring and one for status/statics?
>
> Additionally, if is not clear to me what happens when an attached
> area is established and then the configuration changes?  Can
> the configurable objects be changed?
>
> Also, the counters in this table refer to ospfv3DiscontinuityTime
> but if the OSPFv3 routing process starts-up, then my understanding
> is that these counters might be affected (specifically, 
> ospfv3AreaNssTranslatorEvents),
> so I think another discontinuityTime object is needed...please comment.
>
>
> *) ospfv3AreaId
>
> Isn't this unsigned?
>
>
> *) ospfv3AreaBdrRtrCount and other Gauge32 objects in this
> table may have a DEFVAL clause of zero (this is mentioned in
> the DESCRIPTION clauses).
>
> *) ospfv3AreaScopeLsaCksumSum
>
> Should this be Unsigned32?
>
>
> *) ospfv3AreaStatus
>
> Please rename to ospfv3AreaRowStatus
>
> *) ospfv3AreaStubMetric
>
> Is there a DEFVAL for this object?
>
>
> *) ospfv3AreaNssaTranslatorStabInt
>
> Please use entire word Interval
>
>
>
> *) ospfv3AsLsdbSequence
>
> Should this have a range?
>
> *) ospfv3AreaLsdbSequence
>
> (same question, is there a range for this?)
>
> *) ospfv3AreaLsdbAge
>
> Unsigned32 and a range?
>
> What is the value if the DoNotAge Bit is set?
>
> *) ospfv3AreaLsdbChecksum
>
> Should this be unsigned32?
>
>
> *) ospfv3AreaLsdbTypeKnown
>
> Please indicate what true(1) means in the
> DESCRIPTION
>
> *) ospfv3LinkLsdbSequence
>
> Same comment as with the other Sequence numbers,
> should this have a range?  Additionally, should these
> sequence numbers have a common TC?
>
> *)ospfv3LinkLsdbAge
>
> same comments and questions
> as with the "Age" object in the prior table?
>
> *) ospfv3LinkLsdbChecksum
>
> Unsigned32?
>
>
> *) ospfv3HostTable
>
> Need to have a storageType object added to this table.
>
>
>
>
>
> *) ospfv3HostStatus
>
> Please rename to ospfv3HostRowStatus
> Usually, this is the last in the list of objects.
>
> *)ospfv3IfTable
>
> Don't understand the REFERENCE here, please explain.
>
>
> Same comment as with the other table, there is mix of
> configuration and status/statistics in this one table.
> Could this be made into 2 tables?
>
> Also, the Counters in this table
> likely need their own discontinuityTime object....
>
> Can configurable objects change once the interface
> is established (for example, if the interface is pointToPoint?)
>
>
>
>
> *) ospfv3IfTransitDelay
>
> Don't understand the DESCRIPTION here.  Could you
> please expand.
>
> Is there a REFERENCE that could be added?
>
> *) ospfv3IfStatus
>
> Please rename to ospfv3IfRowStatus
>
> *) ospfv3IfAdminStat
>
> Would an OperStatus object be beneficial in this
> table?
>
> *) ospfv3IfDemandNbrProbeRetxLimit
>
> Retx is used for Retransmission, elsewhere Retrans
> was used.  Please be consistant.
>
> *) ospfv3VirtIfTable
>
> Don't understand the reference here.  If this is
> an IPv6/V3 specific table then why are you
> Refering to OSPFv2?  Is this correct?  Additionally,
> could a OSPFv3 REFERENCE be added also?
>
> Same comments as with the other tables that have
> a mix of config and status/statistics objects.
>
> Please change RowStatus objects to have RowStatus
> at the end of their name.
>
> *) ospfv3NbrTable
>
> Same question as to how the Counters in this table
> can successfully use ospfv3DiscontinuityTime.  In other
> words, if this table is specific to neighbors, then
> the counters are also, so there might be (at least it
> seems to me) a case where an entry in this table is
> affected and neighbor counters suffer a discontinuity
> but the ospfv3DiscontinuityTime may not.  Please comment.
>
>
> *) ospfv3NbrTable and ospfv3CfgNbrTable
>
> What is the relationship between these 2 tables?
> The indexing is different between the 2 tables and so
> I'm wondering what the relationship is between them.
>
>
>
> *) ospfv3AreaAggregateRouteTag
>
> Is this Unsigned32?
>
>
> Notifications
> ------------
>
> In general the accessible-for-notify objects should probably be
> changed into read-only objects.  Additionally, a timestamp should
> be associated with some of these.  There is an assumption made that
> it is better to send out notifications rather than poll, but I'd
> rather give the operator the choice on that.
>
>
>
>
>
>
>
> Compliance Statements
> -------------------------
>
> * Need a Read-only compliance statement.
> It is missing.
>
> ---
>
>
>
>
>
> 

_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: David Ward <[email-masked]>
Date: Fri, 7 Mar 2008 11:39:49 -0600

The two (V2 and V3) are incompatible.

-DWard

On Mar 7, 2008, at 11:37 AM, Joan Cucchiara wrote:

> ----- Original Message ----- From: "Joan Cucchiara"  
> <[email-masked]>
> <[email-masked]>; <[email-masked]>; "MIB Doctors (E-mail)" <mib- 
> [email-masked]>
> Cc: "Ronald Bonica" <[email-masked]>; "Abhay Roy"  
> <[email-masked]>; "Ross Callon" <[email-masked]>; "Vishwas  
> Manral" <[email-masked]>; "Dan Joyal" <[email-masked]>;  
> "Bert Wijnen" <[email-masked]>; "David Ward" <[email-masked]>

---

From: Acee Lindem <[email-masked]>
Date: Fri, 7 Mar 2008 12:48:46 -0500

Hi Joan,
Thanks much for the thorough and prompt review. There are some basic  
semantic differences between OSPFv2 and OSPFv3. Hence, I'm not sure  
if it is feasible to combine the MIBs. Also, over the long term our  
intent is to incorporate new function into OSPFv3 that will not be  
contained in OSPFv2. Finally, we've been working on this MIB for so  
long that I don't think it is in the best interest of the OSPF WG to  
even attempt consolidation.
Thanks,
Acee

---

From: "Joan Cucchiara" <[email-masked]>
Date: Tue, 11 Mar 2008 10:31:41 -0500

Hi Folks,

I have a couple of clarifications inline below.

Thanks,
   Joan

----- Original Message ----- 
From: "Joan Cucchiara" <[email-masked]>
To: "Joan Cucchiara" <[email-masked]>; "Romascanu, Dan (Dan)" 
<[email-masked]>; "Acee Lindem" <[email-masked]>; <[email-masked]>; 
"MIB Doctors (E-mail)" <[email-masked]>
Cc: "Ronald Bonica" <[email-masked]>; "Abhay Roy" <[email-masked]>; 
"Ross Callon" <[email-masked]>; "Vishwas Manral" 
<[email-masked]>; "Dan Joyal" <[email-masked]>; "Bert Wijnen" 
<[email-masked]>; "David Ward" <[email-masked]>
Sent: Friday, March 07, 2008 12:37 PM
Subject: Re: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt

>> fairly specific comments/questions on the MIB.

It has been explained to me that the read-only conformance
is not a requirement.
However, the working group need to be aware of what it means
to NOT have a read-only conformance.

Here is the relevant text from RFC 4181:

   - If there are any objects with a MAX-ACCESS value of read-write or
     read-create for which there is no OBJECT clause that specifies a
     MIN-ACCESS of read-only, then implementations must support write
     access to those objects in order to be compliant with that MODULE-
     COMPLIANCE statement.  This fact sometimes catches MIB module
     authors by surprise.  When confronted with such cases, reviewers
     SHOULD verify that this is indeed what the authors intended, since
     it often is not.

   - On the other side of the coin, MIB module authors need to be aware
     that while a read-only compliance statement is sufficient to
     support interoperable monitoring applications, it is not sufficient
     to support interoperable configuration applications.  A technique
     commonly used in MIB modules that are intended to support both
     monitoring and configuration is to provide both a read-only
     compliance statement and a full compliance statement.  A good
     example is provided by the DIFFSERV-MIB [RFC3289].  Authors SHOULD
     consider using this technique when it is applicable.

I would ask that the authors and working group comment on the
read-only conformance, either for or against, and why.  In my personal
experience not all operators want to use SNMP to configure, so having
a read-only conformance allows MIB implementations to be compliant
to the MIB standard.  In other words, read-only conformance guides
MIB implementors on the interoperability with read-only conformance,
just as the full (read and write) conformance does.  Certainly, I would
encourage this to be added to the MIB, but it is not mandatory.

>> why only one Discontinuity object is used.

Having discussed this with other MIB Drs. has lead me to
rephrase the above, please comment on 2 issues:

a) situations where counters could suffer a discontinuity
(e.g. a single OSPFv3 area's counters could have a discontinuity)
The reason is that the document specifies only one OSPFv3 related
reason for counters to suffer a discontinuity (i.e., the restart of the 
OSPFv3
routing process) and this is in the text of the document, not the MIB 
portion
of the document.  Describing more specific OSPFv3 situations in the MIB 
document itself
would help implementors.

b)  some of the indexes use InterfaceIndex from the IF-MIB.  The counters
in these tables "might" be related to the  ifCounterDiscontinuityTime 
object.
More discussion on these tables would be helpful to determine if this
is so.

In essence, more Discontinuity objects may NOT be beneficial, and so
would like to discuss a) and b) above before making that determination.

Thanks,
   -Joan

---

From: "Daniel Joyal" <[email-masked]>
Date: Thu, 13 Mar 2008 17:51:46 -0400

Hi,

 Please see my comments below.

Thanks.
-Dan 

> -----Original Message-----
> From: Joan Cucchiara [mailto:[email-masked]] 
> Sent: Tuesday, March 11, 2008 11:32 AM
> To: Joan Cucchiara; Romascanu, Dan (Dan); Acee Lindem; 
> [email-masked]; MIB Doctors (E-mail)
> Cc: Ronald Bonica; Abhay Roy; Ross Callon; Vishwas Manral; 
> Joyal, Daniel (BL60:SF23); Bert Wijnen; David Ward
> <[email-masked]>; "Acee Lindem" <[email-masked]>; 
> <[email-masked]>; "MIB Doctors (E-mail)" <[email-masked]>
> <[email-masked]>; "Ross Callon" <[email-masked]>; 
> "Vishwas Manral" 
> > I do also have one other question.  There seems to be quite 
> a bit of 
> > overlap between RFC4750 (OSPFv2 MIB) and this draft.  While I 
> > understand that there are obvious differences between IPv4 and IPv6 
> > addresses, and also some differences in OSPFv2 vs. OSPFv3, 
> I still see 
> > many of the same MIB objects in the 2 MIB Modules, did the authors 
> > consider using OSPFv2 MIB and doing AUGMENTS for OSPFv3?
> >
> > Please give me some background/history on why a completely separate 
> > MIB Module was done for OSPFv3.
> >
> > Thank you,
> >   Joan
> >
> >
> > <[email-masked]>; "Ross Callon" <[email-masked]>; 
> "Vishwas Manral"
[snip]
> encourage this to be added to the MIB, but it is not mandatory.

Since it's not mandatory, do many MIB authors opt to add a
read-only conformance? In other words, is it common practice?

> of the document.  Describing more specific OSPFv3 situations 

The thinking was that an OSPFv3 instance would never clear its SNMP
counters after it is started, so only the coarse discontinuity
timer is necessary. I will add the text into the MIB module in
the discontinuity timer object description.

> More discussion on these tables would be helpful to determine if this

The ifCounterDiscontinuityTime does not apply to the counters associated
with OSPFv3 interfaces.

> would like to discuss a) and b) above before making that 
[snip to end]

---

From: "Joan Cucchiara" <[email-masked]>
Date: Mon, 17 Mar 2008 23:05:50 -0500

> From: "Daniel Joyal" <[email-masked]>
> <[email-masked]>; "Bert Wijnen" <[email-masked]>; "David 
> Ward"
> <[email-masked]>
> Sent: Thursday, March 13, 2008 4:51 PM
> Subject: RE: MIB Dr. Review of draft-ietf-ospf-ospfv3-mib-12.txt
>
>
> Hi,
>

Yes, it is common practice.

> the discontinuity timer object description.

Thank you.

> The ifCounterDiscontinuityTime does not apply to the counters associated

Okay.  I do have a couple more questions,
is there a one-to-one mapping between an OSPFv3 Interface and an IPv6 
interface?
If so, then do the DiscontinuityTimeObjects in RFC4293 apply to OSPFv3 
interfaces
as well?

More generally, does the IP-MIB in RFC4293 need to be populated prior to 
this MIB?

-Joan

---

From: "Daniel Joyal" <[email-masked]>
Date: Fri, 21 Mar 2008 17:41:40 -0400

[snip]
> read-only 
> > conformance? In other words, is it common practice?
> >
> 

Then we will follow doctor's advice ;-)

> > The ifCounterDiscontinuityTime does not apply to the counters 
> > associated with OSPFv3 interfaces.
> >
> 
> Okay.  I do have a couple more questions, is there a 
> one-to-one mapping between an OSPFv3 Interface and an IPv6 interface?
> If so, then do the DiscontinuityTimeObjects in RFC4293 apply 
> to OSPFv3 interfaces as well?

There is a one-to-one relationship for non-virtual interfaces, but
the OSPFv3 interface should survive a recycling of the lower layer
interface, that is, recycling of the lower layer interface should
not cause an OSPFv3 interface to clear its SNMP counters.

> 
> More generally, does the IP-MIB in RFC4293 need to be 
> populated prior to this MIB?

In general, there should be a corresponding entry in the
ipv6InterfaceTable
from the IP-MIB for non-virtual OSPFv3 interfaces, but I think
the dependency of the configuration of an OSPFv3 interface upon
the configuration of an IPv6 interface would be implementation specific.

Thanks.
-Dan