Re: [Bridge-mib] VLAN-ID
"Les Bell" <Les_Bell@eur.3com.com> Mon, 24 February 2003 10:07 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 FAA06728 for <bridge-archive@odin.ietf.org>; Mon, 24 Feb 2003 05:07:40 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OAG9I13532 for bridge-archive@odin.ietf.org; Mon, 24 Feb 2003 05:16:09 -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 h1OAG5p13525; Mon, 24 Feb 2003 05:16:05 -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 h1OAFjp13494 for <bridge-mib@optimus.ietf.org>; Mon, 24 Feb 2003 05:15:45 -0500
Received: from columba.www.eur.3com.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06712 for <bridge-mib@ietf.org>; Mon, 24 Feb 2003 05:06:44 -0500 (EST)
Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.www.eur.3com.com with ESMTP id h1OACANS018599; Mon, 24 Feb 2003 10:12:11 GMT
Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id h1OAC8Q00293; Mon, 24 Feb 2003 10:12:09 GMT
Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256CD7.00381754 ; Mon, 24 Feb 2003 10:12:39 +0000
X-Lotus-FromDomain: 3COM
From: Les Bell <Les_Bell@eur.3com.com>
To: Randy Presuhn <randy_presuhn@mindspring.com>
cc: bridge-mib@ietf.org, mibs@ops.ietf.org
Message-ID: <80256CD7.00380E6F.00@notesmta.eur.3com.com>
Date: Mon, 24 Feb 2003 10:10:04 +0000
Subject: Re: [Bridge-mib] VLAN-ID
Mime-Version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-Disposition: inline
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>
If the "any" value is to be non-negative, then it should be 4095 (0x0FFF), as suggested by Andrew Smith in an earlier email. This value is reserved by 802.1Q-1998, in Table 9-2, with the following definition: "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." There is a concern that it says "This VID value shall not be ... used in any Management operation ...", but this does not consider the need for a wildcard value. Would everyone be happy to ignore this constraint? Les... "Randy Presuhn" <randy_presuhn@mindspring.com> on 24/02/2003 06:29:58 Sent by: "Randy Presuhn" <randy_presuhn@mindspring.com> To: bridge-mib@ietf.org cc: mibs@ops.ietf.org (Les Bell/GB/3Com) Subject: Re: [Bridge-mib] VLAN-ID Hi - I think it would be better if the "any" value in the *OrAny TC were a non-negative value so that the type could be used to define an index. There may not be a need today, but thinking ahead to representing policy-like things wouldn't hurt. Randy > From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com> > To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>; <bridge-mib@ietf.org> > Cc: <mibs@ops.ietf.org> > Sent: Friday, February 21, 2003 7:15 AM > Subject: RE: [Bridge-mib] VLAN-ID > > Having seen some discussion. How about if we were to define > two generic TCs for this that people will be encouraged to use > from now on: > > > VlanId ::= TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "A 12-bit VLAN ID used in the VLAN Tag header." > SYNTAX Integer32 (1..4094) > REFERENCE "Draft Standard for Virtual Bridged Local Area > Networks, P802.1Q/D10, chapter 3.13 > " > > VlanIdOrAny ::= TEXTUAL CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. > The value of -1 is used to indicate a wildcard, > i.e. any value. > " > SYNTAX Integer32 (-1 | 1..4094) > > Or would the VlanIdOrAny better be represented with > SYNTAX Integer32 (-1 | 1..4094) > where zero represents the wild card ?? > > Not sure if we should include the VlanIndex from RFC2674. I think > it is not as general... but am not sure. If we were to generalize it, > then I would think it should look like: > > VlanIndex ::= TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "A value used to index per-VLAN tables: > - values of 0 and 4095 are not permitted; > - a value between 1 and 4094 inclusive represents > an IEEE 802.1Q VLAN-ID with global scope within > a given bridged domain (see VlanId textual > convention). > - a value greater than 4095 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 include them in > tables in the same way. > " > SYNTAX Unsigned32 (1..4094 | 4096..4294967295) > > Or should we also use an Integer32 for the last one? > Would RFC2674 be the best place to define those? > > If we were to do the above, then > - the framework PIb can keep what they have. At a future revision > they can pick up the TC > - RFC2613 could still advance as is. > I would prefer a new one that uses the new TC, but that new > TC will be in a PS, so that would prohibit advancing to DS. > So we can do that at a later stage. > - RFC2674 gets updated > - docsis MIB probably should pick up new TC, or at least define > their VlanID the same way as proposed in the TC. > > Thanks, > Bert > > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: woensdag 19 februari 2003 18:57 > > 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 _______________________________________________ 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