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

[Frank Xia <xiayangsong@huawei.com>]

Hemant

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

BR
Frank

----- Original Message ----- 
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: <v6ops@ops.ietf.org>
Sent: Tuesday, July 29, 2008 10:47 AM
Subject: review for draft-kaippallimalil-v6ops-ipv6-bbnet-00


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

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

Frank=>It is intended to be informational. 

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?

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.


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?
Frank=>You are right.  We should correct it.  

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

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

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
Frank=>OK.


Hemant