Subject: Re: Re: Prefix Delegation using ICMPv6

From: <[email-masked]>
Date: Thu, 24 Aug 2006 19:23:29 -0500 (CDT)

Hi Thomas, please see my comments in-line:

>From: Thomas Narten <[email-masked]>
>Date: 2006/08/24 Thu AM 10:26:19 CDT
>To: [email-masked]
>Cc: Ralph Droms <[email-masked]>, 
	"Durand,    Alain" <[email-masked]>, 
	IETF IPv6 Mailing List <[email-masked]>
>Subject: Re: Prefix Delegation using ICMPv6

>> Hi Ralph, why is it hard to talk about the e-mail without "more detail"?
>
>> Do you believe that it is theoretically possible that DHCPv6 PD
>> would be "neither required nor desired"?
>
>Please make the case here (using technical justifications).

I'd like to clarify that "neither required nor desired" was meant to be from the customer's point of view. Further info regarding customer requirements and the rationale for them will be included in future versions of the draft.

Customer requirements, as well as technical reasons, are both valid types of reasons. Do you agree?

Also, please first tell us what you think of the cases we made in the first revision of the draft. With specifics on where folks see them lacking (both technical and otherwise), we will be better equipped to provide answers (both in subsequent draft revisions, and even on this list).

 Basic the
>need for a new protocol on theoretical possibilities has repeatedly
>been problematic in the IETF.

Our proposal is not based on theoretical possibilites. Customers have expressed interest in an alternative IPv6 PD mechanism.

>
>> It is here that I'd like to start this portion of our conversation.
>
>I would not. Starting off with the assertion that "its theoretically
>possible that the existing protocol isn't desired, therefore we should
>invent a new one" is a complete non-starter for the IETF.

Regrettably, it seems you've taken that question out of context. If one considers the entire related e-mail thread as well as their reading of the draft, they'll see a summary of motivating factors for the proposal. They may well require more detail (as in fact they have and rightfully so), but the summary IS there.

Real customers have stated interest in doing IPv6 PD but not using DHCPv6. As you may know, the next version of our draft will include elaboration on these real (not theoretical) customer requirements.

>
>We do engineering here, presumably solving real problems, where the
>existing solutions are inadquate or non-existent.

I believe we seek to find solutions that are either better than existing ones, or that meet a heretofore unmet requirement. If something is inadquate, by definition it is not a solution.

>
>> There's no doubt that DHCPv6 PD works, was carefully considered, and
>>  does have an install base. We affirm that fully.
>
>In which case, there would appear to be no need to talk about a new
>protocol, since you appear to admit that an existing standard does
>solve the problem.

I'm afraid you misunderstand. That statement was made to further our point that our goal is NOT to replace DHCPv6 PD. Also, if you read our draft you'll see the point made that the ICMPv6 based PD mechanism we propose is mean to be an alternative. 

>
>If you want this group to consider a new protocol, start by convincing
>us that:
>
>1) there is a real (not theoretical) problem that needs solving, and

It is a real problem to be solved that customers need to do IPv6 PD and DHCPv6 is not employed. We believe our mechanism does solve this problem.

>
>2) the existing mechanisms do not address it properly, and

By definition, where DHCPv6 is expressly not employed it cannot address the IPv6 PD requirement at all. 

>
>3) the best way to address the problem is with a new mechanism (and
>   it's better than other proposed ways of fixing the problem).

Are you aware of other IPv6 PD proposals out there Thomas? Not knowing, I'd have to allow that there could be. 

My reading of RFC 3769 is that it says how any IPv6 PD mechanism must behave, NOT that said mechanism MUST be the already existing DHCPv6 PD standard. BTW, to cite RFC 3769 is in no way to say or imply that we're developing this new solution because we CAN.

Development of both the technical cases and customer requirements for the alternative IPv6 PD mechanism we propose will primarily be developed in future revisions of our draft.

It seems many excellent questions and issues have been raised in these many e-mail exchanges. 

These include concerns about the need for elaboration on reasons for customer requirements, as well as how we see ICMPv6 PD either:
1) solving problems that DHCPv6 PD does not solve, or 2) solving problems better than DHCPv6 PD does

These group concerns WILL inform how the future draft revisions are written.

Please also provide us with a technical critique of the proposal itself. If we are to provide the best possible technical solution, we need the best technical feedback the group has to offer.

>
>At this point, AFAIAC, you have not gotten past either points 1) or 2).
>
>Thomas

Tim
Rom 8:28

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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 25 Aug 2006 09:11:55 +0300

Tim,

Its probably best if you now update your draft with a better description
of what scenario you are looking at, details about the customers
requirements, justification of why new work is needed, and an analysis
of why existing solutions are inappropriate or undesirable in your
scenario. This has already been a long discussion but in my opinion
it has not been all that informative yet with regards to these issues.

Also, at least I personally want to know what problem we are
solving before spending a lot of effort in analysing a solution --
we know there is an infinite number of ways to design a protocol
but the real question is whether it solves a problem.

Looking forward to your new draft.

--Jari

---

From: Bob Hinden <[email-masked]>
Date: Fri, 25 Aug 2006 16:34:22 -0700

> it has not been all that informative yet with regards to these issues.

Similar thoughts on my part.

Further, I would like get a better understanding as to why RA was  
chosen for this.  From my viewpoint the RA/RS is a very nice  
mechanism for a router to tell all the hosts on a link common  
information (e.g., prefixes, link MTU, lifetimes, etc.).  ND does  
have the ability to run in a unicast mode where different answers  
could be provided depending on the address of the node sending the  
solicitation, but this not something we have thought very much about  
nor specified.  I think it could be made to work, but it would need a  
lot more thought and discussion.

Also, RAs were, of course, designed to allow routers to send  
information to hosts.  The proposal here is, if I understand it  
correctly, is to use RAs to provision other routers.  Not the  
original intent.

It would be great if these issues could be discussed in a revised draft.

Thanks,
Bob