Reality Check - Implementer Feedback

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

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 <suresh.krishnanericsson.com>
>To: Dna <dnaeng.monash.edu.au>, dna-adstools.ietf.org
>Subject: [DNA] Reality Check - Implementer Feedback
>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
>
>

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

Suresh Krishnan wrote:
>
> 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
>
>

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

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 <suresh.krishnanericsson.com> wrote:
> 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
>
>
>

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 <suresh.krishnanericsson.com> wrote:
>   
>> 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
>>
>>
>>
>>     

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

On 8/3/07, Sathya Narayanan <sathyanjit.edu> wrote:
> 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 <suresh.krishnanericsson.com> wrote:
> >
> >> 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
> >>
> >>
> >>
> >>
>
>
>

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 <smadanapalligmail.com>
Date: Saturday, August 4, 2007 8:01 am
Subject: Re: [DNA] Reality Check - Implementer Feedback
To: Sathya Narayanan <sathyanjit.edu>
Cc: Suresh Krishnan <suresh.krishnanericsson.com>, Dna
<dnaeng.monash.edu.au>, dna-adstools.ietf.org

> 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
> 
> On 8/3/07, Sathya Narayanan <sathyanjit.edu> wrote:
> > 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
<suresh.krishnanericsson.com> wrote:
> > >
> > >> 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
> > >>
> > >>
> > >>
> > >>
> >
> >
> >
>