RE: New Version Notification for draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00

["Hemant Singh (shemant)" <[e-mail]>]

Chris, Barbara, and Fred,

Thanks for all your replies.  Indeed, what Wes and I did in our IETF
IPv6 CPE Rtr doc is to try and write one common document that works for
cable, DSL, and even 3GPP legacy wireless data networks (3GPP was
low-hanging fruit for our document because with a few minor additions we
could satisfy their demands).  However, as feedback tells us, one common
document makes it harder for the reader to see what applies to the
reader's, say, cable network or a DSL network.  So it makes sense for us
to add a section or two to our document to list cable reqs in one
section and DSL reqs in another section.  The list format of Chris et
al's document is something great and will take it.

We'd be happy to work with one CableLabs representative like Chris and
merge our work. 

Hemant


-----Original Message-----
From: Chris Donley [mailto:[e-mail]] 
Sent: Thursday, July 23, 2009 4:34 AM
To: Hemant Singh (shemant); [e-mail]
Cc: Wes Beebee (wbeebee)
Subject: RE: New Version Notification for
draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00 

Hemant,

Thanks for your feedback.  

One of the issues that we have with the v6ops CPE Router draft is that
it is hard to tell what is base functionality, what is optional, and
what is architecture-dependent.  We present our draft to the working
group as a complement to the v6ops CPE Router draft to detail our use
cases, architectural assumptions, and requirements. While this draft is
specific to our needs, we believe that most of our draft is applicable
to the wider community, and that a final document should address the use
cases and requirements of the wider community; we don't presume to speak
for the Broadband Forum or other groups, and encourage them to share
their use cases/requirements, as well. 

As you suggested, there is a significant degree of overlap between our
respective drafts.  That is intentional.  We tried to align as much as
possible to avoid confusion. I think you called out the two major
differences in the overlapping use cases - RDNSS support and our
requirement that the CPE router should assume that devices on the WAN
are "not-on-link" unless the L bit is set to 1 (this is intentional -
based on our network topology, we believe that WAN traffic from a CPE
Router should be forwarded to the Service Provider router; if this
differs for other Service Providers, let's discuss). 

We're happy to work with you and the rest of the v6ops WG with the goal
of creating a document that provides clear guidance to vendors as to how
to build a CPE Router that meets the needs of the broader industry
(cable, DSL, etc.), and that could serve as a reference to Service
Providers or other specifications.

Chris

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[e-mail]] 
Sent: Wednesday, July 22, 2009 11:28 AM
To: Chris Donley; [e-mail]
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee)
Subject: RE: New Version Notification for
draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00 

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: [e-mail] [mailto:[e-mail]] On
Behalf Of Chris Donley
Sent: Thursday, July 09, 2009 8:42 PM
To: [e-mail]
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:[e-mail]] 
Sent: Thursday, July 02, 2009 3:28 PM
To: Deepak Kharbanda
Cc: Chris Donley; [e-mail];
[e-mail]; [e-mail];
[e-mail]; [e-mail];
[e-mail]
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.