Subject: Re: RE: Prefix Delegation using ICMPv6

From: <[email-masked]>
Date: Thu, 24 Aug 2006 13:46:40 -0500 (CDT)

Hi Tony, please see my in-line comments:

>> I think the questions should be is there merit in the
>> proposal? 
>
>That is true, but your section 3 does not establish that merit.

Hi Tony, just a reminder from an earlier e-mail that we will be seeking to provide additional detail in section 3 in the future versions of our draft.**

>
>> Does it basically work? 
>
>Probably.
>
>> What needs to be modified for it to work?
>
>The fundamental ND implementation in the CPE router.

We believe the ND modifications we propose would make ICMPv6 PD work.

Having reviewed the draft, how technically sound do you believe our proposal is?

We also need to carefully consider the technical comments made by the group for inclusion in future revisions of our draft. Please let me/us know.

>
>> Our claim is that there are situations and configurations where
>> DHCPv6 may not be enabled or available and hence PD process can not
>> depend on dhcp protocol.
>
>You assert that without attribution. As Ole pointed out you end up
>reinventing DHCP, but masking it behind an ICMP packet format.
>
>>  If the PD mechanism can be run utilizing more
>> basic and fundamental components of the ipv6 stack, why not? 
>
>That would be fine if those components actually exist.

They will exist if this draft is approved.

>The ability to
>receive RS and send RA is not the same as what this proposal calls for.
>
>> If it
>> basically works, and if implementers believe that it is simpler and easy
>> to implement and deploy, it will get used. It does not propose to
>> replace the dhcpv6 based proposal.
>

>The state of DHCP-PD is somewhat irrelevant.

A point we are trying to make is that we are not trying to prove DHCPv6 PD is inherently insufficient, thus calling for its replacement.

We also believe that the two PD methods (DHCPv6 and ICMPv6) are not mutually exclusive. 

>The point is that multiple reviews of the document >will have to be done before it makes it to RFC.

Most definitely. While challenging at times, we do welcome the multiple reviews as we wish to present the best ICMPv6 PD solution possible.

>You appear to be unwilling to expand on the >fundamental justification, and would rather burn list >bandwidth arguing your right to build something >different.

My apologies for contributing to that mistaken impression, Tony. We will expand upon our justification, as noted **.

If there are folks on the list who are fundamentally opposed to this proposal (regardless of justification), they would hopefully say so. We would like to address as many different (types of) concerns as possible.
 
>
>You need to explain why the DHCP-PD packet format is >insufficient

In a case where (for example) SLAAC (or manual configuration) is used for RN addressing, and no other information is required except PD, it seems unnecessary (while perhaps sufficient) to enable/use DHCPv6 just for PD.

>or explain how your state machine sitting behind ICMP >will be significantly simpler than a light-weight >DHCP client.

>'Significant customer demand' is an important metric, >but it is not the only one.

Agreed on both points here, and especially glad you recognize the importance of customer demand.

>Start by showing some willingness to actually work >within the IETF process by rev'ing the draft to
>put substantive detail in section 3.

Absolutely! **

It is also proper for the group to consider the technical soundness of our proposal.

With group input on the philosophical, procedural, and technical front (these are not mutually exclusive, and should be processed in parallel, IMO), we are more likely to provide the community with the best ICMPv6 PD solution possible (which is our goal).

>Tony

Tim
Rom 8:28

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 25 Aug 2006 16:25:26 -0700

[email-masked] wrote:
> Hi Tony, just a reminder from an earlier e-mail that we will be seeking to
> provide additional detail in section 3 in the future versions of our
> draft.**
> ----snip-----

To be blunt:
There is a team of people willing to work on this draft.      + 1 point
The team appears to be passionate about defending the work.   + 1 point
There appears to be well described content in the draft.      + 1 point
Description of the need for this appears to be lacking.       - 5 points
The mail thread is defending the right to develop something 
different, not expanding on the need for something new.       - 5 points
Between the lines; appears to be religious bias against DHCP. - 10 points

Unless we understand the problem we can't evaluate the solution. Lack of
code that implements PD is not a justification, because no code exists for
this approach either. Arguing existing RS/RA/ICMP code fails as well because
the pieces needed to make this work don't exist in any current
implementations. 

I don't care how many solutions we have as long as they solve unique
problems. For your next version of the draft separate out the packet format
issues from the state machine issues. Process FOO needs to acquire a prefix
for the CPE and will use packet format BAR. There is a state machine driving
this that will need to do the same things no matter what FOO ends up being
called. If that state machine is significantly simpler than anything that is
currently defined then you have a basis for expanding on section 3.
Likewise, if the packet format BAR can do something that any other existing
packet formats can't. Keep in mind that a new FOO can send an existing BAR. 

If the issue is centralized vs. distributed management, then say that. If
the whole issue boils down to 'it can't be called DHCP', then we can just
rename the existing tool to PD and be done with it (ie: drop DHCP from the
name).

Tony

---

From: Ralph Droms <[email-masked]>
Date: Fri, 25 Aug 2006 19:35:10 -0400

Just to be clear (and I know you're aware of this, Tony), "lack of code" is
a provably invalid argument in support of developing an alternative to
DHCPv6 PD.  It is simply not true to say that DHCPv6 PD is not implemented
and has not been deployed.  There are multiple server implementations
available today, that run directly in network elements or as a standalone
server, and client implementations available today.  These implementations
are sufficiently robust that they are in use today in commercial
deployments.

- Ralph

On 8/25/06 7:25 PM, "Tony Hain" <[email-masked]> wrote:

> [...] Lack of
> [...]