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

From: Dana Blair <[email-masked]>
Date: Mon, 05 Feb 2001 09:40:25 -0500

At 07:23 AM 2/5/01 -0500, George Tsirtsis wrote:
>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

I concur with George's statement.  While discussion of solutions is desireable
and we all would like to jump to that point, we really need to focus on defining
problem statement and other sections of the draft and get the IESG endorsement
to continue.

thanks,
Dana

>
>
>
>
>
>-----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.
>