RE: [ipcdn] FW: Dscp and DscpOrAny TCs

Rich,

Thanks for the context - it wasn't clear from the draft or the WG
charter that this was an update to an earlier MIB. I appreciate the
momentum that comes with 20 million deployments!

My comments were aimed exclusively at the CMTS, not the modem: I think a
CMTS probably has a much better chance of supporting the Diffserv MIB,
which sacrifices implementation simplicity for generality in ways that
seemed appropriate for Diffserv switching nodes. I would also assume
that deployment of updates to CMTSs is many orders of magnitude easier
than changes to modems and that backwards-compatibility with RFC 2669 is
also less of an issue.

Regards,

Andrew Smith


-----Original Message-----
From: Woundy, Richard [mailto:[email protected]] 
Sent: Friday, March 07, 2003 2:28 PM
To: 'Andrew Smith'; [email protected]; IPCDN WG (E-mail)
Cc: [email protected]; [email protected]; [email protected];
'Wijnen, Bert (Bert)'
Subject: 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:[email protected]]
Sent: Friday, March 07, 2003 4:06 PM
To: Woundy, Richard; [email protected]
Cc: [email protected]; [email protected]; [email protected];
'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
[email protected]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html