Re: [Bridge-mib] VLAN-ID

"Tom Petch" <nwnetworks@dial.pipex.com> Mon, 24 February 2003 14:58 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15881 for <bridge-archive@odin.ietf.org>; Mon, 24 Feb 2003 09:58:43 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OF7HI31038 for bridge-archive@odin.ietf.org; Mon, 24 Feb 2003 10:07:17 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OF73p30679; Mon, 24 Feb 2003 10:07:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OF6kp30553 for <bridge-mib@optimus.ietf.org>; Mon, 24 Feb 2003 10:06:46 -0500
Received: from colossus.systems.pipex.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15843 for <bridge-mib@ietf.org>; Mon, 24 Feb 2003 09:57:40 -0500 (EST)
Received: from tom3 (userat04.uk.uudial.com [62.188.137.107]) by colossus.systems.pipex.net (Postfix) with SMTP id 46E211600062E; Mon, 24 Feb 2003 15:01:25 +0000 (GMT)
Message-ID: <01d401c2dc15$4f709f40$0301a8c0@tom3>
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
From: Tom Petch <nwnetworks@dial.pipex.com>
To: Andrew Smith <ah_smith@acm.org>, 'Eduardo Cardona' <e.cardona@CableLabs.com>
Cc: mibs <mibs@ops.ietf.org>, bridge-mib@ietf.org
Subject: Re: [Bridge-mib] VLAN-ID
Date: Mon, 24 Feb 2003 14:31:40 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 7bit
Sender: bridge-mib-admin@ietf.org
Errors-To: bridge-mib-admin@ietf.org
X-BeenThere: bridge-mib@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/bridge-mib>, <mailto:bridge-mib-request@ietf.org?subject=unsubscribe>
List-Id: <bridge-mib.ietf.org>
List-Post: <mailto:bridge-mib@ietf.org>
List-Help: <mailto:bridge-mib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/bridge-mib>, <mailto:bridge-mib-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

As Andrew says, VLAN-ID is defined in IEE Std 802.1Q-1998.  That makes
it an IEEE object and so we should follow the specification of the
IEEE.  I see this as the fundamental principle and anything that goes
against that I would regard as wrong.

Tom Petch
nwnetworks@dial.pipex.com

----Original Message-----
From: Andrew Smith <ah_smith@acm.org>
To: 'Eduardo Cardona' <e.cardona@CableLabs.com>
Cc: mibs@ops.ietf.org <mibs@ops.ietf.org>; bwijnen@lucent.com
<bwijnen@lucent.com>; bridge-mib@ietf.org <bridge-mib@ietf.org>;
'Romascanu, Dan (Dan)' <dromasca@avaya.com>
Date: 19 February 2003 23:46
Subject: RE: [Bridge-mib] VLAN-ID


>Eduardo,
>
>Suggest you refer to the IEEE spec (e.g. IEEE 802.1Q-1998 section
>9.3.2.3 although I think there is a newer draft in progress for which
I
>do not have the exact info). Note that it specifically says there
that
>the VID is an "unsigned binary number" so I don't know why the SYNTAX
>would be INTEGER rather than Unsigned32. Hex FFF (4095, not -1) is
>reserved for "implementation uses" - I would suggest that this is the
>appropriate one to choose for "special semantics". The value 0 is not
>appropriate since you can very validly have packets on the wire
carrying
>0 as the VID and you may very well want to place filters or counters
on
>such packets. At some point, DOCSIS should probably try to align with
>the 802.1Q specification (or else not pretend that it is compatible).
>
>Note also that use of a "mask" on VID values is inappropriate (it
>implies some local manager's allocation policy that is not likely to
be
>universally useful): a list of individual values or a numerical range
>would be more appropriate.
>
>I would suggest that RFC 2613 is wrong not to allow for counting of
>VID=0 packets on the wire by a probe.
>
>Now 802.1Q does also say that the VID values 0 and FFF "shall not be
>used in any management operation" and I'm not entirely sure why we
>included this statement.
>
>To answer Bert's original question, several TCs will be needed to
>capture all of the semantic differences between on-the-wire,
>internal-to-a-bridge and allowed-in-management-operations uses of
this
>VID/VLAN-ID/12-or-more-bit thing. I think that RFC 2674 is consistent
>with 802.1Q and should be the place to start for extracting common
TCs.
>
>Hope that helps,
>
>Andrew Smith
>
<snip>
>>
>> > -----Original Message-----
>> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
>> > Sent: Wednesday, February 19, 2003 5:14 PM
>> > To: bridge-mib@ietf.org
>> > Subject: [Bridge-mib] VLAN-ID
>> >
>> >
>> > Bridgemibbers....
>> >
>> > I do not see much (if any activity lately) :-(
>> >
>> > But I have a question.
>> >
>> > I see a VLAN ID represented in various forms:
>> >
>> > - draft-ietf-bridge-ext-v2-01.txt
>> >     VlanId ::= TEXTUAL-CONVENTION
>> >        STATUS      current
>> >        DESCRIPTION "A 12-bit VLAN ID used in the VLAN Tag
header."
>> >        SYNTAX      INTEGER (1..4094)
>> > - somehwere I found:
>> >     dot1vProtocolPortGroupVid OBJECT-TYPE
>> >        SYNTAX      INTEGER (1..4094)
>> >        MAX-ACCESS  read-create
>> >        STATUS      current
>> >        DESCRIPTION "The VID associated with a group of protocols
for
>> >                     each port."
>> >        REFERENCE   "IEEE 802.1v clause 8.4.4, 12.10.1.2"
>> >
>> > - In a DOCSIS document I find:
>> >     docsQosPktClassVlanId OBJECT-TYPE
>> >        SYNTAX          Integer32 (0..4095)
>> >        MAX-ACCESS      read-only
>> >        STATUS          current
>> >
>> > - In the framework PIB (draft-ietf-rap-frameworkpib-09.txt) I
find:
>> >
>> >   frwk802FilterVlanId OBJECT-TYPE
>> >       SYNTAX         Integer32 (-1 | 1..4094)
>> >       STATUS         current
>> >       DESCRIPTION
>> >           "The VLAN ID (VID) that uniquely identifies a VLAN
>> >           within the device. This VLAN may be known or unknown
>> >           (i.e., traffic associated with this VID has not yet
>> >           been seen by the device) at the time this entry
>> >           is instantiated.
>> >
>> >           Setting the frwk802FilterVlanId object to -1
>> indicates that
>> >           VLAN data should not be considered during traffic
>> >           classification."
>> >
>> > - In rfc2613 I find:
>> >    smonVlanIdStatsId OBJECT-TYPE
>> >     SYNTAX     Integer32 (1..4094)
>> >     MAX-ACCESS not-accessible
>> >     STATUS     current
>> >     DESCRIPTION
>> >         "The unique identifier of the VLAN monitored for
>> >          this specific statistics collection.
>> >
>> >         Tagged packets match the VID for the range between
>> 1 and 4094.
>> >         An external RMON probe MAY detect VID=0 on an Inter
Switch
>> >         Link, in which case the packet belongs to a VLAN
>> determined by
>> >         the PVID of the ingress port. The VLAN to which
>> such a packet
>> >         belongs can be determined only by a RMON probe
>> internal to the
>> >         switch."
>> >     REFERENCE
>> >         "Draft Standard for Virtual Bridged Local Area Networks,
>> >           P802.1Q/D10, chapter 3.13"
>> >
>> > - In RFC2674 I find:
>> >   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
>> >
>> > - IN RFC2674 I also find
>> >    VlanId ::= TEXTUAL-CONVENTION
>> >       STATUS      current
>> >       DESCRIPTION
>> >           "A 12-bit VLAN ID used in the VLAN Tag header."
>> >       SYNTAX      INTEGER (1..4094)
>> >
>> > Not sure I found all occurances.
>> >
>> > So my question is: what is the CORRECT spec, and could we try to
>> > define one (or a few)  TC(s) that everyone else can IMPORT and
use.
>> >
>> > Bert
>> > _______________________________________________
>> > Bridge-mib mailing list
>> > Bridge-mib@ietf.org
>https://www1.ietf.org/mailman/listinfo/bridge-mib
>


_______________________________________________
Bridge-mib mailing list
Bridge-mib@ietf.org
https://www1.ietf.org/mailman/listinfo/bridge-mib