Subject: Re: Open Issues on: draft-nadeau-l2vpn-vpls-mib

From: [email-masked]
Date: Tue, 7 Nov 2006 12:08:45 -0500

Hi Thomas,

Please see my comments on the issues.

> 1. Should the MIB modules be read-write or read-only?

     Making appropriate objects read-write is the normal practice; concerns
about security can be dealt with by use of SNMPv3, or perhaps in some
situations with communities. A read-only MIB won't be very useful.

> 2. Add number of attachment circuits per VSI.

     Could do, although it's the AC binding table that's the real
requirement here. PWE3 MIB doesn't provide what we need for VPLS, since
VPLS consists of a bunch of PW's as well as bunch of AC's. PWE3 is a
point-to-point configuration.

> 3. Add PwBindTable (contains PWs bound to VSI)

     Don't you already have vplsPwBindTable in there??

> 4. Add VsiPerfTable (contains number of PWs in VSI, numberLearnedMac)

     Sure, could be useful.

> 5. Define vplsOperStatus: current values are unknown, up or down.
> Propose  adding a value 'partialMesh'. Definition of operStatus of
> VSI: 1 or more PW + 1 or more ACs up == OperStatusUp.

     This is a very useful state which can be used by management to track
down network issues. I believe you were asking whether this needs an OAM --
all that's needed here is for software to figure out that underlying
PWs/tunnels are broken, based on already existing mechanisms. It's a bit
like bubbling up interface status to bridge or router port states.

> 6. Proposed addition to vplsStatusTable to indicate the number of
> Mesh Peers in this VPLS instance.

     Just a simple object to tell us how big our VPLS is. A bunch of
get-nexts could accomplish the same thing in a more difficult manner.

> 7. vplsSpokePeerCount: proposed addition to vplsStatusTable to
> indicate the number of Spoke Peers in this VPLS instance.

     This is useful since we don't have much management hooks about the
spokes. Some of which may be QinQ.

> 8. The VPLS LDP Qualified Learning/Unqualified Learning mode on the
> VSI is current read-only.

     Currently, there is no qualified/unqualified learning mode in the MIB,
far as I can see. Its addition, even if read-only, would be useful.

> 9. Get IEEE 802.x objects we must look in the IEEE/IETF Bridge MIB.

     802.x? I don't understand this issue. As the main author of the Bridge
MIB, I'd be able to help map objects in there with this MIB if people feel
that's a useful exercise. You probably also need a "relationship" section
up front to indicate which portions of the Bridge MIB would be expected on
a pseudowire/VPLS logical port basis.

> 10. vplsMacAging/Learning: these  are currently mandatory
> requirements in the MIB even though they are not part of the standard
> itself. Remove them and Rely on IEEE/IETF Bridge MIB or put them in
> an optional group?

     Clearly, I think it's best to leave these optional.

> 11. vplsACBindTable: proposed table to bind Attachment Circuits to  a
> VPLS

     Needed I believe, as mentioned above. There's no other way to
configure local ports into the virtual bridge comprising a VPLS instance.

Regards,
Anil

---

From: Jayanta Tewari <[email-masked]>
Date: Thu, 9 Nov 2006 17:02:34 +0530

Comments inline with JT.
rgds,
--Jayanta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, November 07, 2006 10:39 PM
To: Thomas D. Nadeau
Cc: [email-masked]
Subject: Re: Open Issues on: draft-nadeau-l2vpn-vpls-mib

Hi Thomas,

JT: Was vplsPwBindTable  intended to be meant here ? If that is the
case,this point was not very clear asto it's addition.

Rather the already existing table can be augmented to bring in  general
attributes e.g BindType,MacaddressLimit that are currently present in
vplsLdpPwBindTable and might not be only specific to LDP signalling.This was
discussed in another mail from Shailender.

     Sure, could be useful.

JT:This one should be introduced to get that information.

JT: Won't a new table be useful instead of trying to map with some sections
of Bridge MIB ?

     Clearly, I think it's best to leave these optional.
JT:Keep them as optional.

Regards,
Anil