RE: [Bridge-mib] VLAN-ID

"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Fri, 21 February 2003 19:13 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 OAA11623 for <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <bridge-mib@ietf.org>; 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 <bridge-mib@ietf.org>; Fri, 21 Feb 2003 14:15:47 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <DVZN5848>; Fri, 21 Feb 2003 20:15:45 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155F7C59D@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Les Bell <Les_Bell@eur.3com.com>
Cc: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, 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: <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>

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)" <bwijnen@lucent.com> on 21/02/2003 15:15:37
> 
> Sent by:  "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> 
> 
> 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