Subject: RE: [seamoby] Re: context transfer/fast MIP conflict (was: [seamo by-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt)

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 4 Feb 2001 23:27:05 +0100

I've removed people from the cc list to avoid receiving duplicates
	I know the're on the list already.

> Hesham Soliman  (ERA) writes:
>  > Now we are solving the routing part of the problem. No new
>  > COA means no routing. Obviously CT is still needed for a more
>  > complete solution. 
>  > We had two possible options for sending this
>  > request-reply messages. Dest options or ICMP. After a long 
>  > debate we thought ICMP is more appropriate since it allows 
>  > for future extensions and MAY also be used by the CT team. 
> 
>    Well, I'm glad to hear that you ditched the
>    Destination Option, 
> 
	=> Why ?

> but as far as whether ICMP
>    is the right method, I think it's far to early
>    to guess. A few questions come immediately to
>    mind:
> 
>    1) Do we need congestion avoidance?
	=> Could you elaborate a bit on this ? I don't see the additional
	need here compared to other signalling flows.

>    2) Do we need > MAX MTU contexts?
> 
	=> So far we haven't seen the need. 

>    3) What are the security requirements?
> 
	=> The HI/Ack MUST be authenticated. IPsec is used.

>    
>  > Now if that is a bad solution then we can always revert to
>  > destination options and leave the door open for highler level
>  > protocols for CT.
> 
>    Or you could feed the requirements to SEAMOBY
>    and have a single solution. 
> 
	=> I see. I have to disagree with this. As I said earlier 
	we're trying to solve the problem of routing packets to and
	from the MN. Forming a new COA in a stateless manner
	poses a challenge to this routing problem. This is how 
	we chose to solve it. I was also happy with doing DAD 
	in parallel but this seemed to be a good way to do it 
	for routers that can confirm that no duplication will 
	take place. 
	As to whether it should be done in SEAMOBY, well, 
	I believe SEAMOBY is standardising the CT and not 
	every message that is sent between ARs. Especially 
	if the purpose of these messages is to enable the 
	routing of packets. We are not transferring context 
	really (like QoS, SAs ...etc). 

	I think this discussion should be taken on the MIP list
	since it is a MIP draft. 

	Hesham

	PS: This list is very slow. It takes me at least half an hour
	to get my email back !

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 4 Feb 2001 23:49:10 +0100

>    Can Destination Options be encrypted using ESP?
	=> There are 2 dest options in the IPv6 header. 
	Dest 1 is processed by intermediate nodes and can not 
	be encrypted. Dest 2 is placed after the IPsec header 
	and is processed by the end node only and can definitely
	be encrypted.

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 4 Feb 2001 23:27:05 +0100

=> Why ?

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 4 Feb 2001 19:05:57 +0100

Hello, 

First of all I'd like to state that there is a new draft that will 
appear in a couple of days, this draft is much clearer and 
hopefully it will explain a bit more what we're trying to 
achieve. The draft will however still contain the HI/Ack messages
hence this email. 
Now, let me try to explain why these messages exist and see 
if we can get some feedback. I hope we can keep this discussion
constructive.

IPv6 allows the MNs to get a new COA when attaching to the new
AR, however this requires DAD. DAD can take up to 2 seconds. If 
you strictly folow RFC 2462, then the MN can not receive or send 
packets during that period. Not very fast is it !
The draft is based on anticipation, the MN anticipates its new COA
and sends BUs based on that anticipated address. 

So we had to work around RFC 2462: 

- If the new AR has knowledge of all MNs connected to it, then this 
knowledge can be used to immediately know whether the MN's 
address is valid or not. This would require a request-reply message 
from the old AR to the new one. 

The option of doing DAD in parallel was there but in view
of the new approach (coming out in the new draft) it may not 
be needed. 

Now if that is a bad solution then we can always revert to
destination options and leave the door open for highler level
protocols for CT. But we need to know why it's bad and why
CT will be done differently. So far we haven't heard any reasons
because the work of the CT team is not done yet. So nothing 
is set in stone. 

As far as I'm aware no one was trying to "take over" the context
transfer work. So I don't see any need for being concerned about 
that. 
I hope we can cooperate in this area as it is obviously 
needed by both WGs. 

Hesham

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 5 Feb 2001 07:23:11 -0500

Hi all,

I think we should all relax and take a deep breath...
The new draft of the design team will by out on Tuesday or Wednesday (the
latest) this week. As Charlie and Hesham have indicated it is going to be
significantly different from v00. I think we should all wait for this draft
so we can have a reasonable discussion on something specific rather than
some of you trying to guess what we have done and the design team trying to
explain mechanisms over e-mail instead of pointing to a draft. 

George

-----Original Message-----
From: Charlie Perkins [mailto:[email-masked]]
Sent: Monday, February 05, 2001 3:55 AM
To: Michael Thomas
Cc: [email-masked]; [email-masked]; George Tsirtsis;
Basavaraj Patil (NTC/Dallas); Phil Roberts
Subject: Re: [seamoby] Re: context transfer/fast MIP conflict (was:
[seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt)

Hello again,

>    Suppose that my home address is 11.12.13.14 and
>    my current attachment point is 100.1.1.1, my
>    next attachment point is 100.1.2.1. When I send
>    a BU to the old AR to create a tunnel to my
>    new care of address at 100.1.2.1, the format
>    of the IP packets from the old AR will be:
>
>    IPHdr: D:100.1.2.1 [D:11.12.13.14 ...]

Check.

>    Correct? As such, _ARnew_ doesn't need to do anything
>    extraordinary to route the tunneled packet to MN
>    since from its perspective it's just an ordinary
>    IP datagram that is reachable via whichever interface
>    100.1.2.0 points to. Correct?

Check.

>    Thus, I don't understand what new routing state
>    needs to be set up on ARnew: it's already there.

No, what needs to be set up is that ARnew needs
to know the MAC address for the mobile node, and
ARnew needs to confirm that 100.1.2.0 is not already
in use by some other mobile node.

>    What you seem to be implying above is that the tunnel
>    endpoint is on ARnew instead of MN in which case
>    I could understand why ARnew's routing tables
>    need to be updated, but that's not what you
>    mean is it?

No, the tunnel endpoint is MN as you originally thought.
However, in order for MN to actually use its new care-of
address without suffering the rigors of DAD and ND,
special arrangements have to be made at ARnew, and
the logical seat of authority for those arrangements is
ARold.

>                  ...         our argument is only in
>    who should choose the appropriate transport
>    vessel for the goodies. I think it would be
>    better to defer that decision and let SEAMOBY
>    decide which is best for both in light of the
>    full set of requirements.

On the other hand, other people do not feel this way.
Nothing has been set into stone, although I think that
the design team has a good design.  If after due
consideration it turns out to be incompatible with
whatever [seamoby-context] decides has to be done
simultaneously with HI/HAck, then why don't we fix
the problem then instead of going into paralysis mode
now?

Regards,
Charlie P.

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 6 Feb 2001 17:35:28 -0500

Hi Michael,

I apologize in advance for only having glanced at this discussion but I am
trying to understand what is really bothering you.

From what I can say you do not like the idea that we use HI/HACK messages
between old and newARs...and the reason is that you want to define those
after you consider context transfer in seamoby?
Moreover you also seam to think that the newAR should be not be involved at
all with the fast handoff, is this true? If yes, could you please let us
know how this can be done? I would be very interested in such scheme.

Are the above your main objections? If not, please do correct me...

George
-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Tuesday, February 06, 2001 6:31 PM
To: Charles E. Perkins
Cc: Michael Thomas; [email-masked]
Subject: Re: [seamoby] Re: context transfer/fast MIP conflict (was:

Charles E. Perkins writes:
 > >    Why can't ARnew get the MAC address in the
 > >    usual way? Ie, through ARP or ND? This only looks
 > >    like an optimization of one round trip on the
 > >    local media which is certainly not on the same
 > >    order latency as what fast handoff is trying
 > >    to counter.
 > 
 > Any such round trip comes equipped with retransmission
 > timers and failure conditions.  So, even if I agreed
 > with your premise (which I do not) I would still believe
 > it is highly advantageous to eliminate control messages
 > over the air.
 > 
 > Furthermore, we have to design a protocol that allows
 > access routers to work better even if they have
 > hundreds of thousands of attached mobile nodes.

   It would be even more advantagous for the router 
   to do some mind reading. I'm sorry, but this is 
   completely unpersuasive. Fast handoff's job is 
   to come up with a way that deals with in-flight 
   data for the potentially long round trips to HA's 
   and CN's. It wasn't to explore every possible optimization 
   for the least common denominator. I, for one, think 
   it is a lousy idea for an 802.11 network which 
   has ample bandwidth and doesn't want to deal 
   with the administrative nonsense of having to 
   get adjacent routers to know and trust one 
   another. Yet the last draft I saw makes HI/HACK 
   MUST requirements. Bletch. 
 
 > Furthermore, we have to design a protocol that allows 
 > access routers to work better even if they have 
 > hundreds of thousands of attached mobile nodes. 
 
   Please explain the scaling issue here. If a 
   router melts down because of a single round trip to
   do ARP/ND per node, it's got way bigger problems than
   the MIP WG can help with.
 
 > I claim that eliminating this round trip that you
 > mention is more than worth the effort.  And I do not
 > see any downside.

   Sure there's downside: you're *requiring* network
   administrators to set up the provisioning and
   security between AR's. That is *hardly*
   inconsequential.

 > You have made your opinion very clear!  There is a
 > tradeoff between signaling between routers and speed
 > of handovers.  I think it is clear that we can get
 > significantly faster and less error-prone handovers
 > by specifying a bit of signaling between routers.

   _Significantly_? It sure looks like it's down
   several orders of magnitude to me. Like one
   round trip on the local interface vs. round
   trips across the world.

 > >    The problem is that it's impossible to tell you
 > >    whether your transport vessel is a good one at
 > >    this point.
 > 
 > This is in the eye of the beholder.  I'm 95% sure that
 > it's a good one, and a number of highly qualified people
 > have been staring at it for months. 

   How can you say that when your design team just
   decided to switch to ICMP? How can you know
   that CT's requirements won't require a reliable
   datastream using, say, SCTP because context
   doesn't fit within an MTU and we need
   congestion avoidence?

   I think it's entirely premature to be spouting
   95% confidence levels.

 > The design team
 > didn't get to this point accidentally after a wild
 > night of bar-hopping.

   Yes, but does it pass the Turing Test?

	    Mike