RE: New Version Notification for draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00
"Hemant Singh (shemant)" <shemant@cisco.com> Wed, 22 July 2009 17:34 UTC
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720703A68AE for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 22 Jul 2009 10:34:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.668
X-Spam-Level:
X-Spam-Status: No, score=-3.668 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6qbbteG17zq for <ietfarch-v6ops-archive@core3.amsl.com>; Wed, 22 Jul 2009 10:34:02 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F5823A6B35 for <v6ops-archive@lists.ietf.org>; Wed, 22 Jul 2009 10:34:02 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1MTfcZ-0007EW-Pt for v6ops-data0@psg.com; Wed, 22 Jul 2009 17:28:51 +0000
Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from <shemant@cisco.com>) id 1MTfcT-0007E3-TL for v6ops@ops.ietf.org; Wed, 22 Jul 2009 17:28:49 +0000
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAHfpZkpAZnmf/2dsb2JhbAC7GoglkQ0Fgi4FBoFVgUQ
X-IronPort-AV: E=Sophos;i="4.43,248,1246838400"; d="scan'208";a="51369104"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2009 17:28:43 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6MHShge025092; Wed, 22 Jul 2009 13:28:43 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6MHSh1Z016566; Wed, 22 Jul 2009 17:28:43 GMT
Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 13:28:43 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: New Version Notification for draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00
Date: Wed, 22 Jul 2009 13:28:17 -0400
Message-ID: <B00EDD615E3C5344B0FFCBA910CF7E1D07A0270F@xmb-rtp-20e.amer.cisco.com>
In-Reply-To: <B1ED8A2E683E16479C92C3F4AE13677B01E1A92E@srvxchg3.cablelabs.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: New Version Notification for draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00
Thread-Index: Acn7W/u2rcwANIFtQXSBqhC268bJTAFSADIAApBX8BA=
References: <B1ED8A2E683E16479C92C3F4AE13677B01E1A92E@srvxchg3.cablelabs.com>
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: Chris Donley <C.Donley@cablelabs.com>, v6ops@ops.ietf.org
Cc: "Hemant Singh (shemant)" <shemant@cisco.com>, "Wes Beebee (wbeebee)" <wbeebee@cisco.com>
X-OriginalArrivalTime: 22 Jul 2009 17:28:43.0507 (UTC) FILETIME=[DC6DF430:01CA0AF1]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12617; t=1248283723; x=1249147723; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20<shemant@cisco. com> |Subject:=20RE=3A=20New=20Version=20Notification=20for=20dr aft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00=20 |Sender:=20 |To:=20=22Chris=20Donley=22=20<C.Donley@cablelabs.com>,=20< v6ops@ops.ietf.org>; bh=iSrpq03EcD7TZP5dTiFM5hWJjcjV8HSBg5ojuPsPf5s=; b=u5ZzzsrmWq7IQtz9vRLDGYizhYxcK7nmzjy3k8+ApsNQNcAT6XHiRLB0l3 /4QBp4/13SRdpUXF30UpJv+0wMBA0W2ax+LKaeh5lcGoAI7RVhjrCbzi5TDI PvU9mdroQk;
Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>
I am on vacation till end of this month, but before the next IETF started, I thought I'd review this document. After an hour or so, I won't be able to reply to any emails because I am off to the hills in India for hiking. I hope to check email by end of Sunday or Monday. I really do not understand why this draft was authored especially since it's been one year since our IETF CPE Rtr doc has been around? I would recommend the CableLabs and cable community to work just like the DSL Forum folks have worked with the IETF CPE Rtr doc. The DSL Forum folks have given v6ops formal liaison docs for what they would like to see in the IETF CPE Rtr doc. They have also given us an Excel spreadsheet of copious requirements. The other point is that we thought we had all cable requirements already covered in the IETF CPE Rtr doc, so why this new document? Please see detailed review below for what I mean. This doc is also cable specific and won't work for DSL or wireless, etc. even though this doc claims it should work for other networks. I also do not see any use case in this document that is not discussed in the IETF CPE Rtr doc. Lastly, the document has few gross mistakes. Detailed review is below in a style where some text from the doc is included within square brackets with my comment below the text. The Abstract says [This document captures use cases and associated requirements for an IPv6 Customer Premises Equipment (CPE) router. Specifically, the current version of this document focuses on the provisioning of an IPv6 CPE router and the provisioning of IPv6 Home Devices attached to it.] <hs> Already covered in the IETf IPv6 CPE Rtr draft. [It also addresses IPv6 traffic forwarding and IPv6 CPE Router security.] <hs> Traffic forwarding is covered by generic IPv6 RFCs and whatever else needed on a specific basis for forwarding behavior is discussed in IETF CPE Rtr draft. Security is covered by the Woodyatt draft, so why is this draft needed? [This document also identifies areas for future consideration. These areas include prefix sub-delegation, IPv6 multicast, transition and tunneling mechanisms, provisioning consistency between DHCPv4 and DHCPv6, and DNS support.] <hs> All covered in the IETF CPE Rtr draft. So why is this draft needed? [This document does not address IPv4 use cases or requirements, as they are widely understood; however, it is expected that IPv6 CPE Routers will also support IPv4.] <hs> Again, also mentioned by the IETF CPE Rtr doc - so why is this draft needed? <hs> Intro section text is already included in the IETF CPE Rtr draft. <hs> In the Terminology section where a term is defined and if the term is common to the IETF CPE Rtr doc, the IETF CPE Rtr has a better definition and this doc has a essentially the same definitions as IETF CPE Rtr. For example, our document clearly discusses bridged, switched and routed ports on the LAN while this doc does not. <hs> WAN Interface specification is a broken cable Labs definition - why single interface? We have already discussed this issue in v6ops last year and the IETF CPE Rtr already allows for more than one WAN interface. See what a document maintenance nightmare two docs create because your new doc says WAN is a single interface while the IETF CPE Rtr says the WAN can have more than one interfaces. Single WAN interface is cable specific but the document claims doc can be used for other deployments like DSL, etc. <hs> Why is the cable community writing a draft when they can submit a liaison statement to the IETF like the DSL folks did? All authors are the cable community that was the closed body that developed the eRouter specification. This is the same reason why the closed body in CableLabs did not produce a document with more peer review and thorough work. I suggest the cable community produce merely a document that presents requirements or better still, tell us why use case or req did the current IETF CPE Rtr not cover that their new doc is needed? <hs> WAN interface text is already included in the IETF CPE Rtr definition set. <hs> Section 3 - the section has totally removed the core PPPOE DSL requirement - hence this document is reeking of being cable specific. <hs> Section 3 - remove the following sentence from the doc [When offering stateful DHCPv6, the Service Provider may use multiple DHCPv6 servers to provide redundancy.] <hs> The IPv6 CPE Rtr specification has nothing to do with SP provisioning services or the SP premises equipment redundancy. <hs> Section 3: Again, when the ULA has been thrashed out in v6ops with the IETF CPE Rtr draft, this new draft is making ULA optional when the IETF CPE Rtr has ULA as mandatory. This is a mistake in this new doc. The mistake has carried over from CableLabs eRouter specification where the community totally missed that fact that a CPE Rtr always (at least the most common v4 home routers I have seen) includes a bridge that is active soon as the Rtr is powered up - even in an embedded router. Further this doc claims to include a specification for both standalone and embedded router. Well, for a standalone router, if this doc says ULA is optional, how is the CPE Rtr getting configured without ULA? ULA is a MUST requirement for the CPE Rtr. <hs> Title of section 4.1.2.1 is not proper - an IPv6 node does not obtain a Link-local address. The Link-local is created by the node. The title should change. Information in this section is already included in the IETF CPE Rtr doc. Also, this section is also very cable specific because this section did not consider the fact that in PPP networks the DAD DupAddrDetectTransmits is 0. Interesting that this document claims the doc should be applicable for all networks like cable, DSL, wireless, but in this section the document has clearly not considered the DSL network with PPP and DupAddrDetectTransmits of zero while our IETF CPE Rtr document has. <hs> Section 4.1.2.3 first paragraph uses a term of "the prefix advertisement options". There is no such term in IPv6 RFC's. The correct term to use here is "the prefix information option". <hs> Interesting that a cable network has clients in the home network as always off-link to each other, so why would the cable network even need to specify on-link prefixes? [Because many Internet access topologies for home users require that traffic be sent to the Service Provider's router, if the prefix advertisement has the L bit set to 0, the CPE Router SHOULD identify the prefix as "not-on-link" and forward traffic destined for that prefix to the router.] <hs> Very basic mistake in the text above. IPv6 ND as specified by RFC 4861 has no means to specify a prefix as "not on-link". So L=0 mention above in relation to not on-link is incorrect. Section 4.1.2.3 says [The CPE Router SHOULD request values for the following options through DHCP: Client Identifier, IA_NA, IA_PD, Reconfigure Accept, and Options Request Option for the DNS Recursive Name Server, [RFC3646] and the Container Option for Server Configuration [I-D.ietf-dhc-container-opt]. The CPE Router MAY also accept and request additional information via DHCP.] <hs> The IETF CPE Rtr doc already includes most of these options. The ones that are enumerated in this doc but not included in the IETF CPE Rtr is the Contain Option. The IETF CPE Rtr did not include it since it's not an RFC. Such an option will move to the secondary CPE Rtr draft that includes references to any Work in Progress in the IETF. <hs> Section 4.2.1. has nothing new over the IETF CPE Rtr document except for RDNSS. RDNSS has been discussed in v6ops for the IETF CPE Rtr doc but no consensus was reached that RDNSS is needed. Till that consensus is achieved, any CPE Rtr doc should not mention this work. <hs> Section 4.3.2 - 2nd paragraph should be removed from the section because RFC 4943 has been folded into RFC 4861. <hs> Section 4.3.1 - poorly specified section. If routing is discussed one must discuss routing on the WAN as well as LAN side and also name what routing protocols. Anyway, the IETF CPE Rtr doc already discusses routing in copious details. <hs> Section 4.4 - all such security is already included in the IETF CPE Rtr doc. <hs> Section 5 - some DHCPv6 options have been TBD in the IETF CPE Rtr doc. SNTP and Information Refresh Time Option can be added to the IETF CPE Rtr doc. <hs> CRP-REQ1 is already a mandate specified in RFC 4862. Again, there is no such thing as a prefix advertisement option in RFC 4861. This req is also debatable because as pointed out in an earlier comment no client in a cable network is on-link to another client. So where does a on-link req come out from? <hs> CRP-REQ3 is already mandated in the IETF CPE Rtr doc. <hs> CRP-REQ4 - the IETF CPE Rtr doc already includes such a req. <hs> CRP-REQ5 - over specification! DHCPV6 RFC already includes such mandates. <hs> CRP-REQ6 - the IETF CPE Rtr doc already includes such a req. <hs> Section 6.1.1 - the IETF CPE Rtr doc already includes a mcast section. <hs> Section 6.1.2 - the IETF CPE Rtr doc already includes some of such specifications. Vendor class is cable specific documents and does not apply to DSL or wireless. Again an instance in this doc where the doc is cable specific but the doc claims it can apply to other networks as well. <hs> Section 7.2 - the IETF CPE Rtr doc already includes such a section. <hs> Section 7.3 - the IETF CPE Rtr doc already includes a mcast section. <hs> Section 7.4 - Provisioning consistency does not seem to be a useful section at all since a typical client identifier in a residential/SOHO network is the mac-addr which has got to be same between DHCPv4 and DHCPv6. <hs> Section 7.4 - this document has missed what was discussed at the San Francisco IETF that the IETF CPE Rtr doc be broken up into two drafts where the first draft (a v6ops WG work item) would not discuss any Work in Progress and move such pending work to the 2nd draft so that the first draft can be fast tracked thru the IETF. DS-Lite being discussed in this section is clearly a Work in Progress and hence has no business to be in this draft as well. Same comment for NAT64 # Section 7.5 is redundant with the IETF CPE Rtr doc. Hemant -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Chris Donley Sent: Thursday, July 09, 2009 8:42 PM To: v6ops@ops.ietf.org Subject: FW: New Version Notification for draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00 Hello, We just posted a new draft, "Use Cases and Requirements for an IPv6 CPE Router," draft-donley-ipv6-cpe-rtr-use-cases-and-reqs. We would appreciate your feedback. Thanks, Chris -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Thursday, July 02, 2009 3:28 PM To: Deepak Kharbanda Cc: Chris Donley; john_brzozowski@cable.comcast.com; yiu_lee@cable.comcast.com; jason.weil@cox.com; kirk.erichsen@twcable.com; william.howard@twcable.com; trembjfr@videotron.com Subject: New Version Notification for draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00 A new version of I-D, draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00.txt has been successfuly submitted by Deepak Kharbanda and posted to the IETF repository. Filename: draft-donley-ipv6-cpe-rtr-use-cases-and-reqs Revision: 00 Title: Use Cases and Requirements for an IPv6 CPE Router Creation_date: 2009-07-02 WG ID: Independent Submission Number_of_pages: 24 Abstract: This document captures use cases and associated requirements for an IPv6 Customer Premises Equipment (CPE) router. Specifically, the current version of this document focuses on the provisioning of an IPv6 CPE router and the provisioning of IPv6 Home Devices attached to it. It also addresses IPv6 traffic forwarding and IPv6 CPE Router security. This document also identifies areas for future consideration. These areas include prefix sub-delegation, IPv6 multicast, transition and tunneling mechanisms, provisioning consistency between DHCPv4 and DHCPv6, and DNS support. This document does not address IPv4 use cases or requirements, as they are widely understood; however, it is expected that IPv6 CPE Routers will also support IPv4. The IETF Secretariat.
- FW: New Version Notification for draft-donley-ipv… Chris Donley
- RE: New Version Notification for draft-donley-ipv… Stark, Barbara
- RE: New Version Notification for draft-donley-ipv… Jean-Francois.TremblayING
- RE: New Version Notification for draft-donley-ipv… Stark, Barbara
- RE: New Version Notification for draft-donley-ipv… Chris Donley
- RE: New Version Notification for draft-donley-ipv… Chris Donley
- RE: New Version Notification for draft-donley-ipv… Stark, Barbara
- RE: New Version Notification for draft-donley-ipv… Alan Kavanagh
- RE: New Version Notification for draft-donley-ipv… Wes Beebee (wbeebee)
- RE: New Version Notification for draft-donley-ipv… Hemant Singh (shemant)
- RE: New Version Notification for draft-donley-ipv… Hemant Singh (shemant)
- RE: New Version Notification for draft-donley-ipv… Wes Beebee (wbeebee)
- Re: New Version Notification for draft-donley-ipv… Fred Baker
- RE: New Version Notification for draft-donley-ipv… Stark, Barbara
- RE: New Version Notification for draft-donley-ipv… Chris Donley
- Re: New Version Notification for draft-donley-ipv… Brian E Carpenter
- RE: New Version Notification for draft-donley-ipv… Wes Beebee (wbeebee)
- RE: New Version Notification for draft-donley-ipv… Chris Donley
- Re: New Version Notification for draft-donley-ipv… Fred Baker
- RE: New Version Notification for draft-donley-ipv… Hemant Singh (shemant)
- RE: New Version Notification for draft-donley-ipv… Mikael Abrahamsson
- RE: New Version Notification for draft-donley-ipv… Chris Donley
- RE: New Version Notification for draft-donley-ipv… Wes Beebee (wbeebee)