RE: [Bridge-mib] VLAN-ID

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Wed, 19 February 2003 17:54 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03106 for <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <bridge-mib@ietf.org>; 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 <bridge-mib@ietf.org>; 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 <bridge-mib@ietf.org>; 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: <AAB4B3D3CF0F454F98272CBE187FDE2F017B752F@is0004avexu1.global.avaya.com>
Thread-Topic: [Bridge-mib] VLAN-ID
Thread-Index: AcLYKxCISBVXf79LTvqvcrYKTJivQwAEg3Sg
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, <bridge-mib@ietf.org>
Cc: <mibs@ops.ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id 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: <https://www1.ietf.org/mailman/listinfo/bridge-mib>, <mailto:bridge-mib-request@ietf.org?subject=unsubscribe>
List-Id: <bridge-mib.ietf.org>
List-Post: <mailto:bridge-mib@ietf.org>
List-Help: <mailto:bridge-mib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/bridge-mib>, <mailto:bridge-mib-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

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