Subject: [DNA] Reality Check - Implementer Feedback

From: Suresh Krishnan <[email-masked]>
Date: Wed, 01 Aug 2007 18:57:58 -0400

Hi Folks,
   We have heard comments from OS vendors that the dna protocol, as it
exists, is too complex to implement. We already have one instance of an
OS vendor (Apple) who has shipped their own version of DNAv6 (it is
pretty much a version of DNAv4 adapted to IPv6). From talking to the
people who had the complexity concerns, the chairs have inferred that
the following issues with the current document are the main obstacles to
deployment

* Router changes are NECESSARY
* Handling of corner cases adds complexity to most likely use cases
* Some of the DNA Goals are not really necessary/useful

We have a couple of options going forward

a) Forward the current document to the IESG on the standardization path
with no hope of deployment
b) Simplify the current document
    - remove some of the DNA steps
    - spin off Tentative options to a separate document
    and then put it on the standardization path, and again risk lack of
    deploymen
c) Come up with a much simpler scheme which is probabilistic but works
    decently given a set of assumptions(however limited they may be).
    Then send it up on the standards track. This has the highest
    probability of deployment.
d) Do both b) and c)

We would like to hear the opinions of the WG on these options.

Cheers
Suresh & Greg

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 01 Aug 2007 21:11:59 -0700

FWIW, I'd vote for (c).  DNAv6 is by nature an optimization, and the first 
rule of optimization is "optimize for the common case".  As a result, it 
doesn't make much sense to pay a great deal of attention to corner cases.  
The goal should be to guarantee that DNAv6 will do no harm in corner cases, 
and will provide meaningful optimization for common cases.  The most 
meaningful common case is where IPv6 routers are deployed as is, with no 
changes.

>From: Suresh Krishnan <[email-masked]>
>To: Dna <[email-masked]>, [email-masked]
>Subject: [DNA] Reality Check - Implementer Feedback
>Date: Wed, 01 Aug 2007 18:57:58 -0400
>
>Hi Folks,

---

From: Sathya Narayanan <[email-masked]>
Date: Thu, 02 Aug 2007 15:26:05 -0700

I vote for (d).

I don't see the point in losing all the work/discussions that has gone 
in to creating the current document.

Sathya

---

From: Sathya Narayanan <[email-masked]>
Date: Fri, 03 Aug 2007 09:37:16 -0700

Syam Madanapalli wrote:
> I am not sure how option d works. I understand that we did lot of work
> on the existing draft that does not mean that we should continue progressing
> it if does not going to be useful, especially when you are planning for a
> (new) simpler solution.
>
> Also we need to look into the current draft and see if one of the mechanisms
> (CompleteRA, Landmark and LinkID) can be recommended instead of all three
> (if the changes in the router is OK).
>   
IMHO,  the current  draft not being implemented because people think the 
complex goals (agreed to earlier) do not justify the complexity in the 
solution. So, we should produce a simpler document that achieves a 
simpler goal (probabilistic).  But, I still believe it makes sense to do 
(d) because, we could standardize the current document as a solution to 
the original DNA goals (RFC 4135) and close that loop. If in the future 
it was felt that the new simpler goals are too simple, the work done 
until now need not be repeated. I will agree to doing only (c) if lot 
more work needs to be done before the current draft can be finished, but 
IMO that is not the case. The current document is a good technical 
ready-to-go solution to the goals stated in RFC4315. Lets document it 
for the records quickly while moving onto a simpler goal/solution.

I don't see any reason why we cannot take mechanisms out of the current 
draft into any future solutions if necessary.

Sathya

> If we do not want any changes on the router side, I am not sure if we can
> do better than CPL.
>
> - Syam
>
> On 8/2/07, Suresh Krishnan <[email-masked]> wrote:
>   
>> Hi Folks,

---

From: Syam Madanapalli <[email-masked]>
Date: Sat, 04 Aug 2007 03:28:23 +0530

Satya, the problem I see is if we progress the current draft in
standards track, we would have two standard documents (second
standard as part of option C), which may be confusing for the
implementers in the future.

Thanks,
Syam

---

From: Syam Madanapalli <[email-masked]>
Date: Fri, 03 Aug 2007 14:33:13 +0530

- Syam

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 03 Aug 2007 07:12:33 -0700

>If we do not want any changes on the router side, I am not sure if we can

We can do better than CPL, if only because existing implementations are 
already superior.  That is why CPL as it stands won't be implemented either.

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 02 Aug 2007 17:59:35 -0500

Option C would probably be the best if we want to see it being adopted.

-Raj

---

From: Greg Daley <[email-masked]>
Date: Mon, 06 Aug 2007 17:20:25 +1000

Hi Syam,

It is important that we have something implemented, but I think
we should delineate carefully where the simplified solution is limited.

As one example, it is possible that change detection works well with
unmodified
routers, so long as Link-local addresses are statistically unique across a
single link transition, and the same prefixes are advertised in each RA.

This would constrain the network to work where Routers advertise different
Link-local addresses out each interface, and where routers' prefix
advertisements
aren't disjoint on a particular link.

The simplified system could be described with applicability statements,
and any environment where the assumptions do not hold face sub-optimal
performance.

The existing DNA document may be applicable for those environments
where these constraints to not hold (for example, if RA prefix omission
becomes important as an optimization).

If so, the important thing is to make sure that routers and hosts which
implement
one or the other scheme are compatible, in the sense that the performance is
the same.

The WG needs to determine if a one or two document strategy is applicable in
that case.

What I think is important at this stage, is that we capture the
"running code" feedback in a document.  I've been trying to do that,
and will work with Suresh to make sure we have something to concrete
to review.

Then we can let the WG get into the finer points of which documents
to submit to the IESG.

Greg.

----- Original Message -----
From: Syam Madanapalli <[email-masked]>
Date: Saturday, August 4, 2007 8:01 am
Subject: Re: [DNA] Reality Check - Implementer Feedback
To: Sathya Narayanan <[email-masked]>
Cc: Suresh Krishnan <[email-masked]>, Dna
<[email-masked]>, [email-masked]

> > the original DNA goals (RFC 4135) and close that loop. If in the 
> future> it was felt that the new simpler goals are too simple, the 
> work done
> > until now need not be repeated. I will agree to doing only (c) if 
> lot> more work needs to be done before the current draft can be 
> finished, but
> > I don't see any reason why we cannot take mechanisms out of the 
> current> draft into any future solutions if necessary.
> >
> > Sathya
> >
> >
> > >> * Handling of corner cases adds complexity to most likely use 
> cases> >> * Some of the DNA Goals are not really necessary/useful
> > >>