Subject: [ipcdn] FW: DOCS-IETF-QOS-MIB vesion 9 -- VLAN ID

From: Murwin William-LWM008 <[email-masked]>
Date: Mon, 8 Sep 2003 09:32:42 -0400

Here is a discussion about VLAN ID Textual Convetions recently had by Bert Wijnen and myself.
Bert is currently checking with the Birdge Mib,on proposing a "VlanOrNone" textual convention, where the DOCS-IETF-QOS-MIB would use the syntax with range (0|1..4094).  

-Will

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Sunday, September 07, 2003 3:29 AM
To: Murwin William-LWM008; 'Wijnen, Bert (Bert)'
Subject: RE: DOCS-IETF-QOS-MIB vesion 9 -- VLAN ID

OK, so let me check with brdige mib and IEE folk if it is OK
with them to add this additional TC that I propose.
If so, then you can go ahead with a similar definition,
not yet using the TC if you do not want to be forced to
wait till a "still to be written ID" shows up.

At any later revision, your SYNTAX can then be replaced with
this potential TC, cause it has the same semantics and then
we're all in good shape.

You may want to post some of this discussion to the ipcdn
mailing list, so people understand/know what is going on.

Thanks,
Bert 

> -----Original Message-----
> From: Murwin William-LWM008 [mailto:[email-masked]]
> Sent: vrijdag 5 september 2003 17:59
> To: 'Wijnen, Bert (Bert)'
> Subject: RE: DOCS-IETF-QOS-MIB vesion 9 -- VLAN ID
> 
> 
> That correct Bert, I looking for a VLAN or None.
> (0 | 1..4094). That why we just had the syntax as being 
> (0..4094) with a
> description specifically saying that 0 is for when no VLAN 
> has been configured.
> 
> Will
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Friday, September 05, 2003 11:32 AM
> To: Murwin William-LWM008; Wijnen, Bert (Bert)
> Subject: RE: DOCS-IETF-QOS-MIB vesion 9 -- VLAN ID
> 
> 
> I was going to come back on the VLAN ID
> > 3) Vlan 
> > 	I my previous emial to you we also discuss that 
> > currently there is no VlanIdOrAny Textual Convention. And the 
> > IEEE verbally as agreed to use -1 and 4095 to mean "Any Vlan".
> >
> At the other hand, there has been discussion on the [email-masked]
> and bridgemib mailing lists that people might want to be able to
> use the VlanIdOrAny as an index object and then negative values
> are no good.
> 
> So the current proposal looks more like:
> 
>     VlanId            ::= TEXTUAL CONVENTION
>         DISPLAY-HINT "d"
>         STATUS        current
>         DESCRIPTION  "The VLAN ID that uniquely identifies a VLAN."
>         SYNTAX        Integer32 (1..4094)
> 
> 
>     VlanIdOrAny       ::= TEXTUAL CONVENTION
>         DISPLAY-HINT "d"
>         STATUS        current
>         DESCRIPTION  "The VLAN ID that uniquely identifies a VLAN.
>                       The value of 4095 is used to indicate a 
> wildcard,
>                       i.e. any value.
>                      "
>         SYNTAX        Integer32 (1..4094 | 4095)
> 
> 
> > The DOCS-IETF-QOS-MIB is has the docsQosPktClassVlanId object
> > which reports the value in the file sent from CM to the CMTS.
> > This file may not even contain a Class Vlan Id, I.e. the
> > reason 0 was reported.
> >
> > My question to you is can we keep this object as is or
> > do we have to change the SYNTAX to (-1 | 1..4095) where 
> > -1 and 4095 could mean that this is not configured, 
> > because DOCSIS Specification does not have a concept of 
> > Any Vlan. We would be the only MIB that I know of that 
> > would be using this syntax and would be describing this 
> > -1 and 4095 to be "none" not "Any".
> > 
> 		
> > 
> > docsQosPktClassVlanId OBJECT-TYPE
> >     SYNTAX          Integer32 (0..4095)
> >     MAX-ACCESS      read-only
> >     STATUS          current
> >     DESCRIPTION    "This object applies only to Ethernet frames 
> >                     using the 802.1P/Q tag header.
> > 
> >                     If this object's value is nonzero, tagged
> >                     packets must have a VLAN Identifier that matches
> >                     the value in order to match the rule.
> > 
> >                     Only the least significant 12 bits of 
> this object's
> >                     value are valid. 
> > 
> I would remove this para. The range makes it such that the 
> values cannot
> exceed 12 bits.
> 
> >                     If the referenced parameter is not 
> present in the
> >                     classifier, the value of this object is 
> reported 
> >                     as 0.
> >                    "
> >     REFERENCE      "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.2"
> >     ::= { docsQosPktClassEntry 24 }
> > 
> It sounds as if you might also want a
> 
>     VlanIdOrZero      ::= TEXTUAL CONVENTION
>         DISPLAY-HINT "d"
>         STATUS        current
>         DESCRIPTION  "The VLAN ID that uniquely identifies a VLAN.
> 
>                       The value zero is NOT a valid VLAN ID. 
>                       
>                       When this textual convention is used as the
>                       syntax of an object, the object definition
>                       MUST specify in the DESCRIPTION clause what
>                       the value zero means.
>                      "
>         SYNTAX        Integer32 (0 | 1..4094)
> 
> Did I get that correct?
> 
> Bert
> 

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn