Subject: RE: [Bridge-mib] VLAN-ID

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 21 Feb 2003 16:15:37 +0100

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:[email-masked]]
> Sent: woensdag 19 februari 2003 18:57
> To: Wijnen, Bert (Bert); [email-masked]
> Cc: [email-masked]
> 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:[email-masked]]
> > Sent: Wednesday, February 19, 2003 5:14 PM
> > To: [email-masked]
> > 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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/bridge-mib
> > 
> 
_______________________________________________
Bridge-mib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bridge-mib

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 23 Feb 2003 22:29:58 -0800

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)" <[email-masked]>
> To: "Romascanu, Dan (Dan)" <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, February 21, 2003 7:15 AM