Subject: Re: draft-nadeau-l2vpn-vpls-mib-01.txt

From: [email-masked]
Date: Wed, 4 Oct 2006 15:39:10 -0400

Thomas,

In reviewing the -01 document, it seems several comments I sent to you on
your initial -00 proposal are not addressed.

I hope these can be accomodated. I believe you agreed with most of them
when they were brought up on this list.

The original comments are below, along with others addressing some new
objects you've added to the updated version:

1.  vplsOperStatus: current values are unknown, up or down. Propose adding
a value 'partialMesh' for the case when one or more PW's in the mesh for
the corresponding VPLS instance have gone down and stayed down. This flags
an important VPLS state to the network manager to help debug network
problems, on which he can mine further information from other MIBs once he
knows it exists.

2.  vplsVpnId: This is shown as read-only. Won't the manager want to
configure VPLS ID? If not here, then where and how is it configured?

3.  vplsServiceType: proposed addition to vplsConfigTable to indicate
whether this is a VLAN or Ethernet VPLS instance.

4.  vplsMeshPeerCount: proposed addition to vplsStatusTable to indicate the
number of Mesh Peers in this VPLS instance.

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

6.  vplsACBindTable: proposed table to bind Attachment Circuits to a VPLS
instance (addresses a question from VJ)

7.  vplsMacLearning, vplsDiscardUnknownDest and vplsMacAging: these are
currently mandatory requirements in the MIB even though they are not part
of the standard itself. Could we please remove them or put them in an
optional group?

8.  vplsConfigFwdFullHighWatermark, vplsConfigFwdFullLowWatermark: These
objects can lead to a storm of SNMP alarms, which is also why we did not
put them in the Bridge MIB. I would propose removing them and, if
necessary, add corresponding counters or events in an optional group.

9.  vplsPwConfigType: There is no autodiscovery method specified by the
VPLS standard. What is the purpose of this object?

10. vplsLdpDraft01MIB: This is a new component. You seem to have given us 2
MIBs for the price of 1. Why not throw those objects into a single VPLS
MIB?

11. vplsLdpMacAddrWithdraw: What's the purpose of this one? MAW is
applicable only for dual homing, which is itself optional. But if
dual-homing is indeed implemented then MAW becomes mandatory, so I don't
understand the reason for this object.

12. vplsLdpPwBindMacAddressLimit: Why put a MAC address limit on a
per-pseudowire basis in the standard MIB? This sure looks like an
implementation issue which could be in an extension. What does it have to
do with LDP?

13. vplsLdpPwBindType: A useful object, but one that ought to be in
vplsPwBindType. A spoke VC (QinQ) does not need LDP signalling.

I can send you the necessary MIB syntax, once we agree on the above.

Regards,
Anil

                    "Thomas D.                                                                                      
                    Nadeau"               To:     [email-masked]                                                    
                    <thomasdnadeau@       cc:     Shane Amante <[email-masked]>, Vach Kompella               
                    gmail.com>             <[email-masked]>, A Kiran Koushik S <[email-masked]>      
                                          Subject:     draft-nadeau-l2vpn-vpls-mib-01.txt                           
                    09/14/2006                                                                                      
                    10:22 AM                                                                                        

           L2VPN WG,

           Kiran and I have worked hard to try to incorporate
all of the comments brought by the WG after we presented
the draft. Many objected to the document being accepted
as a WG draft until these things were incorporated. Now
that most of these comments have been added, we would
like to again ask that the document be accepted as a
L2 VPN WG draft.

           --Tom