RE: draft-ietf-ops-vlanid-tc-mib-00.txt

Hi David,

I've updated all the boilerplate text and references, and added the new TCs.
Can I get some suggested text for the usage guidelines for the new TCs?

You mentioned in a previous e-mail that there were some issues on RT, but
I can't find anything there.  Any pointers on where to look?

-Dave

-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Wednesday, October 06, 2004 12:58 AM
To: [email protected]
Cc: [email protected]
Subject: RE: [Bridge-mib] draft-ietf-ops-vlanid-tc-mib-00.txt


Hi Juergen,

Some vendors use 0 as "no vlan" and some use 0 as a wildcard. I believe
other values are used for other local proprietary purposes. There has been
debate about whether the TCs should permit the mib module designer to define
special semantics per object, or whether the values should be standardized. 

I agree some guidelines for usage should be provided.  

Personally, I think it would be good to standardize the local vlan IDs for
use in management, otherwise a manager application would need to know
whether it was a box from vendor-A or vendor-B, or which mib module it is
used in, to understand the semantics and present the info in a user-friendly
manner.

RFC2674bis (draft-ietf-bridge-ext-v2-02.txt) has been a product of this WG,
but the draft expired in August. We expect to have a revision published
before IETF61, possibly with TCs and usage guidelines included.

David Harrington
[email protected]
Bridge-mib co-chair
 
-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email protected]] On Behalf Of
Juergen Schoenwaelder
Sent: Tuesday, October 05, 2004 6:48 PM
To: David B Harrington
Cc: [email protected]
Subject: Re: [Bridge-mib] draft-ietf-ops-vlanid-tc-mib-00.txt

On Thu, Sep 30, 2004 at 08:29:52AM -0400, David B Harrington wrote:
> Hi,
> 
> draft-ietf-ops-vlanid-tc-mib-00.txt has been submitted to for
> publication as an I-D.
> Please review this document and comment.
> 
> If you read it and find nothing to which you strongly object, please

> say so. If you have concerns about the content, or find typos or
> grammar errors, please say so.

In RFC 2674, I read the following:

VlanIndex ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "A value used to index per-VLAN tables: values of 0 and
        4095 are not permitted; if the value is between 1 and
        4094 inclusive, it represents an IEEE 802.1Q VLAN-ID with
        global scope within a given bridged domain (see VlanId
        textual convention).  If the value is greater than 4095
        then it represents a VLAN with scope local to the
        particular agent, i.e. one without a global VLAN-ID
        assigned to it. Such VLANs are outside the scope of
        IEEE 802.1Q but it is convenient to be able to manage them
        in the same way using this MIB."
    SYNTAX      Unsigned32

Note the language about values greater than 4095. The VLAN-ID-MIB defines
things such as:

VlanIdentifier        ::= TEXTUAL-CONVENTION
    DISPLAY-HINT     "d"
    STATUS            current
    DESCRIPTION      "The VLAN ID that uniquely identifies a VLAN.  It
                      is the 12-bit VLAN ID used in the VLAN Tag header.
                      The range is defined by the REFERENCEd specification.
                     "
    REFERENCE        "IEEE Std 802.1Q 2003 Edition, Virtual Bridged
                      Local Area Networks.
                     "
    SYNTAX            Integer32 (1..4094)

I think we need to speel out guidelines in which situations which TC should
be used and why. As it stands, it is kind of confusing for me as an
outsider. How are those local scope VLAN IDs used in practice? (I don't
think they fit into tagged frames.)
 
> Should this be a separate document, or should it be merged into
> rfc2674bis? Please indicate your preference when commenting on the
draft.

Is there actually a plan to revise RFC 2674?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen,
Germany


_______________________________________________
Bridge-mib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/bridge-mib

_______________________________________________
Bridge-mib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/bridge-mib