[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] Reality Check - Implementer Feedback
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 <smadanapalli@gmail.com>
Date: Saturday, August 4, 2007 8:01 am
Subject: Re: [DNA] Reality Check - Implementer Feedback
To: Sathya Narayanan <sathya@njit.edu>
Cc: Suresh Krishnan <suresh.krishnan@ericsson.com>, Dna
<dna@eng.monash.edu.au>, dna-ads@tools.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 <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
> > >>
> > >>
> > >>
> > >>
> >
> >
> >
>