Re: 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