Subject: Re: [L2VPN] comments on VPLS MIB

From: [email-masked]
Date: Tue, 25 Jul 2006 14:56:06 -0400

Tom,

The config table as you have it has a couple status objects in
vplsOperStatus and vplsVpnId. Perhaps it can be broken up into status and
config tables? That, or perhaps simply rename it so that it can contain
read-only as well as read-write entries.

Re how to indicate whether it's a partial-mesh pseudowire: as far as I
could gather from Vach's answer, that is not part of the basic VPLS
architecture. This leads me to believe it's a vendor-specific issue, or do
I not understand the issue correctly? One way to deal with this sort of
thing we've used in IETF MIBs I've written in the past is to add an
enumeration of 'other' (I'm pretty sure we did that in RFC1493, Bridge
MIB).

Regards,
Anil

                    "Thomas D.                                                                                     
                    Nadeau"              To:     [email-masked]                                                  
                    <tnadeau@cisco       cc:     [email-masked], "'Shane Amante'" <[email-masked]>          
                    .com>                Subject:     Re: [L2VPN] comments on VPLS MIB                             
                                                                                                                   
                    07/25/2006                                                                                     
                    02:24 PM                                                                                       

On Jul 25, 2006, at 2:28 PM, [email-masked] wrote:

>
> Tom,
>
> In response to your request for specific objects, please see following
> marked "new".
>
> VplsConfigEntry ::=
>   SEQUENCE {
>     vplsIndex                        Unsigned32,
>    -- existing stuff --
>     vplsMeshPeerCount                Counter, -- new
>     vplsSpokePeerCount               Counter, -- new
>     vplsServiceType                  INTEGER, -- new
>     vplsMtu                          Unsigned32, -- new
>     vplsRowStatus                    RowStatus
>     }

           This is the configuration section. Why would we
put status-related objects in this section?

>
> vplsMeshPeerCount OBJECT-TYPE
>     SYNTAX          Counter
>     MAX-ACCESS      read-only
>     STATUS          current
>     DESCRIPTION
>          "This object specifies the number of mesh peers
>          present in this vpls instance."
>     ::= { vplsConfigEntry 12 }
>
> vplsSpokePeerCount OBJECT-TYPE
>     SYNTAX          Counter
>     MAX-ACCESS      read-only
>     STATUS          current
>     DESCRIPTION
>          "This object specifies the number of spoke peers
>          present in this vpls instance."
>     ::= { vplsConfigEntry 13 }
>
> vplsServiceType OBJECT-TYPE
>     SYNTAX          INTEGER {
>                              vlan        (1),
>                              ethernet    (2)
>                      }
>     MAX-ACCESS      read-only
>     STATUS          current
>     DESCRIPTION
>          "This object specifies the type of service being
>          emulated by this vpls instance."
>     ::= { vplsConfigEntry 14 }
>
> vplsMtu OBJECT-TYPE
>     SYNTAX          Unsigned32 (64..1518)
>     MAX-ACCESS      read-create
>     STATUS          current
>     DESCRIPTION
>          "This object specifies the MTU of this vpls instance."
>     DEFVAL          { 1518 }
>     ::= { vplsConfigEntry 15 }
>
>
> VplsPwBindEntry ::=
>     SEQUENCE {
>         vplsPwIndex                     PwIndexType,
>         -- existing stuff --
>         vplsPwType                      INTEGER, -- new
>         vplsPwBindRowStatus             RowStatus
>     }
>
> vplsPwType   OBJECT-TYPE
>      SYNTAX          INTEGER {
>                              mesh  (1),
>                              spoke (2)
>                      }
>      MAX-ACCESS      read-create
>      STATUS          current
>      DESCRIPTION
>           "The value of this object indicates
>            whether the Pseudo Wire is of type mesh or spoke."
>      DEFVAL       { 0 }
>     ::= { vplsPwBindEntry 2 }

           This was originally in one of the MIBs we merged in, but
was removed because it was felt that this was more of a
convenience than anything else.  Also, how do you describe
a partial-mesh?

           --Tom

> Regards,
> Anil

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 25 Jul 2006 15:27:40 -0400

On Jul 25, 2006, at 2:56 PM, [email-masked] wrote:

> vplsOperStatus and vplsVpnId.

	Traditionally Oper and Admin status objects are
together.  I don't see how VpnID is not a configuration
object.

> Perhaps it can be broken up into status and

	Yes.  This is a good idea.

> architecture.

	Agreed; I made this same point in my response to
the meeting minutes last week when I made the case for
leaving it out.
	
> This leads me to believe it's a vendor-specific issue, or do
> I not understand the issue correctly?

	The issue is that it is not formally part of the
protocol specifications, and therefore is in a gray
area. Since this document is supposed to some day be
a WG document, then it would be okay to add such objects
as long as there as WG consensus to do so.

> One way to deal with this sort of

	We could do that. Although 'other' often leads to
interop issues, so I prefer to avoid it if possible.

	--Tom