RE: [Bridge-mib] VLAN-ID
"Romascanu, Dan (Dan)" <dromasca@avaya.com> Wed, 19 February 2003 18:52 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 NAA04771 for <bridge-archive@odin.ietf.org>; Wed, 19 Feb 2003 13:52:14 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JIwQq01490 for bridge-archive@odin.ietf.org; Wed, 19 Feb 2003 13:58:26 -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 h1JIw7p01482; Wed, 19 Feb 2003 13:58:07 -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 h1JIvsp01460 for <bridge-mib@optimus.ietf.org>; Wed, 19 Feb 2003 13:57:54 -0500
Received: from ierw.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04731 for <bridge-mib@ietf.org>; Wed, 19 Feb 2003 13:51:10 -0500 (EST)
Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10431 for <bridge-mib@ietf.org>; Wed, 19 Feb 2003 13:52:24 -0500 (EST)
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10408 for <bridge-mib@ietf.org>; Wed, 19 Feb 2003 13:52:23 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Bridge-mib] VLAN-ID
Date: Wed, 19 Feb 2003 20:54:55 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F03009B37@is0004avexu1.global.avaya.com>
Thread-Topic: [Bridge-mib] VLAN-ID
Thread-Index: AcLYKxCISBVXf79LTvqvcrYKTJivQwAEg3SgAAJPHWAAAHflIA==
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Eduardo Cardona <e.cardona@CableLabs.com>, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, bridge-mib@ietf.org
Cc: mibs@ops.ietf.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JIvsp01461
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: 8bit
That's a similar semantics with the one in the framework PIB. They just picked -1 as their special semantics value, while DOCSIS picked zero. > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: Wednesday, February 19, 2003 8:52 PM > To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); bridge-mib@ietf.org > Cc: mibs@ops.ietf.org > Subject: RE: [Bridge-mib] VLAN-ID > > > Dan, Bert, > > DOCSIS uses the Vlan Mask in a packet classification scheme where the > value zero means the VLAN-ID is not analyzed to match the > tagged packet. > > As operations, The Vlan value is set in the CM config file, > if not used > in the config file, a default value of zero means don't care > > For the DOCS-QOS-MIB > Would be possible to subtype the VlanId TC as > > docsQosPktClassVlanId OBJECT-TYPE > SYNTAX VlanId INTEGER (0..4094) > Or > SYNTAX VlanId INTEGER (0 | 1..4094) > ..... > > Or a new TC zeroOrVlanId > With ; > SYNTAX INTEGER (0 | 1..4094) > > > > Eduardo > > > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Wednesday, February 19, 2003 10:57 AM > To: Wijnen, Bert (Bert); bridge-mib@ietf.org > Cc: mibs@ops.ietf.org > Subject: RE: [Bridge-mib] VLAN-ID > > > Bert, > > I suggest to take the discussion to the mibs list. The interest is > broader than Bridge MIB, as demonstrated by the number of > MIBs that deal > with VLAN ID objects. > > To the point: > - It looks that definitions in > draft-ietf-bridge-ext-v2-01.txt, RFC 2613 > and RFC 2674 (VlanId) are similar. A common TC can be easily > defined, by > taking the RFC 2674 VlanId TC and adding the REFERENCE as in > RFC 2613. > - I do not know what is the reason DOCSIS supports value 0. > - The framework PIB have added a special value -1, with a separate > semantics (ignore VLAN in the filter). > - VlanIndex in RFC2674 also has a different semantics. > > Side issue - if a TC can be easily written and agreed (after some cat > beating) - what will we be doing with documents already on > the standards > track? RFC 2613 is supposed to be advanced from PS to DS 'as is'. You > can buy a beer to the author and have a new document issued, but will > such a change prevent advancement of the document on the > standard track? > If yes, is this really worth? > > Dan > > > > -----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