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

["Andrew Smith" <ah_smith@acm.org>]

Les,

It's not a problem unless you make it into one. 

[I'm probably repeating myself from an earlier discussion of this but
...] I believe that the "Management operations" under discussion in
802.1Q Table 9-2 are what are called "layer management" (or is it "local
management"?) operations, accessing manageable objects through a
layer/local management interface ("LMI"). If there is an SNMP or CMIP or
CMOT (or whatever remote management protocol you use) local agent that
is using the LMI, it is the resonsibility of that local agent to
translate the syntax of the remote management operation into appropriate
semantics (an SMIv2 MIB for example, defines how the syntax of the
remote request gets mapped into the semantics of the desired operation).
The local agent then collects whatever information it needs or performs
whatever operations are needed (e.g. by firing off requests via the LMI)
and sends back the result via the remote protocol.

Now it has become commonplace, recently, to regard the local agent as a
transparent passthrough, in effect making the SMIv2 MIB have identical
semantics to the objects visible at the LMI (the ones typically defined
in IEEE 802 documents) but that is *not* how the 802 architecture is
defined.

So, specifically for this example, an SMIv2 syntax for "all VLANs" can
be defined. A "layer" being managed, e.g. an 802.1Q bridge relay entity,
may or may not support an "all VLANs" semantic through its LMI. If it
does, then we're fine - not much work for the local agent to do. If it
does not, the local agent has to map the "all VLANs" semantic onto the
available operations - conceptually that could include sending off
individual LMI operations for each VLAN. 

Of course, implementations are likely to optimise the above scenario but
there's no overriding requirement that the 802.1Q spec needs to be
changed to add an "all VLANs" semantic at the LMI (or at least I've not
seen enough discussion on the 802.1 list to warrant it). There does seem
to be reason to clarify what is meant in 802.1Q Table 9-2 by "management
operation" though.

And, of course, the "correct" solution to this perceived problem is not
to overload the available number-space of VLAN-IDs (a number-space whose
administration is not owned by IETF or any other remote-management
protocol organisation) but to define a separate "wildcard" indicator,
outside of the number-space, in a space that you do control.

Regards,

Andrew


-----Original Message-----
From: owner-mibs@ops.ietf.org [mailto:owner-mibs@ops.ietf.org] On Behalf
Of Les Bell
Sent: Wednesday, October 08, 2003 6:31 AM
To: Kristine Adamson
Cc: mibs@ops.ietf.org
Subject: Re: draft-ietf-ops-vlanid-tc-mib-00.txt





That is the gist of it.  The only problem with the currrent 802.1Q is
the
statement in Table 9-2 which says:

    "FFF    Reserved for implementation use. This VID value shall not be
            configured as a PVID, configured in any Filtering Database
            entry, used in any Management operation, or transmitted in a
            tag header."

The "not be ... used in any Management operation" is the problem.

Les...





Kristine Adamson <adamson@us.ibm.com> on 08/10/2003 13:03:34

Sent by:  Kristine Adamson <adamson@us.ibm.com>


To:   mibs@ops.ietf.org
cc:    (Les Bell/GB/3Com)
Subject:  Re: draft-ietf-ops-vlanid-tc-mib-00.txt









Les,
   So, does the current 802.1Q state that the value 4095 is not a valid
VLAN ID?  And then the update to 802.1Q will state that a VLAN ID value
of
4095 is only for use in SNMP MIBs and it means any VLAN ID value between
1-4094?  Thanks,

Kristine Adamson
IBM Communications Server for MVS: TCP/IP Development
Internet e-mail:adamson@us.ibm.com