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

From: Steve Waldbusser <[email-masked]>
Date: Wed, 14 Aug 2013 16:15:51 -0700

On 8/14/2013 2:07 PM, Agrahara Kiran Koushik wrote:
>
>> 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?
> [kiran] We had specific requests in the beginning to separate the MIB into different modules instead
> of one. We'd like to keep it that way if possible.
It's not my preferred choice but it's a valid choice - I don't have a 
big problem with it.

>
>> 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?
> [kiran] Not sure why it would be required?
Here's what I was thinking:
Let's say a row is created via SNMP in the vplsConfigTable. Everything 
the agent knows about that VPLS service is contained in that row. I'm 
assuming the agent will need to be told whether to use BGP or LDP for 
that service.

Perhaps it's a side-effect of whether you created an entry in the 
VplsLdpConfigTable or created one in the vplsBgpConfigTable? Could work 
I guess but it would be good to prohibit situations where neither entry 
is created or both are created (especially the latter). Most important 
would be to define authoritatively how the agent knows. It seemed like 
the other BDP and LDP tables could be empty even if the corresponding 
service was enabled so they wouldn't be good choices.

Thanks,
Steve

>
>
>
>
>
> Thanks
> Kiran
>
>
> On Jul 16, 2013, at 8:02 PM, Steve Waldbusser <[email-masked]> wrote:
>
>> 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: Steve Waldbusser <[email-masked]>
Date: Wed, 14 Aug 2013 22:13:08 -0700

That's exactly what I was thinking (enumerated integer to be more 
exact). And it could be theoretically extended in the future if other 
signalling types are invented.

Steve

On 8/14/2013 4:35 PM, Agrahara Kiran Koushik wrote:
> Thanks for your input Steve.
>
> Do you think adding a new object in the vplsConfigTable to indicate 
> whether BGP or LDP is used for that service
> is sufficient to handle this ambiguity?
>
> Thanks
> Kiran
>
>
>> Let's say a row is created via SNMP in the vplsConfigTable. 
>> Everything the agent knows about that VPLS service is contained in 
>> that row. I'm assuming the agent will need to be told whether to use 
>> BGP or LDP for that service.
>>
>> VplsLdpConfigTable or created one in the vplsBgpConfigTable? Could 
>> work I guess but it would be good to prohibit situations where 
>> neither entry is created or both are created (especially the latter). 
>> Most important would be to define authoritatively how the agent 
>> knows. It seemed like the other BDP and LDP tables could be empty 
>> even if the corresponding service was enabled so they wouldn't be 
>> good choices.
>>
>> Thanks,
>> Steve
>>
>>
>>>
>>>
>>> Thanks
>>> Kiran
>>>
>>>
>>> On Jul 16, 2013, at 8:02 PM, Steve Waldbusser<[email-masked]>  wrote:
>>>
>>>> Hello,
>>>>

---

From: "Giles Heron (giheron)" <[email-masked]>
Date: Thu, 15 Aug 2013 08:23:25 +0000

sounds sensible.

There's also a valid option of having static configuration of the PW labels rather than using LDP or BGP signalling, so the enumerated integer probably needs values for "None", "LDP" and "BGP".

Giles

On 15 Aug 2013, at 06:13, Steve Waldbusser <[email-masked]> wrote:

> That's exactly what I was thinking (enumerated integer to be more exact). And it could be theoretically extended in the future if other signalling types are invented.
> 
> Steve
> 
>> Do you think adding a new object in the vplsConfigTable to indicate whether BGP or LDP is used for that service
>>> Let's say a row is created via SNMP in the vplsConfigTable. Everything the agent knows about that VPLS service is contained in that row. I'm assuming the agent will need to be told whether to use BGP or LDP for that service.
>>> 
>>> Perhaps it's a side-effect of whether you created an entry in the VplsLdpConfigTable or created one in the vplsBgpConfigTable? Could work I guess but it would be good to prohibit situations where neither entry is created or both are created (especially the latter). Most important would be to define authoritatively how the agent knows. It seemed like the other BDP and LDP tables could be empty even if the corresponding service was enabled so they wouldn't be good choices.
>>> 
>>> Thanks,
>>> Steve
>>> 
>>> 
>>>> 
>>>> 
>>>> Thanks
>>>> Kiran
>>>> 
>>>> 
>>>> On Jul 16, 2013, at 8:02 PM, Steve Waldbusser 
>>>> <[email-masked]>
>>>>  wrote:
>>>> 
>>>> 
>>>>> Hello,
>>>>>

---

From: Steve Waldbusser <[email-masked]>
Date: Thu, 15 Aug 2013 13:36:48 -0700

"Other" is a good idea too.

Steve