RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs
"Andrew Smith" <ah_smith@acm.org> Sat, 08 March 2003 00:41 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20191 for <diffserv-archive@odin.ietf.org>; Fri, 7 Mar 2003 19:41:02 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h280ql400682 for diffserv-archive@odin.ietf.org; Fri, 7 Mar 2003 19:52:47 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h280j2O32228; Fri, 7 Mar 2003 19:45:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h280WbO30716 for <diffserv@optimus.ietf.org>; Fri, 7 Mar 2003 19:32:37 -0500
Received: from albatross.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17977; Fri, 7 Mar 2003 19:20:21 -0500 (EST)
Received: from user-11206ng.dsl.mindspring.com ([66.32.26.240] helo=ANDREWLAPTOP) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18rS6Y-0001nX-00; Fri, 07 Mar 2003 16:22:22 -0800
From: Andrew Smith <ah_smith@acm.org>
To: "'Woundy, Richard'" <Richard_Woundy@cable.comcast.com>, diffserv@ietf.org, "'IPCDN WG (E-mail)'" <ipcdn@ietf.org>
Cc: jf.mule@cablelabs.com, narten@us.ibm.com, erik.nordmark@sun.com, "'Wijnen, Bert (Bert)'" <bwijnen@lucent.com>
Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs
Date: Fri, 07 Mar 2003 16:24:13 -0800
Message-ID: <0ad901c2e509$0f2c40e0$1500000a@ANDREWLAPTOP>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <6732623D2548D61193C90002A5C88DCC056637AB@entmaexch02.broadband.att.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-BeenThere: diffserv@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=unsubscribe>
List-Id: Diffserv Discussion List <diffserv.ietf.org>
List-Post: <mailto:diffserv@ietf.org>
List-Help: <mailto:diffserv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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:Richard_Woundy@cable.comcast.com] Sent: Friday, March 07, 2003 2:28 PM To: 'Andrew Smith'; diffserv@ietf.org; IPCDN WG (E-mail) 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 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
- [Diffserv] Dscp and DscpOrAny TCs Wijnen, Bert (Bert)
- Re: [Diffserv] Dscp and DscpOrAny TCs John Schnizlein
- RE: [Diffserv] Dscp and DscpOrAny TCs Andrew Smith
- Re: [Diffserv] Dscp and DscpOrAny TCs Brian E Carpenter
- RE: [Diffserv] Dscp and DscpOrAny TCs Wijnen, Bert (Bert)
- RE: [Diffserv] Dscp and DscpOrAny TCs Andrew Smith
- FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Woundy, Richard
- RE: [Diffserv] Dscp and DscpOrAny TCs Wijnen, Bert (Bert)
- Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… John Schnizlein
- RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Andrew Smith
- RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Andrew Smith
- [Diffserv] simulator for diffserv Sapna Isotupa
- Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… Brian E Carpenter
- RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Woundy, Richard
- RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… Woundy, Richard
- RE: [Diffserv] Dscp and DscpOrAny TCs Woundy, Richard
- RE: [Diffserv] Dscp and DscpOrAny TCs Jean-Francois Mule
- Re: [Diffserv] simulator for diffserv Martin Westhead
- RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… Andrew Smith
- RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… Woundy, Richard