headers
Woundy, Richard | 1 Apr 2003 04:59
Picon

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Michael-LZZ007 | 1 Apr 2003 16:55

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.   

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eduardo Cardona | 1 Apr 2003 18:23
Favicon

RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID


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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eduardo Cardona | 2 Apr 2003 01:22
Favicon

RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 2 Apr 2003 16:45
Picon
Favicon

Status - draft-ietf-ipcdn-subscriber-mib-10.txt

Should I consider revision 10 as the final document for
my very last check before you pass it to your AD for 
IETF Last Call? Has the WG approved this doc?

Maybe I missed some email about this.
Checking my todo-list right now

Thanks,
Bert 

> -----Original Message-----
> From: Wijnen, Bert (Bert) 
> Sent: donderdag 20 februari 2003 23:21
> To: Wilson.Sawyer <at> arrisi.com; ipcdn <at> ietf.org
> Cc: bwijnen <at> lucent.com; Erik Nordmark (E-mail); Ipcdn (E-mail);
> ipcdn-admin <at> ietf.org; Thomas Narten (E-mail)
> Subject: RE: [ipcdn] RE: Tos field -
> draft-ietf-ipcdn-subscriber-mib-09.txt
> 
> 
> I think the suggestion from Erik seemed more to be
> to use the Dscp or DscpOrAny TC from RFC3289.
> 
> Thanks,
> Bert 
> 
> > -----Original Message-----
> > From: Wilson.Sawyer <at> arrisi.com [mailto:Wilson.Sawyer <at> arrisi.com]
> > Sent: donderdag 20 februari 2003 20:40
> > To: ipcdn <at> ietf.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wilson.Sawyer | 2 Apr 2003 16:59
Favicon

Re: Status - draft-ietf-ipcdn-subscriber-mib-10.txt


I think the WG consensus is to remove the masked DSCP, and use the
DscpOrAny TC.

Rich has also asked me to look at RFC 3289 for potential overlap. I haven't
gotten to this yet.

- Wilson

                                                                                                                                    
                      "Wijnen, Bert                                                                                                 
                      (Bert)"                  To:       "'Wilson.Sawyer <at> arrisi.com'" <Wilson.Sawyer <at> arrisi.com>,                   
                      <bwijnen <at> lucent.c         "'ipcdn <at> ietf.org'" <ipcdn <at> ietf.org>                                                 
                      om>                      cc:       "'bwijnen <at> lucent.com'" <bwijnen <at> lucent.com>, "'Erik Nordmark (E-mail)'"    
                                                <Erik.Nordmark <at> sun.com>, "'Ipcdn (E-mail)'" <ipcdn <at> ietf.org>,                       
                      04/02/03 09:45 AM         "'ipcdn-admin <at> ietf.org'" <ipcdn-admin <at> ietf.org>, "'Thomas Narten (E-mail)'"         
                                                <narten <at> us.ibm.com>                                                                 
                                               Subject:  Status - draft-ietf-ipcdn-subscriber-mib-10.txt                            

Should I consider revision 10 as the final document for
my very last check before you pass it to your AD for
IETF Last Call? Has the WG approved this doc?

Maybe I missed some email about this.
Checking my todo-list right now

Thanks,
Bert

> -----Original Message-----
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Michael-LZZ007 | 2 Apr 2003 17:28

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:e.cardona <at> CableLabs.com]
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

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eduardo Cardona | 2 Apr 2003 18:50
Favicon

RE: DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID

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:Michael.Patrick <at> motorola.com] 
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,
(Continue reading)

Permalink | Reply | 5 comments |
headers
Woundy, Richard | 3 Apr 2003 00:57
Picon

RE: Re: Status - draft-ietf-ipcdn-subscriber-mib-10.txt

Wilson and Bert,

One immediate issue I found, in trying to re-use the DiffServ MIB for the
DOCSIS Subscriber Management functionality, was in the structure of the Data
Path table, which is the initial table for packet classification.

The Data Path Table is the first lookup table in the DiffServ MIB, and it
uses ifIndex and ifDirection as the initial parameters to match. Upon a
match, the typical next table is the Classifier Table (although the entry
may point to other Tables in the MIB).

In the Subscriber Management MIB, the first lookup table is
docsSubMgtCmFilterTable, which uses the particular cable modem, upstream or
downstream direction (similar to ifDirection), and CM versus CPE (CPEs are
behind the CMs on the subscriber home network) source/target to map to a
filter-group. The filter-group points to a set of rows in the
docsSubMgtPktFilterTable for packet classification. The four subscriber
management filter-groups are configured through the DOCSIS 1.1/2.0 CM
registration processes.

The two gaps I see in DiffServ MIB functionality are:
1. The DiffServ MIB assumes that a uniform set of classifiers are applied to
all traffic flowing over a particular interface, because in the general
network case, one cannot differentiate traffic except by classification. The
Subscriber Management MIB assumes that distinct sets of classifiers are
applied to different groups of cable modems that co-exist on the same cable
RF interface, because the DOCSIS registration process aids the CMTS in
differentiating different CM/CPE traffic sources and sinks. Note that there
can be thousands of CMs from different filter-groups co-existing on the same
cable RF interface, so an operator would need to add thousands of Classifier
(Continue reading)

Permalink | Reply | 0 comments |
headers
Woundy, Richard | 3 Apr 2003 01:15
Picon

IPCDN meeting minutes from San Francisco

Folks,

Could you review and comment on the following IPCDN meeting minutes from the
March IETF meeting by close of business Thursday? Thanks.

-- Rich

IETF IPCDN Meeting
San Francisco, CA USA
March 19, 2003

Reported by Greg Nakanishi (gnakanishi <at> motorola.com)
Edited by Rich Woundy (richard_woundy <at> cable.comcast.com)

WG Meeting Summary
------------------

Approximately twelve attendees of the IP over Cable Data Networks WG met
at the San Francisco IETF on March 19, 2003. The WG discussed the status
of its work items: five drafts for DOCSIS MIBs, three drafts for
PacketCable/IPCablecom, and six drafts for CableHome. The results of the
February 2003 interim meeting in Louisville, CO were also discussed.
Total meeting time was a little more than one hour.

The "DOCSIS Subscriber Management MIB" completed MIB doctor review,
although the use of DSCP value and mask objects needs to be resolved.
The "Application of the IGMP MIB to DOCSIS 1.1" needs to be rewritten
with a MIB compliance statement; this draft will be brought back to the
WG. Twenty-two submissions for thirteen distinct internet-drafts have
been posted since the previous IETF meeting in Atlanta. The WG also
(Continue reading)

Permalink | Reply | 1 comment |

Gmane