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
- RE: [Bridge-mib] VLAN-ID Wijnen, Bert (Bert)
- [Bridge-mib] VLAN-ID Wijnen, Bert (Bert)
- RE: [Bridge-mib] VLAN-ID Romascanu, Dan (Dan)
- RE: [Bridge-mib] VLAN-ID Romascanu, Dan (Dan)
- Re: [Bridge-mib] VLAN-ID Mike MacFaden
- RE: [Bridge-mib] VLAN-ID Andrew Smith
- RE: [Bridge-mib] VLAN-ID Eduardo Cardona
- RE: [Bridge-mib] VLAN-ID Eduardo Cardona
- RE: [Bridge-mib] VLAN-ID Wijnen, Bert (Bert)
- RE: [Bridge-mib] VLAN-ID Les Bell
- Re: [Bridge-mib] VLAN-ID Randy Presuhn
- RE: [Bridge-mib] VLAN-ID Les Bell
- Re: [Bridge-mib] VLAN-ID Les Bell
- RE: [Bridge-mib] VLAN-ID Wijnen, Bert (Bert)
- Re: [Bridge-mib] VLAN-ID Tom Petch
- Re: [Bridge-mib] VLAN-ID Tom Petch