Subject: [dhcwg] Invitation to a pre-IETF DHCPv6 bake-off

From: "Durand, Alain" <[email-masked]>
Date: Tue, 27 Feb 2007 15:43:28 -0500

Dear wg members,

I'm posting this message with authorization from the wg chairs.

I'm organizing a DHCPv6 bake-off in Amsterdam on 3/15 and 3/16 in the
RIPE-NCC facilities.
The focus of the bake-off is interoperability, operation impact and
usability.
In that sense, it is different and complementary to the TAHI tests.

This event will be organized by Comcast with the help of ISC and will
operate
under standard connectathon-like rules (ie NDA & no detail published
results).

I have already confirmed participation of 5 majors implementations
of DHCPv6 clients, servers and relay agents and I'd like to extend
the invitation to other participants. Please contact me directly if you
are interested or have any questions.

Regards,

    - Alain.

FAQ about the bake-off:
=================

* When and where will the bake-off take place?

==> March 15th-16th in Amsterdam at the RIPE-NCC facilities

*  What is the goal of the event?

==> The goal of the event is to ensure basic inter-operability of DHCPv6
       solution in a traditional enterprise type space by focusing on
the
       operational issues of running an heterogeneous network.

       We will focus on making sure that client X work vs server Y as
expected,
       then we will move on to different networking scenario through the
prism
       of operation in a real network rather than pure conformance to
the spec.

*  What problems has Comcast already identified  with the
implementations?

==> We ran into problems so far with very first basic tests,
       so we thought that there will be tremendous value to replicate
       those tests in a larger set-up.

       For example, we realized that client implementation all made
different choices with DUID types,
       and the type 1 (MAC+time) was confusing about when exactly to
change the time stamp, and
       it was not clear what the desired behavior of a server should be
(regardless of what the spec says or not).
       We have also seen some different interpretations of what messages
were required or not
       and we have also seen various behavior depending on the mix of
stateless vs statefullautoconf.

       I fully expect to see more of those operation problems showing up
during the bake-off

*  What is the test plan  that will be run?  

==> ISC is currently developing the actual test plan with us, we are
planning to release
       it to the participants before the event.

       As I see it today, it will be articulated on 3 axes:

        a) basic X vs Y, with lease renew etc...
           FQDN option, DDNS update,...
           ops question: how to reconcile on the DHCPv6 server clients
using different DUID types,
        b) same but this time focusing on relay agents, with one or two
level of relaying
        c) same but with different mix of stateless and stateful
autoconfiguration
          - DHCPv6 only, RA with empty prefix list
          - DHCPv6 only, RA with prefix list
          - Mix of stateless autoconf and DHCPv6 address assignment
          - Mix of stateless autoconf and DHCPv6 for other parameters

*  Will the testing include relay agents?  

==> Yes, see above 

*  Apparently there will be an NDA required for the event, engineers are
often not authorized to sign NDAs.

==> Contact me directly ASAP if you plan to participate and do not
already 
       have an NDA in place with Comcast.. 

*  How will Comcast use the results? 

==> We will not publish any detail results, and certainly not anything
including the name of the implementations,
       respective results will be available to the respective
participants.
       We will create a brief executive level summary for the IETF
meeting along the lines of:
       "We had a bake-off with xxx number of client, yyy number of
servers, zzz number of relays,
        we found that kkk of them had an issue on that particular topic,
that the spec covering it might have
        a technical problem or simply be not clear enough..." 

*  Will the attendees get a copy of the results? 

==> Yes, see above, a copy of their respective results. 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Feb 2007 19:24:46 -0700

On Feb 27, 2007, at 1:43 PM, Durand, Alain wrote:
>        and the type 1 (MAC+time) was confusing about when exactly  
> to change the time stamp, and
>        it was not clear what the desired behavior of a server  
> should be (regardless of what the spec says or not).
>        We have also seen some different interpretations of what  
> messages were required or not
>        and we have also seen various behavior depending on the mix  
> of stateless vs statefullautoconf.

I find this statement very disturbing.   The DUID generation process  
happens once, and it never changes after that.   Otherwise you have  
no way to know that it's the same client.   If people are  
interpreting the spec to say that they should regenerate the DUID  
every time (for any value of "every time"), we need to figure out why  
and clarify it.

I'm not sure yet whether I can come - if I do, I'll be bringing  
Nominum's sample client.

Thanks!