RE: [Bridge-mib] VLAN-ID

"Eduardo Cardona" <e.cardona@CableLabs.com> Thu, 20 February 2003 09:15 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 EAA04979 for <bridge-archive@odin.ietf.org>; 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 <bridge-mib@optimus.ietf.org>; 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 <bridge-mib@ietf.org>; 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: <E63E74E1F5391449BDFCAE1F352EC7DC115453@srvxchg.cablelabs.com>
Thread-Topic: [Bridge-mib] VLAN-ID
Thread-Index: AcLYTUJ/DBPO+/PTS9S2H/MRBplauAAAFZkA
From: Eduardo Cardona <e.cardona@CableLabs.com>
To: Andrew Smith <ah_smith@acm.org>
Cc: mibs@ops.ietf.org, bwijnen@lucent.com, bridge-mib@ietf.org, "Romascanu, Dan (Dan)" <dromasca@avaya.com>
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: <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

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