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

From: "Chris Donley" <[email-masked]>
Date: Thu, 9 Jul 2009 09:11:41 -0600

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:[email-masked]] 
Sent: Thursday, July 02, 2009 3:28 PM
To: Deepak Kharbanda
Cc: Chris Donley; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
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.

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 9 Jul 2009 14:06:03 -0400

Thanks for this draft. I think you present some interesting ideas, and I
found the format to be very readable.

Several DSL providers are considering using an "unnumbered" model on the
WAN interface. This means that the CPE Router will not be given a GUA
address through either SLAAC or DHCPv6. If the CPE Router isn't given an
address through SLAAC or DHCPv6, then it's expected to use an address
from the delegated prefix for any applications that need to communicate
with the WAN. This address would not be associated with the WAN
interface, but with some other interface (a LAN interface, an internal
physical or logical interface, a loopback interface, etc.). Any CPE
Router that expects to work on a random DSL provider's network would
need to be able to handle this scenario.

This is the only element of your draft that I saw that would actually be
incompatible with some DSL access networks.

There are some other differences, however, between your draft and the
design decisions that some DSL providers are making for their CPE
routers. Here are some that may interest you:
 - because the CPE router is always expected to do a DHCPv6 message
sequence to get the PD, it's been suggested that the RS/RA and DHCPv6
message sequences can be started at the same time; in this case, the M
and O bits are ignored by the CPE Router and the DHCPv6 solicit always
includes the IA_NA and IA_PD options. If the RA includes prefixes for
SLAAC, the Router does SLAAC. If the DHCPv6 response includes an address
for IA_NA, then the Router uses that. (If both, then both, but hopefully
a provider's network won't do that). If neither, then the Router takes
an address from the PD prefix. This shortens the time to completion of
setup (parallel RS/RA and DHCPv6, instead of sequential) and allows the
CPE router logic to be simpler (the DHCPv6 messages are always the
same). The service provider has complete control over whether the DHCPv6
server does or doesn't provide a GUA in response to the IA_NA option. I
would be curious to know if a cable access network might react badly to
a CPE Router that did this. That is, if a consumer plugged such a Router
from a DSL provider (many of these routers have Ethernet WAN interfaces)
into a bridged cable modem, would there be a problem?
 - if DAD fails, it may be a good idea to try a different address,
before giving up; vendors are encouraged to provide more graceful
handling of DAD failures, than terminating operation on the interface. 

As an additional comment, I see that SHP-REQ5 requires the CPE Router to
set the O flag to 0 in its RA if it does RDNSS (RFC 5006) in that RA.
And SHP-REQ4 suggests that the CPE Router pass along additional options
that it got from WAN DHCPv6. Since the RDNSS option only provides DNS,
and the DHCPv6 message (from the WAN) might contain all sorts of other
information, I'm curious as to why you don't think the Router should let
LAN hosts know about the availability of additional options by setting O
to 1.

Barbara

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Chris Donley
> Sent: Thursday, July 09, 2009 11:12 AM
> To: [email-masked]
> Subject: FW: New Version Notification for draft-donley-ipv6-cpe-rtr-
> use-cases-and-reqs-00
> 
> Hello,
>

---

From: [email-masked]
Date: Fri, 10 Jul 2009 14:28:45 -0400

Hello Barbara. 
Thank you for your comments. 

Concerning the O flag with RDNSS, you're absolutely right, the O bit could 
be set to 1 if other pertinent information is available. We should modify 
it to say "O flag could be set to 0 if no other additional information 
than recursive DNS servers is available by DHCPv6". 

For the DAD graceful failure, do you have any idea of what other address 
could be used? Maybe if 2 DHCPv6 ADVERTISE were received from different 
servers, another REQUEST could be sent to the second server. Otherwise I 
don't see how we could make the DAD failure more graceful. 

And last, concerning RS and DHCPv6 in parallel, it looks like a good idea. 
The draft was designed with a provisioning model very close to the current 
CableLabs specifications for IPv6 cable modem provisioning, where both 
operations are done in sequence. Since this is a CPE spec, nothing IMHO 
would prevent the two operations to be done in parallel. 

Jean-Francois Tremblay
Videotron

"Stark, Barbara" <[email-masked]> 
Envoyé par : [email-masked]
2009-07-09 14:47

A
"Chris Donley" <[email-masked]>, <[email-masked]>
cc

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

Barbara

> Title:                                  Use Cases and Requirements for 
an IPv6 CPE
Router

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 10 Jul 2009 15:48:35 -0400

> For the DAD graceful failure, do you have any idea of what other
address could be used?
> Maybe if 2 DHCPv6 ADVERTISE were received from different servers,
another REQUEST could 
> be sent to the second server. Otherwise I don't see how we could make
the DAD failure 
> more graceful.

The draft only mentions DAD in relationship to the Link Local address
(4.1.2.1), so that's the usage I was commenting on. Presumably, DAD
would be used for all unicast addresses, before they're assigned to an
interface, consistent with RFC 4862. I hadn't really thought about what
to do if DAD fails on an address assigned via DHCPv6. That's kind of
weird. I suspect the CPE Router might do best to wait some interval and
try DHCPv6 again. Let the access network get its head on straight and
try to recover from whatever possessed it to do that.

For Link Local DAD failure, I haven't seen any precise suggestion for
exactly what to do. But RFC 4862 says if DAD fails, "If the address is
derived from an interface identifier, a new identifier will need to be
assigned to the interface, or all IP addresses for the interface will
need to be manually configured". I was hoping that vendors could play
around with figuring out some decent way to automatically assign a
different Interface ID for Link Local DAD failure on their CPE Routers.

The draft doesn't discuss or ask about SLAAC GUA DAD failure. I guess
that should be pretty easy for the CPE Router to just come up with
something different there, and try again.

I just don't think that single DAD failure on Link Local should
terminate that IPv6 interface. Multiple failures would be scary. Even
single failure shouldn't happen. But I don't think there's harm in
handling it gracefully. At least try a couple of times to assign a
different Interface ID automatically.
Barbara

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: "Chris Donley" <[email-masked]>
Date: Fri, 10 Jul 2009 14:05:13 -0600

Barbara,

Thanks for the feedback. We know that there are additional use cases
beyond the ones we documented. We appreciate you bringing up the
unnumbered case; we'll work to resolve the incompatibility in a future
revision.   

Also, As Jean-Francois noted, we expect that the CPE router will include
the IA_NA and IA_PD simultaneously.  We are a bit concerned about having
the CPE router ignore the M/O bits in the RA - we want more control over
the device provisioning, and specifically do not want MSO-managed
devices to provision using SLAAC on the WAN side.  

Chris

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: Thursday, July 09, 2009 12:06 PM
To: Chris Donley; [email-masked]
Subject: RE: New Version Notification for

Barbara

---

From: "Chris Donley" <[email-masked]>
Date: Fri, 10 Jul 2009 14:44:15 -0600

Regarding the link-local DAD failure on the WAN interface, we expect the
CPE router to use an EUI-64 address, and included a requirement for it
to "give up" if it detects a duplicate address to make the WAN-side
provisioning process more predictable. I think you're right that we
might want to be more graceful on the LAN side - we could clarify that
going forward.  

Regarding DHCPv6 DAD failure, we expect the device to send a DHCPv6
Decline, stop using the address, and restart the IPv6 provisioning
process, along the lines you suggest; however, we opted to remain silent
in this draft, in case vendors or operators have other ideas. Likewise,
we remained silent in the SLAAC case for similar reasons.

Chris

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: Friday, July 10, 2009 1:49 PM
To: [email-masked]
Cc: Chris Donley; [email-masked]
Subject: RE: New Version Notification for

address could be used?
another REQUEST could 
the DAD failure 

*****

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by
persons or entities other than the intended recipient is prohibited. If
you received this in error, please contact the sender and delete the
material from all computers. GA625

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 10 Jul 2009 16:50:45 -0400

> We are a bit concerned about
> having

It seems to me that the way to prevent SLAAC for GUA on the WAN side is
for the access network to not include any Prefix-Information options
with Autonomous flag set in the RA. I don't see where the M/O flags have
any control at all over whether the CPE Router does SLAAC. If the RA has
valid prefixes (per RFC 4862) in a Prefix-Information option with
Autonomous flag set, then the device is going to do SLAAC on those
prefixes. If the RA doesn't, then the device won't. M and O are
irrelevant for SLAAC.

The only thing M might have an effect on is whether the CPE Router
includes IA_NA in its DHCPv6 Solicit. But I figure if the CPE Router
always puts IA_NA in its DHCPv6 Solicit, then the access network has
complete control over whether to provide an IA_NA address back to the
CPE Router. 

Simple, effective, and the access network is in complete control over
how the device gets its address.

BTW, in Broadband Forum, we had extensive discussion on M and O. It was
very educational for me. If you like, I can send you more about that,
but I don't want to bore this list with that.
Barbara

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

---

From: "Alan Kavanagh" <[email-masked]>
Date: Wed, 15 Jul 2009 11:56:37 -0400

So is the proposal then to mandate the CPE Router behaviour upon receipt
of the M and O bits being set/unset?

Also, is this draft applicable to "all CPE routers" and not just for
cablelabs requirements? 

I sincerely hope that assigning a Globally Unique IPv6 Address from
DHCPv6 would ensure uniqueness of that ipv6_address and similarly for PD
for prefixes, so I don't see any concern if DAD should fail for the
globally unique ipv6 addresses coming for a dhcov6 server.

Similarly, given that wes beebee and Hemant have an IPv6 CPE Router
Recommendation draft, would it be best to take the use cases and add
them to that draft? I would not like to see two drafts for CPE Router
Recommendations.

Alan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chris Donley
Sent: July 10, 2009 4:05 PM
To: Stark, Barbara; [email-masked]
Subject: RE: New Version Notification for
draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00 

Barbara,

Chris

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]]
Sent: Thursday, July 09, 2009 12:06 PM
To: Chris Donley; [email-masked]
Subject: RE: New Version Notification for

Barbara

> draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00.txt has been 
> successfuly submitted by Deepak Kharbanda and posted to the IETF 
> repository.
> 
> 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.
> 
>

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 15 Jul 2009 12:48:52 -0400

Since the CPE Router draft is a Working Group work item, we would be
happy to include any use cases/requirements that the Working Group
agrees should be in the draft.

- Wes 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alan Kavanagh
Sent: Wednesday, July 15, 2009 11:57 AM
To: Chris Donley; Stark, Barbara; [email-masked]
Subject: RE: New Version Notification for
draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00 

Alan 

-----Original Message-----

Barbara,

Chris

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]]
Sent: Thursday, July 09, 2009 12:06 PM
To: Chris Donley; [email-masked]
Subject: RE: New Version Notification for

Barbara

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 22 Jul 2009 13:28:17 -0400

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Chris Donley
Sent: Thursday, July 09, 2009 8:42 PM
To: [email-masked]
Subject: FW: New Version Notification for
draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00 

Hello,

Thanks,
Chris

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Thursday, July 02, 2009 3:28 PM
To: Deepak Kharbanda
Cc: Chris Donley; [email-masked];

A new version of I-D,

Abstract:

The IETF Secretariat.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 22 Jul 2009 13:32:58 -0400

The fact should be clear from my email below, but in case it is not, I
am saying, for this IETF in Stockholm, I just cannot agree to accept
this document as a v6ops working group work item.  

Hemant

-----Original Message-----
From: Hemant Singh (shemant) 
Sent: Wednesday, July 22, 2009 10:58 PM
To: Chris Donley; [email-masked]
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee)
Subject: RE: New Version Notification for

The Abstract says

Section 4.1.2.3 says

Hemant

-----Original Message-----

Hello,

Thanks,
Chris

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Thursday, July 02, 2009 3:28 PM
To: Deepak Kharbanda
Cc: Chris Donley; [email-masked];

A new version of I-D,

Abstract:

The IETF Secretariat.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 22 Jul 2009 13:52:23 -0400

This work may be subsumed by the IPv6 CPE Router working group item
(merged into one document) - ie., we may go through this document and
add sections in the CPE Router document which lists requirements and use
cases - and make sure that everything that that document intended to
accomplish is accomplished by the CPE Router document.

Your thorough review will hopefully make the process easier.

Thanks,
- Wes

-----Original Message-----
From: Hemant Singh (shemant) 
Sent: Wednesday, July 22, 2009 1:33 PM
To: Hemant Singh (shemant); 'Chris Donley'; [email-masked]'
Cc: Wes Beebee (wbeebee)
Subject: RE: New Version Notification for

Hemant

-----Original Message-----
From: Hemant Singh (shemant)
Sent: Wednesday, July 22, 2009 10:58 PM
To: Chris Donley; [email-masked]
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee)
Subject: RE: New Version Notification for

The Abstract says

Section 4.1.2.3 says

Hemant

-----Original Message-----

Hello,

Thanks,
Chris

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Thursday, July 02, 2009 3:28 PM
To: Deepak Kharbanda
Cc: Chris Donley; [email-masked];

A new version of I-D,

Abstract:

The IETF Secretariat.

---

From: Fred Baker <[email-masked]>
Date: Wed, 22 Jul 2009 10:54:59 -0700

On Jul 22, 2009, at 10:28 AM, Hemant Singh (shemant) wrote:

> 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?

The implication I draw as working group chair is that the document you  
have written doesn't quite do it for Chris or his organization; if it  
did, he would have no motivation to write one. The liaison from BBF  
suggests that they also have concerns with the WG document - something  
we already knew from their previous communications.

This response makes me wonder whether we are ready to draw together a  
working group document. I had hoped that we could have a f2f meeting  
in Stockholm between the interested parties, but that clearly won't  
happen. How would you suggest we proceed to consensus around a  
document? "Use mine" is a non-answer in the circumstance.

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 22 Jul 2009 17:45:13 -0400

>From my perspective, there are several *possible* goals for the working
group CPE Router draft.
1. It must do no harm. It must not say things that would make it not
operate in a common consumer broadband environment. It also shouldn't
say things that are antithetical to behavior that a major industry group
is specifying for devices intended to meet the needs of its
constituency. Fortunately, I think the current WG draft is pretty good
on this front.
2. Encourage discussion and debate, to help us all hammer out some of
these issues before we put this equipment in the hands of the average
consumer. I'm pretty happy with where that's going.
3. Provide a meaningful document that can be used by the makers of
retail CPE Routers. Right now, I think the current WG draft provides
pretty good general guidance. But it's hard to read, and isn't done in a
way as to create testable requirements, or to make individual elements
easy to reference. The individual draft from CableLabs et al was very
readable and well-laid-out. It had enumerated requirements. The
requirements were concisely stated. And then it collected all the
requirements again at the end into an appendix. I might not have liked
or agreed with everything it said, but I was easily able to understand
what it was saying, and even why it was saying that. It was very easy
for me to note elements that I disagreed with and discuss them. I'm
really glad they submitted this informational individual contribution to
the WG, rather than just providing comments against the WG draft. 
4. Provide a meaningful document that can be used as a reference (within
other requirements documents or RFPs) by industry groups and companies
that source equipment. This again, requires readability and good
organization. There may be conflicting needs between goals 3 and 4. If
both are goals, then addressing these conflicting needs will be
important.
Barbara

> Behalf Of Fred Baker
> Sent: Wednesday, July 22, 2009 1:55 PM
> To: Hemant Singh (shemant)
> Cc: Chris Donley; IPv6 Operations; Wes Beebee (wbeebee); Ralph Droms
> Subject: Re: New Version Notification for draft-donley-ipv6-cpe-rtr-
> use-cases-and-reqs-00
> 
> 

*****

---

From: "Chris Donley" <[email-masked]>
Date: Wed, 22 Jul 2009 17:03:41 -0600

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:[email-masked]] 
Sent: Wednesday, July 22, 2009 11:28 AM
To: Chris Donley; [email-masked]
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee)
Subject: RE: New Version Notification for

The Abstract says

Section 4.1.2.3 says

Hemant

-----Original Message-----

Hello,

Thanks,
Chris

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Thursday, July 02, 2009 3:28 PM
To: Deepak Kharbanda
Cc: Chris Donley; [email-masked];

A new version of I-D,

Abstract:

The IETF Secretariat.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Jul 2009 13:03:46 +1200

Chris,

On 2009-07-23 11:03, Chris Donley wrote:
> possible to avoid confusion. 

But I'm afraid that's impossible. Two overlapping documents = confusion,
by definition. I think the only reasonable goal is a combined document,
or possibly two complementary documents.

It's very encouraging to see use-case driven work in this area of course.
It would be well worth while the effort of integrating the two drafts.

    brian

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Thu, 23 Jul 2009 09:15:42 -0400

Regarding #3 -

Do you think we can satisfy this requirement in the WG draft by adding a
section entitled "Requirements" and another section entitled "Use cases"
and follow the same type of structure as the CableLabs draft?  That way,
anyone interested in a short list of requirements could just go to the
Requirements section and immediately know what's required.  Then, the
task going forward is to always make sure that the rest of the document
is kept in sync with that section.

- Wes

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: Wednesday, July 22, 2009 5:45 PM
To: Fred Baker (fred); Hemant Singh (shemant)
Cc: Chris Donley; IPv6 Operations; Wes Beebee (wbeebee); Ralph Droms
(rdroms)

group CPE Router draft.

*****

---

From: "Chris Donley" <[email-masked]>
Date: Thu, 23 Jul 2009 09:41:50 -0600

Brian,

We'd be amenable to that approach (combining the documents, if
possible).

Chris

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Wednesday, July 22, 2009 7:04 PM
To: Chris Donley
Cc: Hemant Singh (shemant); [email-masked]; Wes Beebee (wbeebee)
Subject: Re: New Version Notification for

Chris,

It's very encouraging to see use-case driven work in this area of
course.
It would be well worth while the effort of integrating the two drafts.

    brian

---

From: Fred Baker <[email-masked]>
Date: Sat, 25 Jul 2009 00:40:10 +0200

> or possibly two complementary documents.

Here I have to agree. The preferred outcome is either one draft that  
covers the subject or two drafts on different aspects of the topic.  
Part of the working group discussion will be to determine the  
appropriate way forward.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 26 Jul 2009 10:21:12 -0400

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:[email-masked]] 
Sent: Thursday, July 23, 2009 4:34 AM
To: Hemant Singh (shemant); [email-masked]
Cc: Wes Beebee (wbeebee)
Subject: RE: New Version Notification for

Hemant,

Chris

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: Wednesday, July 22, 2009 11:28 AM
To: Chris Donley; [email-masked]
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee)
Subject: RE: New Version Notification for

The Abstract says

Section 4.1.2.3 says

Hemant

-----Original Message-----

Hello,

Thanks,
Chris

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Thursday, July 02, 2009 3:28 PM
To: Deepak Kharbanda
Cc: Chris Donley; [email-masked];

A new version of I-D,

Abstract:

The IETF Secretariat.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 26 Jul 2009 23:51:47 +0200 (CEST)

On Sun, 26 Jul 2009, Hemant Singh (shemant) wrote:

> could satisfy their demands).

I'd just want to clarify that my intent in my opinions regarding this 
draft was to make it work in ETTH deployments as well. I hope this was 
just an omission in listing technologies and not a statement from the 
authors regarding the intents of the document to exclude ETTH?

I don't know the extent of L2 switches used in delivering ETTH across the 
world, but I'd guess it's in the millions of subscribers getting their 
Internet access this way.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Chris Donley" <[email-masked]>
Date: Mon, 27 Jul 2009 01:06:44 -0600

>From our perspective, it was an inadvertent omission.  We're happy to rectify that in the future.

Chris

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 27 Jul 2009 10:26:20 -0400

If you have specific requirements from the ETTH world that are not being
covered by other deployments, then we would be happy to include them.

- Wes 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mikael Abrahamsson
Sent: Sunday, July 26, 2009 5:52 PM
To: [email-masked]
Subject: RE: New Version Notification for
draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00

On Sun, 26 Jul 2009, Hemant Singh (shemant) wrote:

> 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).

I don't know the extent of L2 switches used in delivering ETTH across
the world, but I'd guess it's in the millions of subscribers getting
their Internet access this way.