Subject: review for draft-kaippallimalil-v6ops-ipv6-bbnet-00

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 29 Jul 2008 11:47:21 -0400

I glanced thru this draft.  Please see my comments below. 

1. Is the draft for Standards Track, Informational, or a BCP?

General comment.  Cable wrote a draft to inform IETF of their IPv6
standards when cable was complete with their standards.  Why is DSL
giving an FYI to IETF via this draft when your IPv6 standards are
clearly not completed?

The draft that cable wrote is draft-mule-cablelabs-docsis3-ipv6-00.txt.

2. Why not add the word "Fixed" to the title of the draft since the
draft is 
   dealing with only fixed broadband deployments?

3. I have a problem with the word Broadband in the title of the draft.
The draft
   should not speak for cable broadband deployment. We may want to add
DSL/FTTH or what have you,
   so that the title is totally clear.  Cable also does not need this
draft because cable
   completed such standards for IPv6 two years back.

4. In the Introduction section, you say "aggregation networks".  There
is no RFC from IETF that
   defines what an aggregation broadband network is.  The term used by
IETF is access concentrator
   that is defined in RFC4388.

5. In section 3, 2nd para, what do you mean by the sentence:

   [In the case of a routed RG, the RG authenticates with the network on
behalf of
   the (trusted) hosts behind it.].

   If hosts in the home sit behind a router, the SP doesn't even see
these hosts
   if hosts acquire IPv6 address using SLAAC.  So where does the
question arise
   for "on behalf of hosts"? Am I missing something?

6. This text from the same section seems to be disjoint:

   [In upcoming networks based on IPv6, nomadic or mobile clients that
attach to such
   networks would find it easy to attach

   [RFC4779] describes IPv6 deployment options in a TR-059 architecture
   based on ATM access aggregation. ].

7. Section 4.1: what do you mean by "high address assignment
efficiency"?

8. I would rather that section 4.2 be a sub-section 4.1.2 - that's how
the flow
   of the sub-sections seem to be going. Similarly, section 4.3 should
be 4.1.3.

9. Section 4.2, around text that says:

   [In the routed RG case (1), RG1 configures its link local address and
   obtains a unique prefix in a router advertisement from the IP Edge.
   The address derived using this prefix is used in RG management
   traffic.]

   Why not use SLAAC or DHCPv6 for the management address? Also how is
the address 
   derived - please explain? Same questions for the bridged RG case in
ensuing paragraphs
   of this section.

10. Section 6. What is a sub-router?

11. Figure 7: This level of detail is not need in this draft. Refer to
your TR DSL report 
    for such details. 

12. Figure 9 : Why is there no NS DAD line after "7 DHCP Configuration"?
One needs to perform
    NS DAD for the DHCPv6 address as well.  The draft does say so in
text after the figure,
    but if you bothered to draw a figure, the figure should be complete

Hemant

---

From: Frank Xia <[email-masked]>
Date: Tue, 29 Jul 2008 12:21:16 -0500

Hemant

Thank for your review, please check my inline reply..

BR
Frank

----- Original Message ----- 
From: "Hemant Singh (shemant)" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 29, 2008 10:47 AM
Subject: review for draft-kaippallimalil-v6ops-ipv6-bbnet-00

Frank=>It is intended to be informational. 

Frank=>We would like to make full use of IETF expert resource when
IPv6 depolyment  is being discussed in DSL forum.

The draft that cable wrote is draft-mule-cablelabs-docsis3-ipv6-00.txt.
Frank=>Cable network has many different characteristis from
DSL network, and IMHO, it can't be applied to DSL network directly.

2. Why not add the word "Fixed" to the title of the draft since the
draft is 
   dealing with only fixed broadband deployments?
Frank=>Sound reasonable, let us reconsider.

3. I have a problem with the word Broadband in the title of the draft.
The draft
   should not speak for cable broadband deployment. We may want to add
DSL/FTTH or what have you,
   so that the title is totally clear.  Cable also does not need this
draft because cable
   completed such standards for IPv6 two years back.
Frank=>Now DSL forum has changed it's name to Broadband Forum.
However, I still think you suggest is reasonable.

4. In the Introduction section, you say "aggregation networks".  There
is no RFC from IETF that
   defines what an aggregation broadband network is.  The term used by
IETF is access concentrator
   that is defined in RFC4388.
Frank=>The terms are  used in DSL network.  The readers of the draft
should be both DSL and IETF guys.  Anyway, we should clarify them.

   If hosts in the home sit behind a router, the SP doesn't even see
these hosts
   if hosts acquire IPv6 address using SLAAC.  So where does the
question arise
   for "on behalf of hosts"? Am I missing something?
Frank=>You are right.  We should correct it.  

   [RFC4779] describes IPv6 deployment options in a TR-059 architecture
   based on ATM access aggregation. ].
Frank=>We will check further.

7. Section 4.1: what do you mean by "high address assignment
efficiency"?
Frank=>Due to scarcity of the IPv4 address, hosts
share a subnet even though they are layer 2 seperated from each other.
This priciple does not apply to IPv6, and each host thus can
have a unique prefix.

8. I would rather that section 4.2 be a sub-section 4.1.2 - that's how
the flow
   of the sub-sections seem to be going. Similarly, section 4.3 should
be 4.1.3.
Frank=> It looks no section 4.2 according to your opinion.

   Why not use SLAAC or DHCPv6 for the management address? Also how is
the address 
   derived - please explain? Same questions for the bridged RG case in
ensuing paragraphs
   of this section.
Frank=>It means SLAAC for uptream interface address configuration.
Please pay attention to the texts "obtains a unique prefix in a router 
advertisement from the IP Edge". 
In bridged RG case,  we only illustrate SLAAC case.

10. Section 6. What is a sub-router?
Frank=>It means subnet-router anycast address. It is a reserved
address.

11. Figure 7: This level of detail is not need in this draft. Refer to
your TR DSL report 
    for such details. 
Frank=>We will consider to delete it.

Frank=>OK.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 31 Jul 2008 01:46:36 -0400

>DSL network, and IMHO, it can't be applied to DSL network directly.

I only gave the reference to cable draft to show which one it was.  I
wasn't saying to use it for DSL.  

>Frank=>It is intended to be informational. 

So please fix the draft to say it's Informational.

In general, if DSL needs IETF help, be prepared to have your DSL
standards take a long time.  IETF deals with more generalized devices
and their process can more lengthy than a focused cable standards or DSL
standards body.  I would rather DSL gets experts from routing and
general data networking product companies and also get folks who know
IPv6 cold to work in the DSL Forum directly.  Cable added IPv6 to its
docsis 3.0 standards because we had router and IPv6 folks from Cisco and
Juniper involved in the standards, also cable savvy folks from Cisco,
and DHCPv6 experts like Ralph Droms and Bernie Volz.  That is how
specific deployment standards get done.

Anyhow, your document is not even ready to be picked up by any IETF WG
right now.  

Hemant

---

From: Frank Xia <[email-masked]>
Date: Thu, 31 Jul 2008 09:50:45 -0500

hello Hemant

Please check my reply...

BR
Frank

----- Original Message ----- 
From: "Hemant Singh (shemant)" <[email-masked]>
To: "Frank Xia" <[email-masked]>; <[email-masked]>
Sent: Thursday, July 31, 2008 12:46 AM
Subject: RE: review for draft-kaippallimalil-v6ops-ipv6-bbnet-00

Frank=>sure.

In general, if DSL needs IETF help, be prepared to have your DSL
standards take a long time.  IETF deals with more generalized devices
and their process can more lengthy than a focused cable standards or DSL
standards body.  I would rather DSL gets experts from routing and
general data networking product companies and also get folks who know
IPv6 cold to work in the DSL Forum directly.  Cable added IPv6 to its
docsis 3.0 standards because we had router and IPv6 folks from Cisco and
Juniper involved in the standards, also cable savvy folks from Cisco,
and DHCPv6 experts like Ralph Droms and Bernie Volz.  That is how
specific deployment standards get done.
Frank=>IETF 16NG working group had been working on 
rfc5121"Transmission of IPv6 via the IPv6 Convergence Sublayer
 over IEEE 802.16 Networks" .   This document is the basic IPv6
document for WiMAX.   Of course, some WiMAX experts were
involved in the activity.  As for our draft,  we also presented the 
draft in DSL Forum, and will discuss in the coming DSL meeting.

Hemant