Subject: RE: Address config for FMIPv6 (was Re: [mobile-ip] FMIPv6: F BUtransmission text)

From: Soliman Hesham <[email-masked]>
Date: Wed, 25 Jun 2003 19:26:42 -0400

> > => Yes I was suggesting all 3. But I didn't ask for 
 > > them to be removed from the draft. 
 > > 
 > > The problem is, I didn't say anything that disagrees
 > > with the above. I said, make them optional... I'm starting
 > > to regret saying it ;)
 > 
 > 1. FMIPv6 is an *optional* enhancement to base IPv6 mobility
 > 2. The WG consensus is to make this mechanism *experimental*
 > 
 > So what would be gained by saying HI/HACK is optional to
 > implement in the reactive scenario (as an example). 

=> In the example you mention, nothing will be gained. 
But In the case I mentioned it's different. 
Basically, my sentence was saying the following:
The only reason for these messages is avoiding
address collision and DAD delays. So if you
don't have these problems in your system, don't
implement these messages. Isn't that reasonable?
I can cite more than one link layer where DAD is not
useful and in fact is not used (e.g. WCDMA). 
So why would I want all these messages when the problem
that they solve does not exist.

Let
 > the results from implementations prove whether these are
 > effective or NOT. I guess you are proposing that we leave
 > the implementation of some of these messages optional and let
 > implementers decide whether they will achieve greater optimization
 > by incorporating them. 

=> Well, that's one reason, but not quite all, please see my 
explanation above. If it's not clear let me know.

Thats a possibility as well. Something
 > to get consensus on.

=> ok.

 > 
 > On a side note:
 > It would also be not a bad idea for the IRTF work that is
 > under discussion to develop tools that can be used to evaluate
 > the benefits of having certain messages vs not having them.

=> Agreed. But my issue was more of a need. For instance, 
MIPv6 does not mandate the implementation of dynamic
keying because there is an alternative in some cases. 
Those who want to implement dynamic keying can go ahead
and do it. All I said was that we say the problem that
these messages solve and in systems that do not have
that problem life would be easier for implementers 

Hesham

 > > Hesham
 > -Basavaraj

---

From: Bryan Hartwell <[email-masked]>
Date: Wed, 25 Jun 2003 20:19:40 -0400

>address collision and DAD delays. So if you
I think, and James seems to agree with me, that HI/HACK
should at least exist  for policy enforcement. Maybe NAR
doesn't want to detunnel your packets?

Bryan

---

From: "Youn-Hee Han" <[email-masked]>
Date: Thu, 26 Jun 2003 14:36:05 +0900

> implement these messages. Isn't that reasonable?

Yes. we can delete the messages for avoiding address 
collosion and DAD delays *only when* we can completely 
assure that the probability of collision is exceedingly low.

In the Section 3.2 of current OptDAD draft...

    "...   It is for this reason that Optimisitc DAD should only 
     be used where the probability of collision is exceedingly low."

So, if we make FMIPv6 incorporated with OptDAD 
without any complementary measures handling the collison case,
we cannot help say that...

    "FMIPv6 should only be used where the probability of 
     collision is exceedingly low."

> that they solve does not exist.

I agree that the address collision wll not occur in the most cases.
However, I don't agree that the probability of collision is so 
enough small to ignore DAD procedure.

Although all L2 technologies are not examined, I would like to 
say that DAD procedure is indispensable on some of them. 
And, even with EUI64 IID based on the IEEE 802 address, 
we cannot completely assure that the probability of collision 
is exceedingly low. 

IMO, the coupling between FMIPv6 and OptDAD should 
become optional. 

Regards,
Youn-Hee