Subject: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10

From: Steve Waldbusser <[email-masked]>
Date: Tue, 16 Jul 2013 18:02:07 -0700

Hello,

Here's my review of the the VPLS MIB.

1. There are three tables that have a many-to-one relationship with the 
vplsConfigTable AND that
    allow SNMP create operations. A potential ambiguity exists in the 
creation process for these
    tables. For example one could create entries in the vplsPwBindTable 
that reference VPLS entries
    that don't yet exist: IOW one could create 
vplsPWBindRowStatus.VPLS-A.PW-B and THEN create vpls-A
    in the vplsConfigTable. It is perfectly alright for the inactive 
rows in the vplsPWBindTable to
    have unresolved dangling references to VPLS-A as long as VPLS-A is 
created before the PWBind
    Entry is set to active. On the other hand, it has been my experience 
that agent writers will not
    allow that mode of operation (i.e. will not allow creation of the 
dangling references) unless the MIB
    explicitly mandates it and I think such a mandate may be more 
trouble than it's worth. Therefore,
    to protect an NMS writer from ordering their create operations that 
way and not interoperating,
    I'd suggest explicitly saying that it is optional for the agent to 
allow entries to be created
    that point to non-existent VPLSConfig entries. The most 
straightforward path is for the NMS to create the
    VPLSConfig entry and then the vplsPWBind entries.

The relevant tables are:

       VplsPwBindEntry ::=
           SEQUENCE {
               vplsPwBindConfigType              INTEGER,
               vplsPwBindType                  INTEGER,
               vplsPwBindRowStatus             RowStatus,
               vplsPwBindStorageType             StorageType
           }
           INDEX  { vplsConfigIndex, pwIndex }

       VplsBgpRteTargetEntry ::=
          SEQUENCE {
           vplsBgpRteTargetIndex          Unsigned32,
           vplsBgpRteTargetRTType         VplsBgpRouteTargetType,
           vplsBgpRteTargetRT             VplsBgpRouteTarget,
           vplsBgpRteTargetRowStatus      RowStatus
          }
          INDEX     { vplsConfigIndex, vplsBgpRteTargetIndex }

      VplsBgpVEEntry ::= SEQUENCE {
           vplsBgpVEId          Unsigned32,
           vplsBgpVEName        SnmpAdminString,
           vplsBgpVEPreference  Unsigned32,
           vplsBgpVERowStatus   RowStatus,
           vplsBgpVEStorageType StorageType
         }
         INDEX  { vplsConfigIndex, vplsBgpVEId }

2. In a related matter, it would be good to define what happens to rows 
in the above three tables
    when the associated vplsConfigEntry is deleted. One option is 
nothing happens (i.e. allow the
    dangling references). Another option is language in the RowStatus 
objects like: "If this object
    is set to destroy(6) or deleted by the agent, all associated entries 
in the VplsPWBindTable,
    vplsBGPRteTargetTable and vplsBgpVETable shall be deleted."

3. vplsConfigRowStatus
    vplsPwBindRowStatus
    vplsBgpADConfigRowStatus
    vplsBgpRteTargetRowStatus
    vplsBgpVERowStatus

    What columns in those tables must be set to valid values before 
these RowStatus objects can be set
    to active? (Presumably all of them)? [Ref: RFC4181 4.6.4]

4. vplsPwBindEntry
    vplsBgpADConfigEntry
    vplsBgpRteTargetEntry
    vplsBgpVEEntry

    As per RFC4181 4.6.4, "If the agent itself may also create and/or 
delete rows, then the conditions
    under which this can occur MUST be clearly documented in the row 
object DESCRIPTION clause."

    Something like: "Entries in this table may be created or deleted 
through SNMP, as side-effects of
    console or other non-SNMP management commands, or upon learning via 
autodiscovery."

5. VplsBgpADConfigEntry
    VplsBgpRteTargetEntry

    These tables need a StorageType object

6. vplsPwBindStorageType
    Presumably if this row was from auto-discovery, the storagetype for 
this row should be 'volatile' or
    'other'. My argument for 'other' is that the entry is 
'algorithmically' stored.
    Further, you might want to document that if autodiscovered entries 
are deleted they would likely
    re-appear in the next autodiscovery interval. I'm guessing you don't 
intend to
    store a "negative" entry to keep the entry from reappearing. You'd 
have trouble deleting the
    negative entry anyway.

    Similar issue for vplsBgpRteTargetRowStatus.

7. Page 6: Section 5: Example of the VPLS MIB modules usage

    Bravo for including an example section!

8. This document is structured as three separate MIB modules. Did you 
consider putting everything in
    one MIB module and using the conformance section to modularize the 
MIB into 3 optional groups?

9. Page 15: vplsStatusTable

   Do you intend to add a bunch of other stats to this table in the 
future? Since vplsStatusTable is
   a one-to-one mapping with vplsConfigTable and fate-shares with it, 
these could just be read-only
   variables in the vplsConfigTable and then this table would be 
unnecessary. . Further, if it is
   important that this be in a separate table then this should use the 
AUGMENTS clause, not
   INDEX. AUGMENTS is used for sub-tables that have a one-to-one mapping 
and that fate-share, like
   this one.

10. Page 23 vplsStatusChanged NOTIFICATION-TYPE

   Need to specify which instances are included in the notification. 
Something like this: "The object
   instances included in the notification are the ones associated with 
the VPLS service
   whose status has changed."

   vplsFwdFullAlarmRaised NOTIFICATION-TYPE

   Similarly: "The object instances included in the notification are the 
ones associated with the
   VPLS service which has exceeded the threshold"

   vplsFwdFullAlarmCleared NOTIFICATION-TYPE

   Similarly: "The object instances included in the notification are the 
ones associated with the
   VPLS service which has fallen below the threshold."

11. Page 30: vplsLdpConfigMacAddrWithdraw: This object should be 
read-write, not read-create.

12. Generally: How does the agent know that you intend to start BGP or 
LDP on a VPLS entry that you
have created with SNMP?

13. Page 31: vplsLdpPwBindMacAddressLimit

     Given there's no RowStatus I assume entries in the table are 
created by the agent as a side
     effect of the creation of PW bindings on an LDP-managed vpls 
service (regardless of whether the
     service or PW bindings were created manually, by signaling or
     by SNMP.

     If this assumption is correct then the object should be read-write,
     not read-create.

14. Page 42: Security Considerations

     In order to comply with rfc4181 Section 3.4, this should state 
explicitly that
     while the read-write and read-create objects must be protected by 
secure SNMP,
     none of them are especially disruptive. Similarly, while the 
read-only objects might present
     privacy concerns and due consideration should be given to 
protecting them with secure SNMP,
     none of these objects contain especially sensitive information.

I also have a number of smaller items that I wrote notes about when I 
was on vacation. I need to collect those notes and
send them in another email.

Steve

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 19 Jul 2013 14:29:29 -0700 (GMT-07:00)

Hi -

>From: Thomas Nadeau <[email-masked]>
>Sent: Jul 17, 2013 2:02 PM
>To: Andy Bierman <[email-masked]>
>Cc: Randy Presuhn <[email-masked]>, "Kiran Koushik Agrahara Sreenivasa (kkoushik)" <[email-masked]>, "Giles Heron (giheron)" <[email-masked]>, [email-masked], [email-masked]
>Subject: Re: [MIB-DOCTORS] Review of draft-ietf-l2vpn-vpls-mib-10
... 
>> A: in the end it doesn't matter.  NMS developers are not
>> using SNMP for configuration.
>
>	I agree. Having this debate is a waste of time;
> the industry has voted a long time ago...

This list doesn't make sense as place for that debate.
We were asked to comment on a question regarding
a specific aspect of MIB module design.  *That* is what
we should be talking about.  Steve has suggested one
approach to accomplish what the WG wanted to do,
I've suggested another approach, and Andy seems to
be advocating "no, you shouldn't even try to use
SNMP to do this."  If that last case is indeed the
consensus of the MIB doctors, then it's time to
re-do the review guidelines to say that even though
SNMP can be used for these things, it's NOT
RECOMMENDED because "the industry" is doing something
else.

Randy