RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs

Andrew,

Please keep in mind that the current Cable Device MIB is an update to RFC
2669, which pre-dates your RFC 3289 by three years. Since the publication of
RFC 2669, about 20 million cable modems have been shipped, with our industry
presumption that the Cable Device MIB was IETF-blessed. :^(

I described the Cable Device MIB filters as "re-marking boundary nodes"
using the language of RFC 2474. But the original Cable Device filters really
were designed as extended access control lists for cable modems, e.g. to
keep unwanted traffic off the cable network: NetBEUI, spoofed DHCP servers,
etc. The filters also happen to contain IP ToS matching and overwriting
capabilities. As we figure out how to update the RFC 2669 MIB, naturally we
want to replace IPv4 ToS management with IPv4/v6 DSCP management... two
weeks ago we start to look at RFC 3289 for the first time. :^(

The Subscriber Management MIB is designed as a light-weight extension to the
Cable Device MIB for Cable Modem Termination System (CMTS) filtering. That
MIB separates TCP/UDP port filtering into separate filtering tables due to
performance reasons. Otherwise, it is modelled after the Cable Device MIB.

With all that said, the right thing to do may in fact be to adopt the
DiffServ MIB for the filtering and/or classification functions in DOCSIS
cable modems, particularly since:
- it supports IPv6 addresses better than the filters in RFC 2669,
- it supports DSCP and flow ID matching better than RFC 2669,
- it supports more flexible traffic classification, and
- it allows cable modems to reuse an existing IETF MIB used outside of
cable.

But take heed that this is a very significant change to a critical modem
function used by most of the cable industry. It's going to take myself and
others some time to figure out how to adopt more/all of the RFC 3289
DiffServ MIB.

Here are two typical cable industry considerations:
- The base DOCSIS 1.1 and 2.0 technology is not yet DiffServ-aware, since it
currently relies on IP ToS masking and ranges for upstream traffic queuing.
There is interest among the cable operators to start to fix this, but that
may take a long time. To see what DOCSIS expects today, see Appendix
C.2.1.5.1 in
<http://www.cablemodem.com/downloads/specs/SP-RFIv1.1-I09-020830.pdf>.
- The standard DOCSIS cable modem is an inexpensive device (e.g. <$100), so
simplicity of implementation is very critical. This might be satisfied by a
simplified MIB compliance for DOCSIS cable modems -- if it is a real issue
here.

If you are volunteering to help us adopt the DiffServ MIB for DOCSIS, then I
accept your help!

I appreciate and support the IETF community's desire to reuse existing work.
In return, please appreciate that this is changing the expectations of our
IPCDN MIBs (and impacting its publication dates) yet again in a very
significant way.

-- Rich

-----Original Message-----
From: Andrew Smith [mailto:ah_smith@acm.org]
Sent: Friday, March 07, 2003 4:06 PM
To: Woundy, Richard; diffserv@ietf.org
Cc: jf.mule@cablelabs.com; narten@us.ibm.com; erik.nordmark@sun.com;
'Wijnen, Bert (Bert)'
Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs

Rich,

You wrote:
...
> I agree with Wilson when he emphasizes that these Dscp objects in the
> various DOCSIS MIB are access filters, not PHB selectors. In fact,
such
> objects enable the DOCSIS equipment to act precisely as "re-marking
boundary
> nodes", which are also described in RFC 2474 Section 3, pages 8-9:
...

If the pieces of DOCSIS equipment are acting as "re-marking boundary
nodes, which are also described in RFC 2474 Section 3, pages 8-9" then
shouldn't they, by definition, be implementing the IETF's existing
Diffserv MIB RFC 3289 in order to control this functionality? I would
hope that your WG would provide a strong argument why IETF should
sanction another MIB for this same purpose when this work comes before
the IESG for consideration.

Andrew Smith

_______________________________________________
diffserv mailing list
diffserv@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html