Subject: [ipcdn] RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID

From: Patrick Michael-LZZ007 <[email-masked]>
Date: Tue, 1 Apr 2003 09:55:56 -0500

I agree we should modify the wording, but not in order to support an "any" VLAN ID match.

The MIB needs to reflect the semantics of the RFI spec.  The spec's wording is
(from SPI-RFIv1.1-I05):

	"The value of the field specify [sic] the matching value for the IEEE 802.1Q vlan_id bits."

There is no mention that the value must be nonzero in order to match. The assumption must be that a classifier with a 22/23.11.2 parameter value of 0 would match a tagged frame with a VLAN ID of zero.   

This is contrary to the current -07 mib description, which states:

	" If this object's value is nonzero, tagged
        packets must have a VLAN Identifier that matches
        the value in order to match the rule."

In other words, the MIB word requires a nonzero value in order to be matched,
which is contrary to the spec.   I would propose that we simply remove the wording from the MIB description "If this object's value is nonzero". 

As for an "any" VLAN encoding, the assumption there is that we need to allow a packet classifier to match any 802.1Q tagged packet, regardless of its VLAN Id value. While this is admittedly useful, I don't see where the RFI spec requires that operation, and I'm not sure that either CMs or CMTSs have implemented it. If I've missed an ECN to this effect, I apologize. 

Since I'm recommending that we NOT add a "-1" for an "any" VLANid match, I recommend that we keep the current syntax, and NOT use the VlanIdOrAny TC.

Does 
-mike

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Monday, March 31, 2003 9:59 PM
To: IPCDN WG (E-mail); DOCSIS OSS (E-mail)
Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin
William-LWM008
Subject: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID

Folks,

I am concerned about the lack of resolution to this issue of a "default VLAN
ID" for the DOCSIS QoS MIB.

Besides my concern about using a different VLAN ID definition than other
IETF MIBs, my concern centers on this comment from Les Bell of 3Com:

>We should not use the value 0 to indicate "any" VLAN, as this may be
>used by 802.1D Bridges that support Priority Tagging, but do not
>support 802.1Q VLANs.

In a later email, as IETF MIB folks suggested using 4095 as the "wildcard"
VLAN ID, Les' reaction was:

>I have asked for the opinion of the IEEE 802.1 Task Force Chair, Mick
>Seaman, on this proposal.  He believes that the use of 4095 as a
>wildcard VLAN-ID would be okay, but he wants to discuss it formally at
>the IEEE 802 meeting in Dallas (week commencing March 9).  I will be
>attending this meeting.

I am going to try to find out the reaction of the IEEE to this proposal.

The latest proposed IETF TEXTUAL CONVENTION for a VLAN ID (with wildcard
support) is:

    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)

I cannot find anything in the DOCSIS specifications, outside of the DOCSIS
QoS MIB, that uses 0 as a special VLAN ID.

-- Rich

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Thursday, February 13, 2003 3:37 PM
To: Greg White; Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail)
Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt

Inline
> -----Original Message-----
> From: Greg White [mailto:[email-masked]]
> Sent: donderdag 13 februari 2003 20:07
> To: Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail)
> Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt
> 
> 
> It is important that the range for docsQosPktClassVlanId include the
> value 0:
> 
>                     If the referenced parameter is not present in the
>                     classifier, the value of this object is reported
>                     as 0.
> 
Well, yours also goes up to (and inclusive) 4095 while
bridgemib only goes up to (and inclusive 4094).

If zero is not a valid VLAN ID and you want to niclude it as
not present, then maybe yours should be renamed to
  docsQosPktClassVlanIdOrNone
or some such

Bert
> -Greg
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Thursday, February 13, 2003 11:44 AM
> To: Eduardo Cardona; Wijnen, Bert (Bert); Ipcdn (E-mail)
> Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt
> 
> 
> Eduardo writes:
> > 
> > FYI 
> > Could be in other places but a starting point. 
> > 
> > draft-ietf-bridge-bridgemib-01.txt
> > 
> > VlanId ::= TEXTUAL-CONVENTION
> >        STATUS      current
> >        DESCRIPTION
> >            "The 12-bit VLAN ID used in the VLAN Tag header."
> >        SYNTAX      INTEGER (1..4094)
> > 
> And so... why does yours differ
> docsQosPktClassVlanId OBJECT-TYPE
>     SYNTAX          Integer32 (0..4095)
>     MAX-ACCESS      read-only
>     STATUS          current
> 
> I am not claiming that one is better than the other.
> But I always wonder why they are different.
> Best to try and get in touch with the bridgemib people
> 
> Bert
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Eduardo Cardona" <[email-masked]>
Date: Tue, 1 Apr 2003 09:23:16 -0700

I also believe that the wording description is what is needed, 

In addition, the current description carries the bit conversion (12 bit)
from the RFI TLV encoding/ 16 bit tag 12 MSB bits. 
Since VLAN ID is just a well understood ID integer value mapped to the
12  MSB, I think that is not needed or the TC VlanIdOrAny  will cover
that by definition when referencing 802.1x. Or that definition should be
in the TC itself.

Proposed to remove:
  "Only the least significant 12 bits of this object's value are valid."

To keep the most backward compatibility with existing implementations
and MIB/RFI spec balance: - not sure if needed since already included in
RFI Appendix C.2.1.7.2- 
"If this field is omitted, then comparison of the IEEE 802.1Q vlan_id
bits for this entry is irrelevant." 
-> regardless of the MIB reported value.

			Proposed:  ( -1 | 4095) TBD by IETF

                    If the referenced parameter is not present in the
                    classifier, the value of this object is reported
                    as a VlanIdorAny Wildcard value (-1 | 4095.) and 
                    ignored when matching the Ethernet frame.

Original:

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.

                    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 }

Proposed: 

docsQosPktClassVlanId OBJECT-TYPE
    SYNTAX          VlanIdOrAny 
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION    "This object applies only to Ethernet frames
                    using the 802.1P/Q tag header.

                    Tagged packets must have a VLAN Identifier that 
                    matches the value in order to match the rule.

                    If the referenced parameter is not present in the
                    classifier, the value of this object is reported
                    as the VlanIdorAny wildcard value (-1 | 4095.) and 
                    ignored when matching the Ethernet frame.
                   "
    REFERENCE      "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.2"
    ::= { docsQosPktClassEntry 24 }

More clarifications to changes,

It is an IETF rule to identify any common object as a whole entity and
being normalized to minimize the number of TC used among all IETF
Groups. There are some concerns ( not sure how bad would be) for huge
Management systems with hundreds of mibs compiled and at the same time
hundred of objects with similar behavior using different TCs. Also TCs
at some point may have a lot of code behind in operations to follow the
their Description rules. For integrators few TC are better. 

Then, I think the only pendig item is the IETF decision of what is
better -1 or 4095 as a valid "wildcard" - IETF- term   

DOCSIS as you pointed "does not" require wildcarding of the VLAN ID, but
not having this parameter in the classifier means ignore it which is a
kind of "wildcarding" "orAny" regardless of the mib value.

Backward compatibility, Regardless of -1|4905 or 0: 
As far MSO understand possible side effects in trying to use VLAN ID 0
for a matching classifier, internally all implementations may work fine.
The mib difference is noticed by pointing to the old mib DOCS-QOS-MIB or
the new one DOCS-QOS-IETF-MIB in  the Support systems.

I do not think we have other option than be tide to IETF TC if they
insist in that.

Now, the point in the TC "4095" is should it be -1 or 4095 and it will
be an IETF decision where we may be interested.

I would think in 4095 as a better "normalized" like an inverse-mask
with AND operations, 
or does any one recognize the mask -1 -1 -1 -1 rather than FF FF FF FF ?

But maybe the -1 value is being implemented already in the context of
802.1Q and this group should take the IETF recommendations.

Eduardo

-----Original Message-----
From: Patrick Michael-LZZ007 [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2003 7:56 AM
To: 'Woundy, Richard'; IPCDN WG (E-mail); DOCSIS OSS Majordomo List
Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin
William-LWM008
Subject: RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID

I agree we should modify the wording, but not in order to support an
"any" VLAN ID match.

The MIB needs to reflect the semantics of the RFI spec.  The spec's
wording is (from SPI-RFIv1.1-I05):

	"The value of the field specify [sic] the matching value for the
IEEE 802.1Q vlan_id bits."

There is no mention that the value must be nonzero in order to match.
The assumption must be that a classifier with a 22/23.11.2 parameter
value of 0 would match a tagged frame with a VLAN ID of zero.   

In other words, the MIB word requires a nonzero value in order to be
matched,
which is contrary to the spec.   I would propose that we simply remove
the wording from the MIB description "If this object's value is
nonzero". 

As for an "any" VLAN encoding, the assumption there is that we need to
allow a packet classifier to match any 802.1Q tagged packet, regardless
of its VLAN Id value. While this is admittedly useful, I don't see where
the RFI spec requires that operation, and I'm not sure that either CMs
or CMTSs have implemented it. If I've missed an ECN to this effect, I
apologize. 

Since I'm recommending that we NOT add a "-1" for an "any" VLANid match,
I recommend that we keep the current syntax, and NOT use the VlanIdOrAny
TC.

Does 
-mike

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Monday, March 31, 2003 9:59 PM
To: IPCDN WG (E-mail); DOCSIS OSS (E-mail)
Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin
William-LWM008

Folks,

I am concerned about the lack of resolution to this issue of a "default
VLAN ID" for the DOCSIS QoS MIB.

>used by 802.1D Bridges that support Priority Tagging, but do not 

In a later email, as IETF MIB folks suggested using 4095 as the

I cannot find anything in the DOCSIS specifications, outside of the
DOCSIS QoS MIB, that uses 0 as a special VLAN ID.

-- Rich

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Thursday, February 13, 2003 3:37 PM
To: Greg White; Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail)
Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt

Inline
>                     classifier, the value of this object is reported
Well, yours also goes up to (and inclusive) 4095 while bridgemib only
goes up to (and inclusive 4094).

If zero is not a valid VLAN ID and you want to niclude it as not
present, then maybe yours should be renamed to
  docsQosPktClassVlanIdOrNone
or some such

Bert

---

From: "Eduardo Cardona" <[email-masked]>
Date: Tue, 1 Apr 2003 16:22:58 -0700

Some extra findings.

In Table 9-2 section 9.3.2.3 VID of format Std 802.1Q-1998 

* VID value (hexadecimal) 
-> Meaning/Use

* 0 
-> The null VLAN ID. Indicates that the tag header contains only
user_priority infor-
mation; no VLAN identifier is present in the frame. This VID value shall
not be
configured as a PVID, configured in any Filtering Database entry, or
used in any
Management operation.

* 1 
-> The default PVID value used for classifying frames on ingress through
a Bridge
Port. The PVID value can be changed by management on a per-Port basis.

* FFF 
-> Reserved for implementation use. This VID value shall not be
configured as a
PVID, configured in any Filtering Database entry, used in any Management
oper-
ation, or transmitted in a tag header.

so I guess the already defined VlanIdOrAny TC is accurate and 0 or 4095
should not be used in any management operation -aka config File/ Mib
reporting- 

(*) The RFI spec may also reflect this constrains for the compound value
vlan_id1, vlan_id2 in  C.2.1.7.2 to not configure 0 or 4095 in the
config file which I refer as a good practice in my previous email :
"ignorance accident" of my part

Also a paragraph from the same section: 
"A priority-tagged frame is a tagged frame whose tag header contains a
VID value equal to the null VLAN
ID." which is covered in TLV definition in IEEE 802.1P User_Priority in
RFI C.2.1.7.1

So, with Patricks comments' I guess a closed mib description could be:

                    as the VlanIdOrAny wildcard value -1 and 

-----Original Message-----
From: Eduardo Cardona 
Sent: Tuesday, April 01, 2003 9:23 AM
To: Patrick Michael-LZZ007; Woundy, Richard; IPCDN WG (E-mail); DOCSIS
OSS Majordomo List
Cc: Greg White; Michael W. Patrick (E-mail); Murwin William-LWM008
Subject: RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID

Proposed to remove:

Original:

Proposed: 

                    as the VlanIdOrAny wildcard value (-1 | 4095.) and 

I would think in 4095 as a better "normalized" like an inverse-mask with
AND operations, 
or does any one recognize the mask -1 -1 -1 -1 rather than FF FF FF FF ?

Eduardo

-----Original Message-----
From: Patrick Michael-LZZ007 [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2003 7:56 AM
To: 'Woundy, Richard'; IPCDN WG (E-mail); DOCSIS OSS Majordomo List
Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin
William-LWM008

Does 
-mike

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Monday, March 31, 2003 9:59 PM
To: IPCDN WG (E-mail); DOCSIS OSS (E-mail)
Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin
William-LWM008

Folks,

-- Rich

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Thursday, February 13, 2003 3:37 PM
To: Greg White; Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail)
Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt

Inline

Bert

---

From: Patrick Michael-LZZ007 <[email-masked]>
Date: Wed, 2 Apr 2003 10:28:20 -0500

Eduardo,

Don't you think it would be confusing to report -1 as "any" for the value when the parameter is omitted?  The object is not used for classification in this case, so it doesn't match "any" tagged packet. My whole point in keeping the reporting of the value 0 is to say that we do NOT match "any" tagged VLAN value.

-mike

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]]
Sent: Tuesday, April 01, 2003 11:23 AM
To: Patrick Michael-LZZ007; Woundy, Richard; IPCDN WG (E-mail); DOCSIS
OSS Majordomo List; Patrick Michael-LZZ007; Woundy, Richard; IPCDN WG
(E-mail); DOCSIS OSS Majordomo List
Cc: Greg White; Michael W. Patrick (E-mail); Murwin William-LWM008
Subject: RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID

Proposed to remove:

Original:

Proposed: 

Eduardo

-----Original Message-----
From: Patrick Michael-LZZ007 [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2003 7:56 AM
To: 'Woundy, Richard'; IPCDN WG (E-mail); DOCSIS OSS Majordomo List
Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin
William-LWM008

Does 
-mike

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Monday, March 31, 2003 9:59 PM
To: IPCDN WG (E-mail); DOCSIS OSS (E-mail)
Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin
William-LWM008

Folks,

-- Rich

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Thursday, February 13, 2003 3:37 PM
To: Greg White; Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail)
Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt

Inline

Bert

---

From: "Eduardo Cardona" <[email-masked]>
Date: Wed, 2 Apr 2003 09:50:01 -0700

Mike, 
Personally I also believe that, but this is also the land of other
IETF,IEEE groups.
The same rationale applied to those groups (non-DOCSIS); showing '0' is
confusing for them since it is an invalid value according to their spec
(802.1Q).. Those guys would like to have in our side a correct 802.1Q
interpretation.

The new guidelines from the ops ietf group are making slight changes in
how MSOs operates DOCS-XXX-MIB vs the new DOCS-XXX-IETF-MIB modules :
In general, I do not think current proposed drafts for RFC are the
places to have them due time constrains and some drafts have no previous
RFCs : SubMgt, BPI2, QOS

Different approaches to clarify those "differences" may be added in OSSI
spec or a remote option as informational RFC.

Eduardo

-----Original Message-----
From: Patrick Michael-LZZ007 [mailto:[email-masked]] 
Sent: Wednesday, April 02, 2003 8:28 AM
To: Eduardo Cardona; Woundy, Richard; IPCDN WG (E-mail); DOCSIS OSS
Majordomo List; Woundy, Richard; IPCDN WG (E-mail); DOCSIS OSS Majordomo
List
Cc: Greg White; Michael W. Patrick (E-mail); Murwin William-LWM008
Subject: RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID

Eduardo,

Don't you think it would be confusing to report -1 as "any" for the
value when the parameter is omitted?  The object is not used for
classification in this case, so it doesn't match "any" tagged packet. My
whole point in keeping the reporting of the value 0 is to say that we do
NOT match "any" tagged VLAN value.

-mike

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]]
Sent: Tuesday, April 01, 2003 11:23 AM
To: Patrick Michael-LZZ007; Woundy, Richard; IPCDN WG (E-mail); DOCSIS

Proposed to remove:

Original:

Proposed: 

Eduardo

-----Original Message-----
From: Patrick Michael-LZZ007 [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2003 7:56 AM
To: 'Woundy, Richard'; IPCDN WG (E-mail); DOCSIS OSS Majordomo List
Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin
William-LWM008

Does 
-mike

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Monday, March 31, 2003 9:59 PM
To: IPCDN WG (E-mail); DOCSIS OSS (E-mail)
Cc: Greg White; Eduardo Cardona; Michael W. Patrick (E-mail); Murwin
William-LWM008

Folks,

-- Rich

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Thursday, February 13, 2003 3:37 PM
To: Greg White; Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail)
Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt

Inline

Bert