[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> >
>