Subject: [MIB-DOCTORS] Comments on 802.1ag MIB module (dated dec 24th 2006)

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Thu, 11 Jan 2007 15:32:19 +0100

Norm, David Elie..,
We have some more feedback from other MIB doctors.
As always, new/different eyeballs see different/new
things. 

See below comments from David Perkins.
Inline are my responses to David Perkins.
Pls check and consider if changes are warranted.

Dave Perkins commented: 

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: vrijdag 29 december 2006 23:11
> To: Wijnen, Bert (Bert)
> Cc: David B Harrington; [email-masked]; MIB 
> Doctors \\\(E-mail\\\)
> Subject: RE: [MIB-DOCTORS] RE: use of 
> TransportDomain/Address(RFC3419)vsTDomain/TAddres s (RFC2579)
> 
> HI,
> 
> Issues with the notification defined in MIB module IEEE8021-CFM-MIB:
> 1) There is only one notification, and it is reported
>     when "A MEP has a persistent defect condition".
>     Most other similar notifications have either another
>     notification (or a variable in the OBJECTS clause)
>     that indicates the reverse event (in this case,
>     that the persistent defect condition has been
>     resolved). As currently defined, when an notification
>     receiver gets the notification, it must start
>     polling the device to determine when the
>     persistent defect is resolved instead of
>     using another notification to indicate the
>     resolution.

This was raised/discussed by Brian Hassink in the 802.1ag discussions;
and I believe would be resolved as follows:
  Brian reaised:

   3. The text for the fault alarm notification incorrectly
      states that there is a notification whenever a MEP
      loses/restores connectivity.  Currently, a notification is
      generated only when an alarm is raised, and only if it is of
      a higher priority than the configured alarm threshold and any
      other existing alarms.  I would suggest generating a
      notification whenever an alarm, that is of a higher priority
      than the configured alarm threshold, is raised or cleared.
  
   Norm responded:

      makes sense, seems easy to do too.

Or is that not what you meant?

> 2) The persistent defect is not so simple. It is
>     really the most important defect if multiple
>     occur concurrently. However, the complex behavior
>     is not described. For example, if first a
>     not very important persistent defect occurs,
>     and a notification is sent, but later a
>     more important persistent defect occurs,
>     is another notification sent?

I believe that is the intention as per above.
Text seems to need more changes to reflect the above agreement

> 3) The DESCRIPTION clause for the notification makes
>     a reference to "Table 20-1". Well, there is no
>     "Table 20-1" in the MIB module.

The table is in the 802.1ag document. But when a MIB is exatrcted,
that may nopt be clear. I can suggest that the editor change 
"Table 20-1" into "Table 20-1 of the 802.1ag specification".

> 4) The DESCRIPTION clause says....
>      "The management entity receiving the notification can identify
>      the system from the network source address of the
>      notification, and can identify the MEP reporting the defect
>      by the indices in the OID of the dot1agCfmMepHighestPrDefect
>      variable in the notification."
>     Which is not correct in the proxy case, nor strictly speaking

I guess what you are aiming at is that the source address should be
picked up this way may be the address of the proxy. I would think that
is good enough, because if the management station then needs to go poll
the device, then it needs to send a SNMP message to the proxy, no?
Or at least, I would think it can do so.

>     when SNMP is used over Ethernet (as specified in RFC 4789).

I am not sure I understand that. Would it not see the source MAC
address?

>     Also, it would be quite useful to expand out and explain
>     the indices for object dot1agCfmMepHighestPrDefect,
>     such as:
>       dot1agCfmMepHighestPrDefect - specifies the highest
>         priority defect that has been present with it's
>         indices identifying the MEP, which consist of:
>           dot1agCfmMdIndex - index from the Maintenance Domain
>                                table (dot1agCfmMdTable)
>           dot1agCfmMaIndex - index from the Maintenance
>                                Association table (dot1agCfmMaTable)
>           dot1agCfmMepIdentifier - final index in the
>                                Maintenance Association
>                                End Point (MEP) table
>                                (dot1agCfmMepTable)

Might be useful. So Norm, can you add that?

> -------------------------
> Continuing with other issues....
> 
> For me, the most important part of MIB module design is 
> describing the tables, including:
>   1) consistent descriptions for how many entries are in
>      each table and how that count is related to attributes
>      of the system
>   2) what are the relationships (if any) between the tables,
>      and whether or not there is referential integrety between
>      related tables. (For example, if in this MIB module,
>      what happens to related entries in tables dot1agCfmMaTable
>      and dot1agCfmMepTable when a related row in table
>      dot1agCfmMdTable is deleted.)
>   3) How are rows created and deleted in tables? Is this
>      through operation of the system, and/or through
>      management operations including SNMP. And if through
>      SNMP operations, what must be done.
> For this MIB module, some of the info is present, but it is a 
> little muddled. 

I guess there is always room for more explanation/text.
But at some point one has to agree that it is good enough.

> Some of the bigger issues are:
> 
> 1) This module allows row creation for tables 
> dot1agCfmMdTable and  dot1agCfmMaTable and uses the MIB 
> design pattern of having an object that indicates an unused 
> index. This pattern works only in limited cases, and for this 
> MIB module, it is appropriately applied for table 
> dot1agCfmMdTable, but not for table dot1agCfmMaTable. To 
> support this design pattern, object dot1agCfmMaTableNextIndex 
> should be a column of table dot1agCfmMdTable instead of a scalar.
> 
Good catch.
I think that the current scalar also works. But I agree that if 
this MaTableNextIndex object were a column of the MdTable, then the
values would be unique to each Md and not scattered over all Mds.

Norm, would you consider making this change at this point in time?

> 2) I don't understand the use of table 
> dot1agCfmMaMepListTable, it seems redundant with table 
> dot1agCfmMepTable.
> 

Mmm... you could be right.
Spcifically it is confusing that this table is also read-create.
I could understand if it were just a way to quickly get a list of
MEPids,
but then it would be a shorthand read-only implementation of the
epTable.

Norm, what was/is the intention of this MepListTable again?

> 3) I don't see how entries in dot1agCfmStackTable come into 
> and go out of existance? What is the relationship to rows in 
> tables dot1agCfmMdTable and dot1agCfmMaTable?
> 

I believe entries come and go based on entries added/deleted to/from
the MepTable.

Am I correct Norm?

Maybe we should add some words about that to the StackTable DESCRIPTION
clause.

> 4) Table dot1agCfmVlanTable seems to be underspecified.
> 

Could be. As I state elsewhere, one can always add more text and
explanation. What is unclear?

> 5) Table dot1agCfmMepTable seems overly complex. It seems
>     like it should be split up (but maybe this was already
>     done). It's just quite messy as is.
> 

Mmm... in fact it was multiple (I bleieve 3 tables) earlier on.
But that had a lot of duplication. Then they got merged. I will
agree that this table is now having quite a lot of columns, which
indeed makes it somewhat complex.
Not sure we want to go back and split it again.

> ---------------------
> Other items that I would fix include:
> 1) fixing spelling

I/we assume that final editing pass of IEEE 802.1 process will
take care of spelling errros (like our RFC-Editor does).

> 2) adding more text to the DESCRIPTION clause of the
>     module identity to include:
>     a) what the items defined in the module would be used for
>        (help the reader to determine there the module is applicable)

I can suggest that, however, see below

>     b) common abbreviations and acronyms

same

> 3) remove references in DESCRIPTION clauses to tables and other
>     information in the IEEE 802.1ag document.
> 

What is wrong with using a REFERENCE clasue that specifies the document
(802.1ag) plus section/cause and/or table in that document?
Is that any different than us using a REFERENCE clause to some other RFC
(or even the same RFC)? 
Note that the authoritative version of the MIB module is PART OF THE
802.1ag SPEC/document.

> ---------------
> Good luck with further review and clean up. I spent a couple 
> of hours yesterday and about 2 hours today. I skimmed through 
> the IEEE document (it's approx 250 pages), and some of the 
> concepts that are not explained in the MIB module are 
> described in the IEEE document.
> However, it is a long document, and is complicated by it 
> trying to add additional levels of adstraction to VLANs.

Yep, I agree that one needs to be well versed in 802.1 and VLAN
terminology/technology before you could implement an agent or
a management app for this MIB module. I think that that is OK.

> The  security issues seem to me to be nonimplementable by existing 
> SNMP toolkits, but that question should be better answered by 
> the SNMP toolkit suppliers.

I agree on that and we (Dan and I) spend quite some time discussing
this with the authors/editors and the 802.1ag TG. I do not see how
to make it much easier though; Certainly not without needing major
work. I have brought up the complexity several times in the TG, and
suggested that all would go back to their developers to ensure that
this is all implementable. I also indicated that actually populating
the access control tables and views etc might be a nightmare and that
there are additional complexities if a system reboots and a ifNumber
would change as a result. 
It seemed people were happy with (or did not understand) what is in
the MIB module and what access control implications it has from an
implementation, but also from a deployment point of view. 
But who are we to try to force them to change after we have pointed
out the issues.

> Skimming the document does 
> confirm my concerns about notification delivery - which is 
> the MIB module simply specifies an address to send a 
> notification, which is not sufficient for sending a notification.
> 
To this one I will come back in a separate email.

Bert
> Best wishes for the new year!
> 
> Regards,
> /david t. perkins
> 
> 

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: "Norman Finn \(nfinn\)" <[email-masked]>
Date: Thu, 11 Jan 2007 15:05:14 -0800

Bert and David,

First of all, thanks much for the careful review.

1. Notification that the condition has ceased.

In discussions with carriers in ITU Q.5/13, no need for a notification
that everything is OK was raised.  This would require changes to the
state machine, clause 12, and the MIB, and would be a bigger change than
is appropriate at this stage of the process.  This could be raised as a
Sponsor Ballot comment, and changed, then.

My "makes sense, is easy to do" comment applied to the raising of a more
important fault alarm.  I apologize for not picking up the "or cleared".
I should have, so I see why you bring it up.

2. New more-important defects.

The MIB has been changed to say "MEP has a persistent defect condition".
A paragraph has been added mentioning that a higher-priority defect will
trigger another Fault Alarm.

3. Reference to Table 20-1

Whenever Table 20-1 is referenced in a REFERENCES clause, P802.1ag is
mentioned.  There are dozens of references in the DESCRIPTION clauses
that parallel the REFERENCES clause.  Is there really any confusion,
here????  I don't think any changes are necessary for this.

4. Source of the Notification

Is the source IP or (for SNMP/Ethernet) source MAC address not
sufficient?  How is the source of the notification normally conveyed?

5. MA/MD index.

Absolutely correct.  The next MA index should be in the MD table.  I'll
fix that.

Additional text added to described the indices of the Fault Alarm
variable.

6. Fault alarm address

We're using TransportDomain, now.

7.  Additional explanations.

The use of the stack table and MIB DB table are quite sufficient, if one
reads the rest of 802.1ag.  The MIB module is not a substitute for the
standard, and cannot incorporate the standard as a whole.  Rather, as
Bert points out, the MIB module is included in the document.  This is a
very complex document, and deciding exactly how much to put into the MIB
module descriptions is a judgment call.  I judge we're done.  :)

-- Norm

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Thursday, January 11, 2007 6:32 AM
> To: David T. Perkins; Norman Finn (nfinn); David 
> Elie-Dit-Cosaque; [email-masked]
> Cc: MIB Doctors
> Subject: Comments on 802.1ag MIB module (dated dec 24th 2006)
> 
> Norm, David Elie..,
> As always, new/different eyeballs see different/new things. 
> 
> > Cc: David B Harrington; [email-masked]; MIB Doctors 
> > \\\(E-mail\\\)
> This was raised/discussed by Brian Hassink in the 802.1ag 
> discussions; and I believe would be resolved as follows:
>   Brian reaised:
> 
> The table is in the 802.1ag document. But when a MIB is 
> exatrcted, that may nopt be clear. I can suggest that the 
> editor change "Table 20-1" into "Table 20-1 of the 802.1ag 
> specification".
> 
>