In your previous mail you wrote:
- whether omitting/optimizing DAD is a good idea
= IMHO this is the same thing, i.e., optimizing gives the same result
than omitting.
Omitting DAD altogether removes the ability to detect and correct
address collisions, whereas
Hi Francis,
Francis Dupont wrote:
In your previous mail you wrote:
- whether omitting/optimizing DAD is a good idea
= IMHO this is the same thing, i.e., optimizing gives the same result
than omitting.
Omitting DAD altogether removes the ability to detect and correct
In your previous mail you wrote:
Omitting DAD altogether removes the ability to detect and correct
address collisions, whereas optimizations such as Optimistic DAD
mean that while there may be a short term disruption the problem
will be detected and corrected.
In your previous mail you wrote:
= in the real world this kind of problem cannot be corrected...
The only thing you can do is to avoid to reproduce the same error again.
Was there a specific non-recoverable scenario you had in mind there?
= just ask large network managers.
Francis Dupont wrote:
So I really believe in the DAD usefulness and if you'd like to remove
or optimize DAD on one of my networks my answer will be NO!.
I believe the optimistic DAD folks are very keen on keeping the DAD
functional. That is, it is a requirement that networks and nodes must
be
Francis Dupont wrote:
In your previous mail you wrote:
= in the real world this kind of problem cannot be corrected...
The only thing you can do is to avoid to reproduce the same error again.
Was there a specific non-recoverable scenario you had in mind there?
= just ask large
Sorry to respond to my own e-mail. But I wanted to clarify one thing.
Manual recovery is fixing the problem, like reconfiguring the address.
The recovery that optimistic DAD provides is however different. It
just corrects a temporary disruption that the optimistic assumption
may have caused.
In your previous mail you wrote:
Sorry to respond to my own e-mail.
= our keyboards have large enter keys, and often more than one (:-).
But I wanted to clarify one thing.
Manual recovery is fixing the problem, like reconfiguring the address.
= and in some cases (*all* the real
Francis Dupont wrote:
Sure. But aren't you assuming that they have to go in and manually
recover?
= it is the case for IPv4 because this kind of event is very rare
so there is no need to add an automatic recover tool. But IMHO
the real question is where are these problems for? They
In your previous mail you wrote:
= usually both the real owner and the offender are dead. Murphy's law
makes the real owner an important server.
This is not going to happen in Nick's optimistic DAD draft.
= I disagree: even in Nick's draft the second system has both
a service
Hi Francis,
Francis Dupont wrote:
In your previous mail you wrote:
Omitting DAD altogether removes the ability to detect and correct
address collisions, whereas optimizations such as Optimistic DAD
mean that while there may be a short term disruption the problem
will
In your previous mail you wrote:
= what we need is collision avoidance, no collision detection after
damage.
Here I have a slightly different opinion. There are two questions:
do we want avoidance or detection, and whether optimistic DAD
implies possible problems.
chair hat on
While the topic of Optimistic DAD is interesting, I believe we are
getting work items crossed here. The consensus I see is to not make
changes to 2462 wrt Optimistic DAD. Therefore, we can drop this
discussion as it relates to the 2462 update.
There is a slot in Seoul to discuss
Tony,
I agree that 'draft-hain-templin-ipv6-localcomm' has served the useful
purpose of focusing the discussion, but (like an RFP or BAA) its sole
purpose was to issue a call for solution alternatives; not to propose
solution alternatives or otherwise seek a more active role in itself.
As such, I
Alain,
Speaking only as an individual wg participant, I appreciate the concerns
you are raising but am hoping that you are not contemplating a divisive
and time-consuming appeals process such as the one we have just come
through for site local deprecation.
Please consider that published documents
Bill,
Whether or not this would be new and untrodden, I believe
we need to step forward together into the unknown - under
the confidence that careful monitoring and any necessary
course-corrections will see us through the uncharted waters.
Regards,
Fred L. Templin
[EMAIL PROTECTED]
Bill Manning
Alain,
At 01:22 AM 2/20/2004, Alain Durand wrote:
Dears ADs,
Since the appeal process starts with the working group chairs, we
are responding as such.
I found it very unfortunate that the chair decided to request to advance
this document
without answering two major issues I raised during the
On 2004-02-24, Francis Dupont wrote:
[Greg Daley wrote:]
This is not going to happen in Nick's optimistic DAD draft.
= I disagree: even in Nick's draft the second system has both
a service disruption and has to switch to another address.
So as to be the second system is just a
On 2004-02-24, Francis Dupont wrote:
[Jari Arkko wrote:]
= what we need is collision avoidance, no collision detection after
damage.
[...] Generally, for the last two we can only provide detection
and then wait for further input from the user; for the first we can
On Feb 24, 2004, at 10:09 AM, Fred Templin wrote:
Alain,
Speaking only as an individual wg participant, I appreciate the
concerns
you are raising but am hoping that you are not contemplating a divisive
and time-consuming appeals process such as the one we have just come
through for site local
The issue always has been where in IETF to get these collection of delays
addressed in a co-ordinated fashion. DNA was thought to be the venue, but it
has chosen not to. Given we have to address the delays piecemeal, then
OptiDAD seems like a place to start.
jak
- Original
21 matches
Mail list logo
