RE: [Bridge-mib] VLAN-ID

"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Mon, 24 February 2003 14:24 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 JAA15192 for <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <bridge-mib@ietf.org>; 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 <bridge-mib@ietf.org>; Mon, 24 Feb 2003 09:27:27 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <DVZN6Z5J>; Mon, 24 Feb 2003 15:27:21 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155F7C8D2@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Les Bell <Les_Bell@eur.3com.com>, Randy Presuhn <randy_presuhn@mindspring.com>
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: <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>

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" <randy_presuhn@mindspring.com> on 24/02/2003 06:29:58
> 
> Sent by:  "Randy Presuhn" <randy_presuhn@mindspring.com>
> 
> 
> To:   bridge-mib@ietf.org
> cc:   mibs@ops.ietf.org (Les Bell/GB/3Com)
> Subject:  Re: [Bridge-mib] VLAN-ID
> 
> 
> 
> 
> Hi -
> 
> I think it would be better if the "any" value in the *OrAny TC were
> a non-negative value so that the type could be used to define an
> index.  There may not be a need today, but thinking ahead to
> representing policy-like things wouldn't hurt.
> 
> Randy
> 
> > From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> > To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>; 
> <bridge-mib@ietf.org>
> > Cc: <mibs@ops.ietf.org>
> > Sent: Friday, February 21, 2003 7:15 AM
> > Subject: RE: [Bridge-mib] VLAN-ID
> >
> 
> > Having seen some discussion. How about if we were to define
> > two generic TCs for this that people will be encouraged to use
> > from now on:
> >
> >
> >   VlanId            ::= TEXTUAL-CONVENTION
> >       DISPLAY-HINT "d"
> >       STATUS        current
> >       DESCRIPTION  "A 12-bit VLAN ID used in the VLAN Tag header."
> >       SYNTAX        Integer32 (1..4094)
> >       REFERENCE    "Draft Standard for Virtual Bridged Local Area
> >                     Networks, P802.1Q/D10, chapter 3.13
> >                    "
> >
> >   VlanIdOrAny       ::= TEXTUAL CONVENTION
> >       DISPLAY-HINT "d"
> >       STATUS        current
> >       DESCRIPTION  "The VLAN ID that uniquely identifies a VLAN.
> >                     The value of -1 is used to indicate a wildcard,
> >                     i.e. any value.
> >                    "
> >       SYNTAX        Integer32 (-1 | 1..4094)
> >
> > Or would the VlanIdOrAny better be represented with
> >       SYNTAX        Integer32 (-1 | 1..4094)
> > where zero represents the wild card ??
> >
> > Not sure if we should include the VlanIndex from RFC2674. I think
> > it is not as general... but am not sure. If we were to 
> generalize it,
> > then I would think it should look like:
> >
> >   VlanIndex         ::= TEXTUAL-CONVENTION
> >       DISPLAY-HINT "d"
> >       STATUS        current
> >       DESCRIPTION  "A value used to index per-VLAN tables:
> >                    - values of 0 and 4095 are not permitted;
> >                    - a value between 1 and 4094 inclusive represents
> >                      an IEEE 802.1Q VLAN-ID with global scope within
> >                      a given bridged domain (see VlanId textual
> >                      convention).
> >                    - a value greater than 4095 represents a 
> VLAN with
> >                      scope local to the particular agent, i.e. one
> >                      without a global VLAN-ID assigned to it. Such
> >                      VLANs are outside the scope of IEEE 802.1Q but
> >                      it is convenient to be able to include them in
> >                      tables in the same way.
> >                    "
> >       SYNTAX        Unsigned32 (1..4094 | 4096..4294967295)
> >
> > Or should we also use an Integer32 for the last one?
> > Would RFC2674 be the best place to define those?
> >
> > If we were to do the above, then
> > - the framework PIb can keep what they have. At a future revision
> >   they can pick up the TC
> > - RFC2613 could still advance as is.
> >   I would prefer a new one that uses the new TC, but that new
> >   TC will be in a PS, so that would prohibit advancing to DS.
> >   So we can do that at a later stage.
> > - RFC2674 gets updated
> > - docsis MIB probably should pick up new TC, or at least define
> >   their VlanID the same way as proposed in the TC.
> >
> > Thanks,
> > Bert
> >
> > > -----Original Message-----
> > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> > > Sent: woensdag 19 februari 2003 18:57
> > > To: Wijnen, Bert (Bert); bridge-mib@ietf.org
> > > Cc: mibs@ops.ietf.org
> > > Subject: RE: [Bridge-mib] VLAN-ID
> > >
> > >
> > > Bert,
> > >
> > > I suggest to take the discussion to the mibs list. The
> > > interest is broader than Bridge MIB, as demonstrated by the
> > > number of MIBs that deal with VLAN ID objects.
> > >
> > > To the point:
> > > - It looks that definitions in
> > > draft-ietf-bridge-ext-v2-01.txt, RFC 2613 and RFC 2674
> > > (VlanId) are similar. A common TC can be easily defined, by
> > > taking the RFC 2674 VlanId TC and adding the REFERENCE as in
> > > RFC 2613.
> > > - I do not know what is the reason DOCSIS supports value 0.
> > > - The framework PIB have added a special value -1, with a
> > > separate semantics (ignore VLAN in the filter).
> > > - VlanIndex in RFC2674 also has a different semantics.
> > >
> > > Side issue -  if a TC can be easily written and agreed (after
> > > some cat beating) - what will we be doing with documents
> > > already on the standards track? RFC 2613 is supposed to be
> > > advanced from PS to DS 'as is'. You can buy a beer to the
> > > author and have a new document issued, but will such a change
> > > prevent advancement of the document on the standard track? If
> > > yes, is this really worth?
> > >
> > > Dan
> > >
> > >
> > > > -----Original Message-----
> > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > > > Sent: Wednesday, February 19, 2003 5:14 PM
> > > > To: bridge-mib@ietf.org
> > > > Subject: [Bridge-mib] VLAN-ID
> > > >
> > > >
> > > > Bridgemibbers....
> > > >
> > > > I do not see much (if any activity lately) :-(
> > > >
> > > > But I have a question.
> > > >
> > > > I see a VLAN ID represented in various forms:
> > > >
> > > > - draft-ietf-bridge-ext-v2-01.txt
> > > >     VlanId ::= TEXTUAL-CONVENTION
> > > >        STATUS      current
> > > >        DESCRIPTION "A 12-bit VLAN ID used in the VLAN 
> Tag header."
> > > >        SYNTAX      INTEGER (1..4094)
> > > > - somehwere I found:
> > > >     dot1vProtocolPortGroupVid OBJECT-TYPE
> > > >        SYNTAX      INTEGER (1..4094)
> > > >        MAX-ACCESS  read-create
> > > >        STATUS      current
> > > >        DESCRIPTION "The VID associated with a group of 
> protocols for
> > > >                     each port."
> > > >        REFERENCE   "IEEE 802.1v clause 8.4.4, 12.10.1.2"
> > > >
> > > > - In a DOCSIS document I find:
> > > >     docsQosPktClassVlanId OBJECT-TYPE
> > > >        SYNTAX          Integer32 (0..4095)
> > > >        MAX-ACCESS      read-only
> > > >        STATUS          current
> > > >
> > > > - In the framework PIB 
> (draft-ietf-rap-frameworkpib-09.txt) I find:
> > > >
> > > >   frwk802FilterVlanId OBJECT-TYPE
> > > >       SYNTAX         Integer32 (-1 | 1..4094)
> > > >       STATUS         current
> > > >       DESCRIPTION
> > > >           "The VLAN ID (VID) that uniquely identifies a VLAN
> > > >           within the device. This VLAN may be known or unknown
> > > >           (i.e., traffic associated with this VID has not yet
> > > >           been seen by the device) at the time this entry
> > > >           is instantiated.
> > > >
> > > >           Setting the frwk802FilterVlanId object to -1
> > > indicates that
> > > >           VLAN data should not be considered during traffic
> > > >           classification."
> > > >
> > > > - In rfc2613 I find:
> > > >    smonVlanIdStatsId OBJECT-TYPE
> > > >     SYNTAX     Integer32 (1..4094)
> > > >     MAX-ACCESS not-accessible
> > > >     STATUS     current
> > > >     DESCRIPTION
> > > >         "The unique identifier of the VLAN monitored for
> > > >          this specific statistics collection.
> > > >
> > > >         Tagged packets match the VID for the range between
> > > 1 and 4094.
> > > >         An external RMON probe MAY detect VID=0 on an 
> Inter Switch
> > > >         Link, in which case the packet belongs to a VLAN
> > > determined by
> > > >         the PVID of the ingress port. The VLAN to which
> > > such a packet
> > > >         belongs can be determined only by a RMON probe
> > > internal to the
> > > >         switch."
> > > >     REFERENCE
> > > >         "Draft Standard for Virtual Bridged Local Area Networks,
> > > >           P802.1Q/D10, chapter 3.13"
> > > >
> > > > - In RFC2674 I find:
> > > >   VlanIndex ::= TEXTUAL-CONVENTION
> > > >     STATUS      current
> > > >     DESCRIPTION
> > > >         "A value used to index per-VLAN tables: values of 0 and
> > > >         4095 are not permitted; if the value is between 1 and
> > > >         4094 inclusive, it represents an IEEE 802.1Q 
> VLAN-ID with
> > > >         global scope within a given bridged domain (see VlanId
> > > >         textual convention).  If the value is greater than 4095
> > > >         then it represents a VLAN with scope local to the
> > > >         particular agent, i.e. one without a global VLAN-ID
> > > >         assigned to it. Such VLANs are outside the scope of
> > > >         IEEE 802.1Q but it is convenient to be able to 
> manage them
> > > >         in the same way using this MIB."
> > > >     SYNTAX      Unsigned32
> > > >
> > > > - IN RFC2674 I also find
> > > >    VlanId ::= TEXTUAL-CONVENTION
> > > >       STATUS      current
> > > >       DESCRIPTION
> > > >           "A 12-bit VLAN ID used in the VLAN Tag header."
> > > >       SYNTAX      INTEGER (1..4094)
> > > >
> > > > Not sure I found all occurances.
> > > >
> > > > So my question is: what is the CORRECT spec, and could we try
> > > > to define one (or a few)  TC(s) that everyone else can IMPORT
> > > > and use.
> > > >
> > > > Bert
> > > > _______________________________________________
> > > > Bridge-mib mailing list
> > > > Bridge-mib@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/bridge-mib
> > > >
> > >
> > _______________________________________________
> > Bridge-mib mailing list
> > Bridge-mib@ietf.org
> > https://www1.ietf.org/mailman/listinfo/bridge-mib
> 
> 
> 
> 
> 
> 
> 
> 
_______________________________________________
Bridge-mib mailing list
Bridge-mib@ietf.org
https://www1.ietf.org/mailman/listinfo/bridge-mib