Re: [DNA] Reality Check - Implementer Feedback

[Syam Madanapalli <smadanapalli@gmail.com>]

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 <sathya@njit.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.krishnan@ericsson.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
> >>
> >>
> >>
> >>
>
>
>