Subject: RE: HI/HAck in the current spec (was: Re: [Mipshop] FNA in the current spec)

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 23 Aug 2005 12:20:34 -0400

> > If we take a step back and understand that 99.999999% of the time
 > > there is no collision, we would all see how silly it is to design
 > > another mechanism (HI/HACK) to handle this.
 > >
 > > Anyway, I personally won't use them and as long as the spec
 > > does not mandate their use I'm fine. I prefer to remove
 > > them altogether though. If for nothing else, we'll avoid confusing
 > > implementers.
 > 
 > I agree that the current spec is ambiguous. I think this 
 > needs to be cleaned 
 > up.

=> Great.

 > 
 > While I do agree that the probability of duplicates is very 
 > low, there are 
 > two issues:
 > 
 > 1) It's not zero.

=> But nothing is Zero in the world of engineers. In fact
DAD in 2462 *does not* remove the possibility of duplication. 
It has well-known limitations. So reducing it to zero in
FMIP is not possible unless we do something extremely complex
that replaces DAD in IPv6. In the world of tradeoffs (Engineering)
you should measure that against the probability of the duplication
happening. IMO, there is no logical tradeoff that would justify
the complexity coming from reducing the probability from 0.00000001
to 0. There is not one reliability requirement that I'm aware
of today in any system that requires 0 down time or 0 anything. 

 > 2) As a practical matter, I think the IESG will insist that 
 > FMIP have a 
 > clean story with regard to duplicates, no matter how 
 > unlikely, before they 
 > approve it for proposed standard.

=> We have one, oDAD. The current spec is no where near PS IMO. 
With oDAD it might have a chance.

 > 
 > I'd certainly like to get the protocol simplified as much as 
 > possible, so, 
 > from that standpoint, I'd like to get rid of HI/HAck and 
 > FNA. But only if we 
 > can figure out some nicer way to deal with the problems they 
 > were designed 
 > to address.

=> Agreed. It seems like where we disagree is whether there
is a problem introduced by removing them. 

Hesham

 >         jak

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop