From mailnull@www1.ietf.org Wed Feb 12 09:20:57 2003 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 JAA03266 for ; Wed, 12 Feb 2003 09:20:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1CEUMh19051 for bridge-archive@odin.ietf.org; Wed, 12 Feb 2003 09:30:22 -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 h1CEUEp19040; Wed, 12 Feb 2003 09:30:14 -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 h1CETJp19000 for ; Wed, 12 Feb 2003 09:29:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03134; Wed, 12 Feb 2003 09:19:23 -0500 (EST) Message-Id: <200302121419.JAA03134@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: bridge-mib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 12 Feb 2003 09:19:23 -0500 Subject: [Bridge-mib] I-D ACTION:draft-ietf-bridge-8021x-01.txt 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: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bridge MIB Working Group of the IETF. Title : Definitions for Port Access Control (IEEE 802.1X) MIB Author(s) : K. Norseth Filename : draft-ietf-bridge-8021x-01.txt Pages : 41 Date : 2003-2-11 This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the operation of Port Access Control, based on the specification contained in Clause 8 and Clause 9 of the IEEE 802.1X standard. This clause includes a MIB module that is SNMPv2 SMI compliant. This standard defines a mechanism for Port-based network access control that makes use of the physical access characteristics of IEEE 802 LAN infrastructures in order to provide a means of authenticating and authorizing devices attached to a LAN port that has point-to-point connection characteristics, and of preventing access to that port in cases in which the authentication and A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bridge-8021x-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bridge-8021x-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bridge-8021x-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-11140943.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bridge-8021x-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bridge-8021x-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-11140943.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From mailnull@www1.ietf.org Wed Feb 19 10:12:29 2003 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 KAA27630 for ; Wed, 19 Feb 2003 10:12:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JFIbn18090 for bridge-archive@odin.ietf.org; Wed, 19 Feb 2003 10:18:37 -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 h1JFITp18071; Wed, 19 Feb 2003 10:18:29 -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 h1JFH8p17933 for ; Wed, 19 Feb 2003 10:17:08 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27548 for ; Wed, 19 Feb 2003 10:10:29 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1JFECc23423 for ; Wed, 19 Feb 2003 10:14:13 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 16:14:12 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155F7C06C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: bridge-mib@ietf.org Date: Wed, 19 Feb 2003 16:14:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Bridge-mib] VLAN-ID 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: , List-Id: List-Post: List-Help: List-Subscribe: , 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 From mailnull@www1.ietf.org Wed Feb 19 12:54:30 2003 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 MAA03106 for ; Wed, 19 Feb 2003 12:54:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JI0eH30389 for bridge-archive@odin.ietf.org; Wed, 19 Feb 2003 13:00:40 -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 h1JI0Ap30373; Wed, 19 Feb 2003 13:00:10 -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 h1JHxmp30327 for ; Wed, 19 Feb 2003 12:59:48 -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 MAA03076 for ; Wed, 19 Feb 2003 12:53:04 -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 MAA16294 for ; Wed, 19 Feb 2003 12:54:18 -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 MAA16259 for ; Wed, 19 Feb 2003 12:54:17 -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 19:56:49 +0200 Message-ID: Thread-Topic: [Bridge-mib] VLAN-ID Thread-Index: AcLYKxCISBVXf79LTvqvcrYKTJivQwAEg3Sg From: "Romascanu, Dan (Dan)" To: "Wijnen, Bert (Bert)" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JHxmp30328 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: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit 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 From mailnull@www1.ietf.org Wed Feb 19 13:52:14 2003 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 ; 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 ; 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 ; 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 ; 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 ; 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: Thread-Topic: [Bridge-mib] VLAN-ID Thread-Index: AcLYKxCISBVXf79LTvqvcrYKTJivQwAEg3SgAAJPHWAAAHflIA== From: "Romascanu, Dan (Dan)" To: "Eduardo Cardona" , "Wijnen, Bert (Bert)" , Cc: 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: , List-Id: List-Post: List-Help: List-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 From mailnull@www1.ietf.org Wed Feb 19 14:27:58 2003 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 OAA05951 for ; Wed, 19 Feb 2003 14:27:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JJYAv04101 for bridge-archive@odin.ietf.org; Wed, 19 Feb 2003 14:34:10 -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 h1JJY5p04094; Wed, 19 Feb 2003 14:34: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 h1JJXwp04065 for ; Wed, 19 Feb 2003 14:33:58 -0500 Received: from mordor.riverstonenet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05931 for ; Wed, 19 Feb 2003 14:27:14 -0500 (EST) Received: (qmail 7750 invoked by uid 10041); 19 Feb 2003 19:31:03 -0000 Date: Wed, 19 Feb 2003 11:31:03 -0800 From: Mike MacFaden To: "Wijnen, Bert \(Bert\)" Cc: bridge-mib@ietf.org Subject: Re: [Bridge-mib] VLAN-ID Message-ID: <20030219113103.T5475@riverstonenet.com> References: <7D5D48D2CAA3D84C813F5B154F43B155F7C06C@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155F7C06C@nl0006exch001u.nl.lucent.com>; from bwijnen@lucent.com on Wed, Feb 19, 2003 at 04:14:04PM +0100 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: , List-Id: List-Post: List-Help: List-Subscribe: , On Wed, Feb 19, 2003 at 04:14:04PM +0100, Wijnen, Bert (Bert) wrote: >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. I prefer the two TCs in 2674 as being most definitive. This mib module has support for both public vlans 1-4094 and private vlans (4097 and up). Unfortunately not having a value for unknown/invalid is disappointing (might have used 0 or 4095 for this?). Regards, Mike MacFaden _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From mailnull@www1.ietf.org Thu Feb 20 04:15:10 2003 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 EAA04953 for ; Thu, 20 Feb 2003 04:15:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K9Lew29489 for bridge-archive@odin.ietf.org; Thu, 20 Feb 2003 04:21:40 -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 h1K9LKp29449; Thu, 20 Feb 2003 04:21:20 -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 h1JJWWp03944 for ; Wed, 19 Feb 2003 14:32:32 -0500 Received: from swan.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05854 for ; Wed, 19 Feb 2003 14:25:48 -0500 (EST) Received: from user-vcaunrd.dsl.mindspring.com ([216.175.95.109] helo=ANDREWLAPTOP) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18lZuR-0000u0-00; Wed, 19 Feb 2003 11:29:36 -0800 From: "Andrew Smith" To: "'Eduardo Cardona'" Cc: , , , "'Romascanu, Dan \(Dan\)'" Subject: RE: [Bridge-mib] VLAN-ID Date: Wed, 19 Feb 2003 11:29:22 -0800 Message-ID: <01be01c2d84d$38574500$1500000a@ANDREWLAPTOP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit 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 -----Original Message----- From: owner-mibs@ops.ietf.org [mailto:owner-mibs@ops.ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Wednesday, February 19, 2003 10:55 AM To: Eduardo Cardona; Wijnen, Bert (Bert); bridge-mib@ietf.org Cc: mibs@ops.ietf.org Subject: RE: [Bridge-mib] VLAN-ID 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 From mailnull@www1.ietf.org Thu Feb 20 04:15:15 2003 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 EAA04966 for ; Thu, 20 Feb 2003 04:15:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K9Lik29502 for bridge-archive@odin.ietf.org; Thu, 20 Feb 2003 04:21:44 -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 h1K9LJp29434; Thu, 20 Feb 2003 04:21:19 -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 h1JItDp01384 for ; Wed, 19 Feb 2003 13:55:13 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04657 for ; Wed, 19 Feb 2003 13:48:28 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h1JIqCwH015191; Wed, 19 Feb 2003 11:52:12 -0700 (MST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Bridge-mib] VLAN-ID X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 19 Feb 2003 11:52:12 -0700 Message-ID: Thread-Topic: [Bridge-mib] VLAN-ID Thread-Index: AcLYKxCISBVXf79LTvqvcrYKTJivQwAEg3SgAAJPHWA= From: "Eduardo Cardona" To: "Romascanu, Dan (Dan)" , "Wijnen, Bert (Bert)" , Cc: X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JItDp01385 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: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit 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 From mailnull@www1.ietf.org Thu Feb 20 04:15:16 2003 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 EAA04979 for ; Thu, 20 Feb 2003 04:15:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K9LkT29515 for bridge-archive@odin.ietf.org; Thu, 20 Feb 2003 04:21:46 -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 h1K9LLp29464; Thu, 20 Feb 2003 04:21:21 -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 h1JKA1p07080 for ; Wed, 19 Feb 2003 15:10:01 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07175 for ; Wed, 19 Feb 2003 15:03:15 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.6/8.12.6) with ESMTP id h1JK70wH017393; Wed, 19 Feb 2003 13:07:01 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Bridge-mib] VLAN-ID Date: Wed, 19 Feb 2003 13:07:00 -0700 Message-ID: Thread-Topic: [Bridge-mib] VLAN-ID Thread-Index: AcLYTUJ/DBPO+/PTS9S2H/MRBplauAAAFZkA From: "Eduardo Cardona" To: "Andrew Smith" Cc: , , , "Romascanu, Dan (Dan)" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JKA1p07081 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: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Thanks Andrew and Dan, One clarification, by mistake I say MASK but it really is VlanId For what I see, a packet tagged 0 could potentially be filtered, Even though, current DOCSIS requirements are in the range 0..4095, a syntax change will be needed :Integer32 (INTEGER) to Unsigned32 Also, unfortunately the DESCRIPTION is tied to 0 as the "implementation uses" of not using as a matching filters criteria for compatibility reasons. For now, a note referencing the documents inconsistencies would be needed with an internal discussion inside ipcdn. In the mean time, if the bridge-mib group can normalize the TC based on RFC 2674 and give us the guidelines for that would be appreciated. Thanks Eduardo -----Original Message----- From: Andrew Smith [mailto:ah_smith@acm.org] Sent: Wednesday, February 19, 2003 12:29 PM To: Eduardo Cardona Cc: mibs@ops.ietf.org; bwijnen@lucent.com; bridge-mib@ietf.org; 'Romascanu, Dan (Dan)' 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 -----Original Message----- From: owner-mibs@ops.ietf.org [mailto:owner-mibs@ops.ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Wednesday, February 19, 2003 10:55 AM To: Eduardo Cardona; Wijnen, Bert (Bert); bridge-mib@ietf.org Cc: mibs@ops.ietf.org Subject: RE: [Bridge-mib] VLAN-ID 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 From mailnull@www1.ietf.org Fri Feb 21 10:17:11 2003 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 KAA03017 for ; Fri, 21 Feb 2003 10:17:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LFOHL30052 for bridge-archive@odin.ietf.org; Fri, 21 Feb 2003 10:24: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 h1LFO9p30029; Fri, 21 Feb 2003 10:24:09 -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 h1LFJVp29827 for ; Fri, 21 Feb 2003 10:19:31 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02839 for ; Fri, 21 Feb 2003 10:11:53 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1LFFhM24292 for ; Fri, 21 Feb 2003 10:15:43 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Feb 2003 16:15:39 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155F7C51F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Romascanu, Dan (Dan)" , bridge-mib@ietf.org Cc: mibs@ops.ietf.org Subject: RE: [Bridge-mib] VLAN-ID Date: Fri, 21 Feb 2003 16:15:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , List-Id: List-Post: List-Help: List-Subscribe: , 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 From mailnull@www1.ietf.org Fri Feb 21 11:43:11 2003 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 LAA06251 for ; Fri, 21 Feb 2003 11:43:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LGoJ103876 for bridge-archive@odin.ietf.org; Fri, 21 Feb 2003 11:50:19 -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 h1LGoBp03867; Fri, 21 Feb 2003 11:50:11 -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 h1LGnvp03843 for ; Fri, 21 Feb 2003 11:49:57 -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 LAA06212 for ; Fri, 21 Feb 2003 11:42:17 -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 h1LGlfNS009440; Fri, 21 Feb 2003 16:47:41 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id h1LGlWQ09820; Fri, 21 Feb 2003 16:47:32 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256CD4.005C4810 ; Fri, 21 Feb 2003 16:47:57 +0000 X-Lotus-FromDomain: 3COM From: "Les Bell" To: "Wijnen, Bert (Bert)" cc: "Romascanu, Dan (Dan)" , bridge-mib@ietf.org, mibs@ops.ietf.org Message-ID: <80256CD4.005C45AA.00@notesmta.eur.3com.com> Date: Fri, 21 Feb 2003 16:45:46 +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: , List-Id: List-Post: List-Help: List-Subscribe: , We should not use the value 0 to indicate "any" VLAN, as this may be used by 802.1D Bridges that support Priority Tagging, but do not support 802.1Q VLANs. There is a draft revision of RFC 2674 currently out (which I believe is ready for WG last call, except for editorial issues). We could revise the VlanId and VlanIndex TCs and add VlanIdOrAny, as you have described below, before we do the last call. RFC 2674 uses VlanIndex itself, so we have to keep it. The SYNTAX in the definitions for VlanId and VlanIndex differ slightly from what is currently defined in RFC 2674. Is this going to cause any problems? Les... "Wijnen, Bert (Bert)" on 21/02/2003 15:15:37 Sent by: "Wijnen, Bert (Bert)" To: "Romascanu, Dan , bridge-mib@ietf.org cc: mibs@ops.ietf.org (Les Bell/GB/3Com) 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 From mailnull@www1.ietf.org Fri Feb 21 14:13:03 2003 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 OAA11623 for ; Fri, 21 Feb 2003 14:13:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LJKEh14044 for bridge-archive@odin.ietf.org; Fri, 21 Feb 2003 14:20:14 -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 h1LJK7p14037; Fri, 21 Feb 2003 14:20: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 h1LJJfp13984 for ; Fri, 21 Feb 2003 14:19:41 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11597 for ; Fri, 21 Feb 2003 14:11:56 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1LJFkf10560 for ; Fri, 21 Feb 2003 14:15:47 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Feb 2003 20:15:45 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155F7C59D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Les Bell Cc: "Romascanu, Dan (Dan)" , bridge-mib@ietf.org, mibs@ops.ietf.org Subject: RE: [Bridge-mib] VLAN-ID Date: Fri, 21 Feb 2003 20:15:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , List-Id: List-Post: List-Help: List-Subscribe: , Inline > -----Original Message----- > From: Les Bell [mailto:Les_Bell@eur.3com.com] > Sent: vrijdag 21 februari 2003 17:46 > To: Wijnen, Bert (Bert) > Cc: Romascanu, Dan (Dan); bridge-mib@ietf.org; mibs@ops.ietf.org > Subject: RE: [Bridge-mib] VLAN-ID > > We should not use the value 0 to indicate "any" VLAN, as this > may be used by 802.1D Bridges that support Priority Tagging, > but do not support 802.1Q VLANs. > Ok, thanks for the update, So the framework PIB is doing it better than the docsis documents were trying to do. > There is a draft revision of RFC 2674 currently out (which I > believe is ready for WG last call, except for editorial issues). Which document is that? > We could revise the VlanId and VlanIndex TCs and add VlanIdOrAny, > as you have described below, before we do the last call. > RFC 2674 uses VlanIndex itself, so we have to keep it. > > The SYNTAX in the definitions for VlanId and VlanIndex differ > slightly from what is currently defined in RFC 2674. > Is this going to cause any problems? > Whell, the VlanID SYNTAX is exactly the same in that on the wire they look the same, and a Interger32 with the same range as an INTEGER is (in my view) exactly the same, no? The VlanIndex is only different in the sense that I have made the unallowed values (0 and 4095 are not allowed) machine readable by specifying a range. So in practice, I think the semantics have not changed. Bert > Les... > > > > > > "Wijnen, Bert (Bert)" on 21/02/2003 15:15:37 > > Sent by: "Wijnen, Bert (Bert)" > > > To: "Romascanu, Dan , bridge-mib@ietf.org > cc: mibs@ops.ietf.org (Les Bell/GB/3Com) > 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 From mailnull@www1.ietf.org Mon Feb 24 01:25:15 2003 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 BAA22547 for ; Mon, 24 Feb 2003 01:25:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O6Xc921764 for bridge-archive@odin.ietf.org; Mon, 24 Feb 2003 01:33:38 -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 h1O6XLp21739; Mon, 24 Feb 2003 01:33:21 -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 h1O6Wbp21702 for ; Mon, 24 Feb 2003 01:32:37 -0500 Received: from scaup.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22528 for ; Mon, 24 Feb 2003 01:23:42 -0500 (EST) Received: from h-68-164-78-252.snvacaid.covad.net ([68.164.78.252] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18nC5N-0000yv-00; Sun, 23 Feb 2003 22:27:33 -0800 Message-ID: <00e801c2dbce$271aaa00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: References: <7D5D48D2CAA3D84C813F5B154F43B155F7C51F@nl0006exch001u.nl.lucent.com> Subject: Re: [Bridge-mib] VLAN-ID Date: Sun, 23 Feb 2003 22:29:58 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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: , List-Id: List-Post: List-Help: List-Subscribe: , 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)" > To: "Romascanu, Dan (Dan)" ; > Cc: > 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 From mailnull@www1.ietf.org Mon Feb 24 04:34:44 2003 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 EAA05942 for ; Mon, 24 Feb 2003 04:34:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O9hCh11640 for bridge-archive@odin.ietf.org; Mon, 24 Feb 2003 04:43:12 -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 h1O9h6p11631; Mon, 24 Feb 2003 04:43:06 -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 h1O9gWp11607 for ; Mon, 24 Feb 2003 04:42:32 -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 EAA05911 for ; Mon, 24 Feb 2003 04:33:32 -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 h1O9cwNS015447; Mon, 24 Feb 2003 09:38:59 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id h1O9cvQ25962; Mon, 24 Feb 2003 09:38:57 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256CD7.00350D22 ; Mon, 24 Feb 2003 09:39:27 +0000 X-Lotus-FromDomain: 3COM From: "Les Bell" To: "Wijnen, Bert (Bert)" cc: bridge-mib@ietf.org, mibs@ops.ietf.org Message-ID: <80256CD7.0034FCA2.00@notesmta.eur.3com.com> Date: Mon, 24 Feb 2003 09:36:27 +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: , List-Id: List-Post: List-Help: List-Subscribe: , On 21 Feb 2003, 19:15 Bert Wijnen said: > > There is a draft revision of RFC 2674 currently out (which I > > believe is ready for WG last call, except for editorial issues). > > Which document is that? http://www.ietf.org/internet-drafts/draft-ietf-bridge-ext-v2-01.txt This expires soon, I am waiting for the editor to submit a new version. Les... _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From mailnull@www1.ietf.org Mon Feb 24 05:07:40 2003 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 ; 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 ; 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 ; 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" To: "Randy Presuhn" 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: , List-Id: List-Post: List-Help: List-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" on 24/02/2003 06:29:58 Sent by: "Randy Presuhn" 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)" > To: "Romascanu, Dan (Dan)" ; > Cc: > 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 From mailnull@www1.ietf.org Mon Feb 24 09:24:42 2003 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 JAA15192 for ; Mon, 24 Feb 2003 09:24:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OEXGI28356 for bridge-archive@odin.ietf.org; Mon, 24 Feb 2003 09:33:16 -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 h1OEX8p28340; Mon, 24 Feb 2003 09:33:08 -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 h1OEWep28320 for ; Mon, 24 Feb 2003 09:32:40 -0500 Received: from ihemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15184 for ; Mon, 24 Feb 2003 09:23:34 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1OERRH03870 for ; Mon, 24 Feb 2003 09:27:27 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Feb 2003 15:27:21 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155F7C8D2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Les Bell , Randy Presuhn Cc: bridge-mib@ietf.org, mibs@ops.ietf.org Subject: RE: [Bridge-mib] VLAN-ID Date: Mon, 24 Feb 2003 15:27:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , List-Id: List-Post: List-Help: List-Subscribe: , Well, I hope we could decide on this pretty soon. The Diffserv (actually framework) PIB is currently using a minus 1 for OrAny. I'd like to get them lined up for whatever we may decide is the best value. If we want to consider 4095 as the value for Any, is that now somethingw e should check with the 802.1 community in IEEE ?? Thanks, Bert > -----Original Message----- > From: Les Bell [mailto:Les_Bell@eur.3com.com] > Sent: maandag 24 februari 2003 11:10 > To: Randy Presuhn > Cc: bridge-mib@ietf.org; mibs@ops.ietf.org > Subject: Re: [Bridge-mib] VLAN-ID > > > > > > 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" on 24/02/2003 06:29:58 > > Sent by: "Randy Presuhn" > > > 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)" > > To: "Romascanu, Dan (Dan)" ; > > > Cc: > > 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 From mailnull@www1.ietf.org Mon Feb 24 09:58:43 2003 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 ; 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 ; 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 ; 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" From: "Tom Petch" To: "Andrew Smith" , "'Eduardo Cardona'" Cc: "mibs" , 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: , List-Id: List-Post: List-Help: List-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 To: 'Eduardo Cardona' Cc: mibs@ops.ietf.org ; bwijnen@lucent.com ; bridge-mib@ietf.org ; 'Romascanu, Dan (Dan)' 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 > >> >> > -----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 From mailnull@www1.ietf.org Mon Feb 24 14:54:31 2003 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 OAA24311 for ; Mon, 24 Feb 2003 14:54:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OK3AG18966 for bridge-archive@odin.ietf.org; Mon, 24 Feb 2003 15:03:10 -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 h1OK35p18959; Mon, 24 Feb 2003 15:03: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 h1OK2mp18937 for ; Mon, 24 Feb 2003 15:02:48 -0500 Received: from pengo.systems.pipex.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24282 for ; Mon, 24 Feb 2003 14:53:35 -0500 (EST) Received: from tom3 (useram84.uk.uudial.com [62.188.135.2]) by pengo.systems.pipex.net (Postfix) with SMTP id 3EA644C00360; Mon, 24 Feb 2003 19:57:24 +0000 (GMT) Message-ID: <000801c2dc3e$a624ae20$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Les Bell" Cc: , "mibs" Subject: Re: [Bridge-mib] VLAN-ID Date: Mon, 24 Feb 2003 19:54:09 -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: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Nope, not happy to ignore the IEEE's constraint. If the IEEE reserve a value for their object, we should do the same. Who knows what a Cisco or 3Com implementation might do with it that we may wish later to model. (More generally, it was bad programming in the 1970s to 'borrow' a value from a range that was not used at that moment in order to convey some additional semantic, like invalid or escape; it was bad database design to do that in the 1980s and by then we had formal methods to tell us it was bad; it remains bad MIB design to do it now with SNMP). Likewise, IEEE define this as unsigned so making it an Integer32 I regard as wrong. And that reference; are we basing this on the draft work in progress of the IEEE, to which noone on these lists has yet admitted having access, or on the published, 801.1Q 1998 standard (which I have in front of me)? We should, by liaising with the IEEE if no other means, find out if the work in progress changes this part of the specification. Tom Petch nwnetworks@dial.pipex.com -----Original Message----- From: Les Bell To: Randy Presuhn Cc: bridge-mib@ietf.org ; mibs@ops.ietf.org Date: 24 February 2003 10:14 Subject: Re: [Bridge-mib] VLAN-ID > >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" on 24/02/2003 06:29:58 > >Sent by: "Randy Presuhn" > >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)" >> To: "Romascanu, Dan (Dan)" ; >> Cc: >> 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 From mailnull@www1.ietf.org Wed Feb 26 19:38:37 2003 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 TAA03948 for ; Wed, 26 Feb 2003 19:38:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1R0mMQ25699 for bridge-archive@odin.ietf.org; Wed, 26 Feb 2003 19:48:22 -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 h1R0mIp25692; Wed, 26 Feb 2003 19:48:18 -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 h1R0lcp25660 for ; Wed, 26 Feb 2003 19:47:38 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03929 for ; Wed, 26 Feb 2003 19:37:21 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1R0fHp29483 for ; Wed, 26 Feb 2003 19:41:17 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 01:41:16 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501062D84@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Bridge-Mib (E-mail)" Cc: Rohit.Rohit@worldwidepackets.com Date: Thu, 27 Feb 2003 01:41:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Bridge-mib] FW: ieee8023-lag-mib : dot3adAggActorSystemPriority and dot3adAgg PortActorSystemPriority definition 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: , List-Id: List-Post: List-Help: List-Subscribe: , Does this actually better belong on the bridgmib mailing list? Thanks, Bert -----Original Message----- From: Rohit Rohit [mailto:Rohit.Rohit@worldwidepackets.com] Sent: woensdag 26 februari 2003 23:55 To: mibs@ops.ietf.org Subject: ieee8023-lag-mib : dot3adAggActorSystemPriority and dot3adAggPortActorSystemPriority definition Hi, I am not sure if this is the right group for this question; but mail to 'stds-802-3-trunking@majordomo.ieee.org' does not seem to work. I see the following inconsistency between the dot3adAggActorSystemPriority and dot3adAggPortActorSystemPriority. dot3adAggPortActorSystemPriority is defined to be 2 octets; but its range is only from 0 to 255. ( IMHO, it should be 0 .. 65535 ). > dot3adAggPortActorSystemPriority OBJECT-TYPE > SYNTAX INTEGER (0..255) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A 2-octet read-write value used to define the priority > value associated with the Actor's System ID." > REFERENCE > "IEEE 802.3 Subclause 30.7.2.1.2" > ::= { dot3adAggPortEntry 2 } while dot3adAggActorSystemPriority is also defined to be 2 octets; but its range is from 0..65535. Any reason for this inconsistency ? > dot3adAggActorSystemPriority OBJECT-TYPE > SYNTAX INTEGER (0..65535) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A 2-octet read-write value indicating the priority > value associated with the Actor's System ID." > REFERENCE > "IEEE 802.3 Subclause 30.7.1.1.5" > ::= { dot3adAggEntry 3 } Thanks Rohit _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From mailnull@www1.ietf.org Thu Feb 27 11:14:11 2003 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 LAA09825 for ; Thu, 27 Feb 2003 11:14:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RGOE431548 for bridge-archive@odin.ietf.org; Thu, 27 Feb 2003 11:24:14 -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 h1RGO9p31541; Thu, 27 Feb 2003 11:24:09 -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 h1RGNep31512 for ; Thu, 27 Feb 2003 11:23:40 -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 LAA09817 for ; Thu, 27 Feb 2003 11:13:05 -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 h1RGIZNS026908; Thu, 27 Feb 2003 16:18:35 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id h1RGIXQ11570; Thu, 27 Feb 2003 16:18:33 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256CDA.0059A3DC ; Thu, 27 Feb 2003 16:19:06 +0000 X-Lotus-FromDomain: 3COM From: "Les Bell" To: "Rohit Rohit" cc: mibs@ops.ietf.org, Bridge-mib@ietf.org, "David Law" Message-ID: <80256CDA.0059A23C.00@notesmta.eur.3com.com> Date: Thu, 27 Feb 2003 16:16:45 +0000 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Bridge-mib] Re: ieee8023-lag-mib : dot3adAggActorSystemPriority and dot3adAggPortActorSystemPriority definition 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: , List-Id: List-Post: List-Help: List-Subscribe: , This is a known bug in the MIB and a fix should appear in the next revision of the 802.3 spec. There are a number of similar objects with the same bug. The range should be (0..65535) on all of them. The proposed fix is to deprecate these objects and replace them with corrected equivalents. There are some other fixes pending also. Les... "Rohit Rohit" on 26/02/2003 22:55:29 Sent by: "Rohit Rohit" To: mibs@ops.ietf.org cc: (Les Bell/GB/3Com) Subject: ieee8023-lag-mib : dot3adAggActorSystemPriority and dot3adAggPortActorSystemPriority definition Hi, I am not sure if this is the right group for this question; but mail to 'stds-802-3-trunking@majordomo.ieee.org' does not seem to work. I see the following inconsistency between the dot3adAggActorSystemPriority and dot3adAggPortActorSystemPriority. dot3adAggPortActorSystemPriority is defined to be 2 octets; but its range is only from 0 to 255. ( IMHO, it should be 0 .. 65535 ). > dot3adAggPortActorSystemPriority OBJECT-TYPE > SYNTAX INTEGER (0..255) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A 2-octet read-write value used to define the priority > value associated with the Actor's System ID." > REFERENCE > "IEEE 802.3 Subclause 30.7.2.1.2" > ::= { dot3adAggPortEntry 2 } while dot3adAggActorSystemPriority is also defined to be 2 octets; but its range is from 0..65535. Any reason for this inconsistency ? > dot3adAggActorSystemPriority OBJECT-TYPE > SYNTAX INTEGER (0..65535) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A 2-octet read-write value indicating the priority > value associated with the Actor's System ID." > REFERENCE > "IEEE 802.3 Subclause 30.7.1.1.5" > ::= { dot3adAggEntry 3 } Thanks Rohit _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From mailnull@www1.ietf.org Thu Feb 27 11:33:11 2003 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 LAA10445 for ; Thu, 27 Feb 2003 11:33:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RGhEq00726 for bridge-archive@odin.ietf.org; Thu, 27 Feb 2003 11:43:14 -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 h1RGh4p00704; Thu, 27 Feb 2003 11:43:04 -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 h1RGgbp00673 for ; Thu, 27 Feb 2003 11:42:37 -0500 Received: from auemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10416 for ; Thu, 27 Feb 2003 11:32:02 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1RGZum14190 for ; Thu, 27 Feb 2003 11:35:57 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 17:35:55 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501062FA1@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Randy Presuhn (E-mail)" Cc: "Bridge-Mib (E-mail)" , mibs@ops.ietf.org Date: Thu, 27 Feb 2003 17:35:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Bridge-mib] VLAn ID 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: , List-Id: List-Post: List-Help: List-Subscribe: , Randy, you wrote: >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. > As far as I can tell, you seem to be the only one sofar who has spoken up on the idea of not having a negative value for the "any" for the VlanIdOrAny TC that I proposed. You do not claim an immediate need, but a possible future (yet-undefined) need. So if there are any other people who feel that this makes sense, please speak up soon. We already have (rfc3289) DscpOrAny ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The IP header Differentiated Services Code-Point that may be used for discriminating among traffic streams. The value -1 is used to indicate a wild card i.e. any value." REFERENCE "RFC 2474, RFC 2780" SYNTAX Integer32 (-1 | 0..63) Based on that, we also got to (draft-ietf-ops-ipv6-flowlabel-00.txt) IPv6FlowLabelOrAny ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The flow identifier or Flow Label in an IPv6 packet header that may be used to discriminate traffic flows. The value of -1 is used to indicate a wildcard, i.e. any value. " SYNTAX Integer32 (-1 | 0..1048575) And so now we were going down the same path 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) So that seems consistent, no? If we do so, we can bypass that discussion about if it is valid to use value 4095 to mean "any"... I suspect that discussion may take a while and we may need to check with IEEE 802 people/docs. Or are you telling us we better change all of the above to use a positive number for "any". >Randy > Thanks, Bert _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From mailnull@www1.ietf.org Thu Feb 27 14:23:11 2003 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 OAA17824 for ; Thu, 27 Feb 2003 14:23:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RJXJc14820 for bridge-archive@odin.ietf.org; Thu, 27 Feb 2003 14:33:19 -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 h1RJX8p14811; Thu, 27 Feb 2003 14:33:09 -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 h1RJWgp14781 for ; Thu, 27 Feb 2003 14:32:42 -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 OAA17792 for ; Thu, 27 Feb 2003 14:22:02 -0500 (EST) Received: from tom3 (unknown [62.188.144.130]) by colossus.systems.pipex.net (Postfix) with SMTP id B973016000563; Thu, 27 Feb 2003 19:25:57 +0000 (GMT) Message-ID: <013e01c2de95$ba0cf560$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Andrew Smith" , "'Wijnen, Bert (Bert)'" Cc: "'Bridge-Mib (E-mail)'" , Date: Thu, 27 Feb 2003 19:12:50 -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 Subject: [Bridge-mib] Re: VLAn ID 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: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree - clunky to overload the field, a separate flag is more elegant - should be unsigned not signed Tom Petch nwnetworks@dial.pipex.com -----Original Message----- From: Andrew Smith To: 'Wijnen, Bert (Bert)' Cc: 'Bridge-Mib (E-mail)' ; mibs@ops.ietf.org Date: 27 February 2003 18:00 Subject: RE: VLAn ID >Bert, > >The whole point of defining these TCs in a separate document is to serve >"possible future (yet-undefined) needs" - why else would we bother to >break them out in a separate document or module? > >The need to use VlanIdOrAny as an index in the future seems likely to >me. It is especially likely if you believe that we're trying to set a >precedent here for how to represent "some sort of packet field or >don't-care". Personally, I think it's a bit clunky to overload the value >like this - a separate flag object is more elegant, but, if we're >comfortable with the overloading, I'd go with Randy and say (as I did >before - maybe you missed my message?) that the syntax here should be >unsigned, not signed (I understand the practical reasons for the >non-negative-index restriction in SNMP but it is a limitation on the >SMIv2 language). I don't think there's a need to consult with IEEE 802 >on this - I think most of the people with relevant opinions on this are >already on this thread - but that's the bridge-mib WG chair's call if he >wants to ask himself for help. > >My opinions (I know you're looking for others though ...). > >Andrew > > >-----Original Message----- >From: owner-mibs@ops.ietf.org [mailto:owner-mibs@ops.ietf.org] On Behalf >Of Wijnen, Bert (Bert) >Sent: Thursday, February 27, 2003 8:36 AM >To: Randy Presuhn (E-mail) >Cc: Bridge-Mib (E-mail); mibs@ops.ietf.org >Subject: VLAn ID > > >Randy, you wrote: >>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. >> > >As far as I can tell, you seem to be the only one sofar who >has spoken up on the idea of not having a negative value >for the "any" for the VlanIdOrAny TC that I proposed. > >You do not claim an immediate need, but a possible future >(yet-undefined) need. > >S > > > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From mailnull@www1.ietf.org Thu Feb 27 20:49:10 2003 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 UAA00210 for ; Thu, 27 Feb 2003 20:49:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1S1xQf06184 for bridge-archive@odin.ietf.org; Thu, 27 Feb 2003 20:59: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 h1S1xFp06177; Thu, 27 Feb 2003 20:59:15 -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 h1S1wPp06153 for ; Thu, 27 Feb 2003 20:58:25 -0500 Received: from iere.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00170 for ; Thu, 27 Feb 2003 20:47:38 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h1S1mnB17127 for ; Thu, 27 Feb 2003 20:48:49 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h1S1mmw17122 for ; Thu, 27 Feb 2003 20:48:49 -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" Date: Fri, 28 Feb 2003 03:51:32 +0200 Message-ID: Thread-Topic: ieee8023-lag-mib : dot3adAggActorSystemPriority and dot3adAggPortActorSystemPriority definition Thread-Index: AcLefHhCKeEqWeyTRgO02M9l3dfKHAAT0uWw From: "Romascanu, Dan (Dan)" To: "Les Bell" , "Rohit Rohit" Cc: , , "David Law" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1S1wQp06154 Subject: [Bridge-mib] RE: ieee8023-lag-mib : dot3adAggActorSystemPriority and dot3adAggPortActorSystemPriority definition 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: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Les, Did you (or somebody else) propose these fixes through the IEEE 802.3 maintenance mechanism? Dan > -----Original Message----- > From: Les Bell [mailto:Les_Bell@eur.3com.com] > Sent: Thursday, February 27, 2003 6:17 PM > To: Rohit Rohit > Cc: mibs@ops.ietf.org; Bridge-mib@ietf.org; David Law > Subject: Re: ieee8023-lag-mib : dot3adAggActorSystemPriority > and dot3adAggPortActorSystemPriority definition > > > > > > This is a known bug in the MIB and a fix should appear in the > next revision of > the 802.3 spec. > There are a number of similar objects with the same bug. The > range should be > (0..65535) on all of them. The proposed fix is to deprecate > these objects and > replace them with corrected equivalents. There are some > other fixes pending > also. > > Les... > > > > > > "Rohit Rohit" on > 26/02/2003 22:55:29 > > Sent by: "Rohit Rohit" > > > To: mibs@ops.ietf.org > cc: (Les Bell/GB/3Com) > Subject: ieee8023-lag-mib : dot3adAggActorSystemPriority and > dot3adAggPortActorSystemPriority definition > > > > > Hi, > > I am not sure if this is the right group for this question; > but mail to 'stds-802-3-trunking@majordomo.ieee.org' does not seem > to work. > > I see the following inconsistency between the > dot3adAggActorSystemPriority > and dot3adAggPortActorSystemPriority. > > dot3adAggPortActorSystemPriority is defined to be 2 octets; but > its range is only from 0 to 255. ( IMHO, it should be 0 .. 65535 ). > > > dot3adAggPortActorSystemPriority OBJECT-TYPE > > SYNTAX INTEGER (0..255) > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "A 2-octet read-write value used to define the priority > > value associated with the Actor's System ID." > > REFERENCE > > "IEEE 802.3 Subclause 30.7.2.1.2" > > ::= { dot3adAggPortEntry 2 } > > > while dot3adAggActorSystemPriority is also defined to be > 2 octets; but its range is from 0..65535. > > Any reason for this inconsistency ? > > > dot3adAggActorSystemPriority OBJECT-TYPE > > SYNTAX INTEGER (0..65535) > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "A 2-octet read-write value indicating the priority > > value associated with the Actor's System ID." > > REFERENCE > > "IEEE 802.3 Subclause 30.7.1.1.5" > > ::= { dot3adAggEntry 3 } > > > Thanks > Rohit > > > > > > > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From mailnull@www1.ietf.org Fri Feb 28 04:02:54 2003 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 EAA17809 for ; Fri, 28 Feb 2003 04:02:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1S9DHn10286 for bridge-archive@odin.ietf.org; Fri, 28 Feb 2003 04:13: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 h1S9D9p10279; Fri, 28 Feb 2003 04:13:10 -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 h1RI0mp07780 for ; Thu, 27 Feb 2003 13:00:48 -0500 Received: from albatross.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13848 for ; Thu, 27 Feb 2003 12:50:11 -0500 (EST) Received: from user-11206ng.dsl.mindspring.com ([66.32.26.240] helo=ANDREWLAPTOP) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18oSEP-0006mA-00; Thu, 27 Feb 2003 09:54:05 -0800 From: "Andrew Smith" To: "'Wijnen, Bert \(Bert\)'" Cc: "'Bridge-Mib \(E-mail\)'" , Date: Thu, 27 Feb 2003 09:53:56 -0800 Message-ID: <046701c2de89$35d1c160$1500000a@ANDREWLAPTOP> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501062FA1@nl0006exch001u.nl.lucent.com> Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Bridge-mib] RE: VLAn ID 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: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bert, The whole point of defining these TCs in a separate document is to serve "possible future (yet-undefined) needs" - why else would we bother to break them out in a separate document or module? The need to use VlanIdOrAny as an index in the future seems likely to me. It is especially likely if you believe that we're trying to set a precedent here for how to represent "some sort of packet field or don't-care". Personally, I think it's a bit clunky to overload the value like this - a separate flag object is more elegant, but, if we're comfortable with the overloading, I'd go with Randy and say (as I did before - maybe you missed my message?) that the syntax here should be unsigned, not signed (I understand the practical reasons for the non-negative-index restriction in SNMP but it is a limitation on the SMIv2 language). I don't think there's a need to consult with IEEE 802 on this - I think most of the people with relevant opinions on this are already on this thread - but that's the bridge-mib WG chair's call if he wants to ask himself for help. My opinions (I know you're looking for others though ...). Andrew -----Original Message----- From: owner-mibs@ops.ietf.org [mailto:owner-mibs@ops.ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Thursday, February 27, 2003 8:36 AM To: Randy Presuhn (E-mail) Cc: Bridge-Mib (E-mail); mibs@ops.ietf.org Subject: VLAn ID Randy, you wrote: >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. > As far as I can tell, you seem to be the only one sofar who has spoken up on the idea of not having a negative value for the "any" for the VlanIdOrAny TC that I proposed. You do not claim an immediate need, but a possible future (yet-undefined) need. S _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From mailnull@www1.ietf.org Fri Feb 28 04:34:00 2003 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 EAA18380 for ; Fri, 28 Feb 2003 04:34:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1S9iOl12416 for bridge-archive@odin.ietf.org; Fri, 28 Feb 2003 04:44:24 -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 h1S9i3p12403; Fri, 28 Feb 2003 04:44: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 h1S9hYp12380 for ; Fri, 28 Feb 2003 04:43:34 -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 EAA18338 for ; Fri, 28 Feb 2003 04:32:39 -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 h1S9bvNS011298; Fri, 28 Feb 2003 09:37:57 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id h1S9bnQ09885; Fri, 28 Feb 2003 09:37:49 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256CDB.0034D6DE ; Fri, 28 Feb 2003 09:37:08 +0000 X-Lotus-FromDomain: 3COM From: "Les Bell" To: "Romascanu, Dan (Dan)" cc: "Rohit Rohit" , mibs@ops.ietf.org, Bridge-mib@ietf.org, "David Law" Message-ID: <80256CDB.0034D1CD.00@notesmta.eur.3com.com> Date: Fri, 28 Feb 2003 09:34:37 +0000 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Bridge-mib] RE: ieee8023-lag-mib : dot3adAggActorSystemPriority and dot3adAggPortActorSystemPriority definition 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: , List-Id: List-Post: List-Help: List-Subscribe: , Yes, these fixes are going through the IEEE 802.3 maintenance mechanism. I do not know the maintenance reference number, but I provided them with the fixes. Les... "Romascanu, Dan (Dan)" on 28/02/2003 01:51:32 Sent by: "Romascanu, Dan (Dan)" To: Les Bell/GB/3Com, "Rohit Rohit" cc: mibs@ops.ietf.org, Bridge-mib@ietf.org, David Law/GB/3Com Subject: RE: ieee8023-lag-mib : dot3adAggActorSystemPriority and dot3adAggPortActorSystemPriority definition Les, Did you (or somebody else) propose these fixes through the IEEE 802.3 maintenance mechanism? Dan > -----Original Message----- > From: Les Bell [mailto:Les_Bell@eur.3com.com] > Sent: Thursday, February 27, 2003 6:17 PM > To: Rohit Rohit > Cc: mibs@ops.ietf.org; Bridge-mib@ietf.org; David Law > Subject: Re: ieee8023-lag-mib : dot3adAggActorSystemPriority > and dot3adAggPortActorSystemPriority definition > > > > > > This is a known bug in the MIB and a fix should appear in the > next revision of > the 802.3 spec. > There are a number of similar objects with the same bug. The > range should be > (0..65535) on all of them. The proposed fix is to deprecate > these objects and > replace them with corrected equivalents. There are some > other fixes pending > also. > > Les... > > > > > > "Rohit Rohit" on > 26/02/2003 22:55:29 > > Sent by: "Rohit Rohit" > > > To: mibs@ops.ietf.org > cc: (Les Bell/GB/3Com) > Subject: ieee8023-lag-mib : dot3adAggActorSystemPriority and > dot3adAggPortActorSystemPriority definition > > > > > Hi, > > I am not sure if this is the right group for this question; > but mail to 'stds-802-3-trunking@majordomo.ieee.org' does not seem > to work. > > I see the following inconsistency between the > dot3adAggActorSystemPriority > and dot3adAggPortActorSystemPriority. > > dot3adAggPortActorSystemPriority is defined to be 2 octets; but > its range is only from 0 to 255. ( IMHO, it should be 0 .. 65535 ). > > > dot3adAggPortActorSystemPriority OBJECT-TYPE > > SYNTAX INTEGER (0..255) > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "A 2-octet read-write value used to define the priority > > value associated with the Actor's System ID." > > REFERENCE > > "IEEE 802.3 Subclause 30.7.2.1.2" > > ::= { dot3adAggPortEntry 2 } > > > while dot3adAggActorSystemPriority is also defined to be > 2 octets; but its range is from 0..65535. > > Any reason for this inconsistency ? > > > dot3adAggActorSystemPriority OBJECT-TYPE > > SYNTAX INTEGER (0..65535) > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "A 2-octet read-write value indicating the priority > > value associated with the Actor's System ID." > > REFERENCE > > "IEEE 802.3 Subclause 30.7.1.1.5" > > ::= { dot3adAggEntry 3 } > > > Thanks > Rohit > > > > > > > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From mailnull@www1.ietf.org Fri Feb 28 11:35:57 2003 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 LAA04038 for ; Fri, 28 Feb 2003 11:35:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SGkTO09908 for bridge-archive@odin.ietf.org; Fri, 28 Feb 2003 11:46:29 -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 h1SGk7p09898; Fri, 28 Feb 2003 11:46:08 -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 h1SGjIp09867 for ; Fri, 28 Feb 2003 11:45:18 -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 LAA03998 for ; Fri, 28 Feb 2003 11:34:14 -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 h1SGdeNS024845; Fri, 28 Feb 2003 16:39:40 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id h1SGddQ04423; Fri, 28 Feb 2003 16:39:40 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256CDB.005B946B ; Fri, 28 Feb 2003 16:40:17 +0000 X-Lotus-FromDomain: 3COM From: "Les Bell" To: "Andrew Smith" cc: "'Wijnen, Bert \(Bert\)'" , "'Bridge-Mib \(E-mail\)'" , mibs@ops.ietf.org Message-ID: <80256CDB.005B7106.00@notesmta.eur.3com.com> Date: Fri, 28 Feb 2003 16:27:17 +0000 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Bridge-mib] RE: VLAn ID 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: , List-Id: List-Post: List-Help: List-Subscribe: , I have asked for the opinion of the IEEE 802.1 Task Force Chair, Mick Seaman, on this proposal. He believes that the use of 4095 as a wildcard VLAN-ID would be okay, but he wants to discuss it formally at the IEEE 802 meeting in Dallas (week commencing March 9). I will be attending this meeting. Les... "Andrew Smith" on 27/02/2003 17:53:56 Sent by: "Andrew Smith" To: "'Wijnen, Bert \ cc: "'Bridge-Mib \, mibs@ops.ietf.org (Les Bell/GB/3Com) Subject: RE: VLAn ID Bert, The whole point of defining these TCs in a separate document is to serve "possible future (yet-undefined) needs" - why else would we bother to break them out in a separate document or module? The need to use VlanIdOrAny as an index in the future seems likely to me. It is especially likely if you believe that we're trying to set a precedent here for how to represent "some sort of packet field or don't-care". Personally, I think it's a bit clunky to overload the value like this - a separate flag object is more elegant, but, if we're comfortable with the overloading, I'd go with Randy and say (as I did before - maybe you missed my message?) that the syntax here should be unsigned, not signed (I understand the practical reasons for the non-negative-index restriction in SNMP but it is a limitation on the SMIv2 language). I don't think there's a need to consult with IEEE 802 on this - I think most of the people with relevant opinions on this are already on this thread - but that's the bridge-mib WG chair's call if he wants to ask himself for help. My opinions (I know you're looking for others though ...). Andrew -----Original Message----- From: owner-mibs@ops.ietf.org [mailto:owner-mibs@ops.ietf.org] On Behalf Of Wijnen, Bert (Bert) Sent: Thursday, February 27, 2003 8:36 AM To: Randy Presuhn (E-mail) Cc: Bridge-Mib (E-mail); mibs@ops.ietf.org Subject: VLAn ID Randy, you wrote: >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. > As far as I can tell, you seem to be the only one sofar who has spoken up on the idea of not having a negative value for the "any" for the VlanIdOrAny TC that I proposed. You do not claim an immediate need, but a possible future (yet-undefined) need. S _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib