Subject: RE: Comments on draft-ietf-mobileip-fast-mipv6-00.txt

From: George Tsirtsis <[email-masked]>
Date: Thu, 1 Mar 2001 06:29:11 -0500

I got your e-mail only once...which means that the mailing list did not
work...anyway..we keep going.

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, February 28, 2001 11:58 PM
To: George Tsirtsis; [email-masked]
Cc: [email-masked]'
Subject: RE: Comments on draft-ietf-mobileip-fast-mipv6-00.txt

...
>
>GT> Well, that is the trick... The MN will send the BU assuming the nCOA is
>OK...but it MUST NOT use the nCOA until it receives a BACK! The BACK will
>only be sent by the oldAR if the HACK has been received from the newAR
>saying that the nCOA is actually valid...

So let me get this straight. Suppose the HI/HACK exchange happens and the 
newCoA is fine with newAR, and tells MN to use the newCoA, but for some 
reason the L2 move is delayed and the BU/BACK occurs over the old L2 
connection. Since newAR is fine with the newCoA, oldAR reports a successful 
BACK. Now suppose, for some reason, that the L2 move is aborted. This could 
happen in cellular, for example, if the mobile suddenly moved back toward 
the middle of the cell and its power readings started increasing.

Now the mobile is left on the old L2 with a topologically incorrect address 
to which oldAR is tunnelling.

GT> The MN will only have to send a Neighbor Advertisement (which can also
be signed) to the oldAR to retrieve its connection, some packets may be lost
but even that should be rare...I think we can make this work but we have not
talked about it in detail in the draft because we have some open issues...We
plan to discuss this and in general ping pong during the IETF because the
subject is complex and we have not managed to agree between us yet...I
suggest we leave this point for now so we can be more productive... I assure
you, we are going to come back to it during and after the IETF.

>GT> If the MN connects to the newAR faster than the HACK returns to the
>oldAR and assuming the MN has already send the BU, the MN will timeout and
>resend the BU but it will not use the nCOA...see the Description paragraph
>in section 4.7. I guess we have made the assumption that the HI/HACK
>sequence is not going to be the limiting factor otherwise we do not make
the
>handoff faster but slower => not good :-)
>

I think this assumption is probably valid, since the HI/HACK is going 
through the
wired network. It should, however, be stated.

GT> OK.

...

According to the description of PrRtAdv on pg. 14:

         In sateful (sp. stateful) configuration, this option MUST be sent
to
         allocate an address on behalf of the Access Router this message
         is proxied for (presumably newAR?). In stateless address auto-
         configuration, this option may or may not be sent. If sent,
indicates
         the requesting node SHOULD use this address as newCoA for the
         duration of the handover. If not sent, the requesting node SHOULD
         compute the newCoA using the Interface ID from the Destination
         Address of this message.

Now, according to this, use of this address is completely optional. If the
MN chooses not to use it or oldAR chooses not to send it,  the MN MUST
do new CoA generation at the newAR, otherwise it can't send a BU. So, in 
effect,
the MN could be left in the position where it generates a CoA which newAR
already knows is invalid, then sends that CoA to oldAR, and has it vetoed 
in the
BACK. Then it has to go through another round of CoA address generation.
I don't think this will reduce any signalling.

GT> Whether this option is sent or not, the newCOA is calculated the same
way by both the oldAR and the MN (at least in the stateless case). The
reason we made this optional is that sending this option avoids guesswork at
the oldAR...i.e.: the oldAR knows for a fact the address that the MN will
use as a newCOA. On the other hand this costs a 24bytes long option...which
we did not want to make mandatory since we try to minimize bits over the air
where possible. Note that the chances of the oldAR calculating a different
address from the MN given the same Interface ID and Prefix is really very
very small. We only added this option to cover for the privacy draft where
the MN might want to change Interface ID very often...

There is a further problem with the description of this message on pg. 
13/14 (which I
just now saw, trying to make sense of the last sentence). What is meant by
"the Interface Id of the Destination address?" First off, if the MN is to 
form a CoA, doesn't it use its own interface ID and the network ID of the 
subnet advertised by the router?

GT> I guess that you are referring to: "the Interface Id of the Destination
address" of the *PrRtAdv* message that is going to the MN. The oldAR can use
the Interface ID of this address (which we know it belongs to the MN) to
construct the newCOA...what is the problem?

 Secondly, the description of the 
Destination Address on pg. 13 states:

         The Source Address of an invoking Router Solicitation for Proxy or
         the addrss of the node the Access Router is instructing to
handover.

What does this mean? It sounds to me, and from the protocol diagrams on pg. 
8) that the PrRtAdv is coming from oldAR. Is that its address? If so, then 
how can the
MN form a CoA on the new link when it doesn't have the subnet? If not, then 
I think the description should reflect that.

GT> I think I might be missing your point...The PrRtAdv is sent from the
oldAR to the MN. The Destination Sddress of this message is the address of
the MN (which can be derived by the Source Address of the RtSolPr message
that was sent from the MN to the oldAR earlier). This same address includes
an Interface ID that can be used to calculate the newCOA...Did I miss your
point?

>In the network assisted, "stateless" config case, how does the MN get
>notified of
>nCoA when it gets to newAR? For example, newAR might determine that the
>address is invalid, but only oldAR gets told. MN needs to go through
>some
>procedure, presumably standard MIPv6 CoA configuration, only to be told
>at
>some point that it can't use the address, while newAR knows this all
>along.
>Is this so, or am I missing something?
>
>GT> Here is what is going on: The first think the MN does when it connects
>to the newAR is to send Neighbor Advertisement (NA). Assuming the BU has
>already been send, 3 things can happen.
>- nCOA is valid => A buffed BACK is delivered to the MN which can now use
>the nCOA
>- nCOA is invalid => A buffered BNACK is delivered to the MN which must now
>get a newCOA all over again (revert back to normal MIPv6)
>- delays/errors (Any of BU, HI , HACK and BACK was lost/delayed) => No BACK
>is delivered to the MN, the MN must resend the BU to the oldAR...

OK, but I still don't understand why the MN has to go through all this 
signalling when newAR may have already sent the HACK and possibly has 
already been defending the newCoA. Why can't MN simply ask newAR, and if it 
gets no response, then go through
the standard MIP newCoA generation?

GT> What is "all that signaling"? The MN will have to send a BU and the
oldAR will have to send a BACK for routing change purposes...no way around
that, agree? So what is the added signaling? In any case, another reason
(which Mohamed reminded me off) is security...the MN does not have a
security association with the newAR yet...all other messages in this
mechanism are secured...

...
>
>GT> Jak, what you are saying is OK only if the network can determine the
>fact that the MN must be handed-off well in advance...and thus have time to
>do HI/HACK before you send the PrRtAdv and this is certainly allowed (and
>you can use it for stateless config as you suggest...). We felt, however,
>that you might not have all this time...In this case you do stateless as we
>suggest and you send the PrRtAdv virtually at the same time you send the HI
>message...that is definitely faster...

Well, according to previous comment, the group seemed to feel that the 
HI/HACK was fast.

Also, if the PrRtAdv is sent at the same time, it can't have a newCoA in 
it, because the
oldAR hasn't yet received an acknowledgement that the generated newCoA is 
OK, correct? Given that, the MN ends up having to generate a newCoA on the 
other end anyway, going through all the signalling involved in MIP CoA 
generation.

GT> Jak, you are missing a fine little point since the start of this
discussion. The oldAR CAN SEND the newCOA even if it HAS NOT received the
HACK! The trick is that we allow the oldAR to guess! In the unlikely case
that the oldAR gets it wrong or the newAR for whatever reason replies with a
HNACK, the oldAR will reply with a BNACK to the MN's BU...and the MN will
have to do normal MIPv6. But this is very unlikely to happen anyway and we
think it will speed things up in 99.9...% of the cases. I think we have to
make sure that you and the WG understand this idea....which I see that it is
counterintuitive and may need better explenation in the draft...I will make
sure we cover this in the presentation.

...

>to get routing right...and thus everything is based at the oldAR (which
>controls routing for the MN)...so we also delegate, the confirmation to the
>MN that its nCOA is OK, to the oldAR and we deliver this information in the
>BACK which also confirms that the routing change has taken place...A design
>decision, someone else might have based everything on the newAR...but that
>would be a different design.

Right, and I think it would result in less signalling in some cases. That's 
what I'm trying to say. Also, this is a design assumption that is left 
unstated in the draft. It should be clearly articulated.

GT> OK, I see that we can make this more clear...The discussion with you has
brought up a number of points that should be clarified...we will try to do
this in the next version.

...
>
>GT> The requirement is that the MN gets the PrRtAdv before the link to the
>oldAR is severed...how you do this is implementation specific...not sure
>what you want us to say about it...If for some reason it does not happen
>(PrRtAdv) gets lost then, in the normal graceful IP manner the MN  will
have
>to do normal MIPv6....

Then this should be stated in the draft, and it is obvious, to me anyway, 
that it requires L2 information because the MN can't possibly know it 
otherwise.

GT> OK, will do, thanks.

>In the case of the BU, I would assume that it *does* matter, that the
>mobile node will not send the BU until it knows it has a solid new L2.
>Otherwise, it might be telling oldAR
>to route to the nCoA before it even has L2 established. So how does it
>find
>this out?
>
>GT> I think you may have now understood from the discussion so far what is
>happening. The BU is sent with the *assumption* that the nCOA is
>valid...this is not confirmed, however, and routing does not change until
>and HACK is returned by the oldAR and BACK returned to the MN...

As mentioned, I think it is possible to do much better if the MN simply 
asks newAR.
It would simplify the design.

Why was the design decision made to base confirmation of newCoA validity on 
oldAR? Perhaps the group had a good reason for this, if so,I think it ought 
to be listed in a "Design Goals" section.

GT> I brought up two reasons up to now. 1. Routing change has to be based at
oldAR so we thought we base the whole design on a single point rather than
distribute different aspects of it in different points. 2. Security
Association only exists between MN and oldAR + oldAR and newAR which already
puts the oldAR in a strategically good position to handle the whole handoff.
I think we can make these explicit in the draft. I would also be interested
to see, if you have the time to work on this and still think is feasible, a
bit more detail on how the newCOA confirmation can be done at the
newAR...then we could judge better wether this is a good idea or not.

...
>
>So MN gets a trigger prior to sending RtSolPr in the mobile assisted
>case,
>and oldAR prior to HI in the network assisted case?
>
>
>GT> In the Mobile Assisted or Mobile Determined the Mobile decides that is
>must handoff, how is this done is outside the scope of this doc...It might
>get a trigger or it might have the intelligence to figure that out by
>itself...either way the same think happens...

I think this is one of the key, meta-level objections I have to this draft. 
I do not think you can simply assume that L3 gets an L2 trigger up front 
that a handoff is about to happen , then continue signalling on L3 
regardless of the state of L2. The problem is that handoff is a mixture of 
L2 actions and L3 actions, by its very nature. That said, I think it should 
be possible to work with some general abstractions about L2 actions rather 
than specific L2s, since most L2 designs will give you some information. 
Clearly articulating what information is required where and what to do if a 
particular L2 does not supply it is critical for having an interoperable 
design. If a designer would rather not use such L2 triggers at all, vanilla 
MIPv6 handoff will do just fine. They can even use an L2 trigger after 
handoff on the mobile via the driver and avoid having to wait for a 
multicast router advert.

GT> OK, I think this can be further discussed and clarified. The problem is
that we did spend a very long time discussing L2 triggers and L2 assumptions
and although we think we more or less understand them, we found impossible
(given the timeframe) to find *useful* general abstractions...and at the end
we found that we did not have too...but let us think about this a bit more
and see if now that we have completed this phase of work can go back and
reconsider this.

>I think this should be clearly stated somewhere in the draft, preferably
>near
>the front under "Assumptions".
>
>GT> Not really, there is no reason to state this...The implementer will
have
>to decide how things get triggered based on the link layer he/she is
working
>with...you think there will be a trigger coming from the network to trigger
>the mobile determined case, I think the mobile will figure this out on its
>own....and we are probably both correct for different link layers...

No reason to state assumptions???? Stating assumptions is one of the 
hallmarks of a good specification. If you don't state assumptions, how is 
an implementer to know whether their situation has the right support for 
the specification?

GT> Let me duck and take this back :-) Of course we have to state
assumptions and I think you have correctly identified a number of things
that might need to be explicitly stated. We may, however, disagree on how
much we need to assume about Link Layers...

>Why should this have to come from the oldAR? The newAR knows whether the
>nCoA is valid, why can't the mobile simply ask it?
>
>GT> Now you are designing a new protocol and I am tempted to ask you to
>write a draft :-)   Seriously, we thought that the most important thing is

I'm sorry for being so touchy, George, but I think there are some problems 
with this draft in terms of explanation, design complexity and some 
assumptions that I think were made that are not explained much less 
justified. If you are not willing to consider modifying the protocol based 
on working group input, let me know right now and I won't bother even 
working on it any further.

GT> Modifications are always welcome but lets not rush and make changes
before we all understand how this works. I can easily see why the draft
might not be 100% clear since the design team has been working intensively
on this for almost 4 months and some things that we came to realize and
consider given, might not be in the draft in a way easy to digest...I am
sure we will work on that..this is v00! I am just asking you to take the
time (and I appreciate the effort you put on this already) and let the
current design sink in before we rip it apart. 

I don't want this conversation to descend into the kind of knife fight 
that's been happening on Seamoby but, on the other hand, if want you are 
looking for is to have the working group simply rubber stamp your work, 
I'll simply say "sayonara" and you can get the rest of the working group to 
do it.

GT> No, no...this is one of the, unfortunately rare these days, set of
comments that are constructive and non religious! Lets keep going...let us
help you understand what we have done and then we change what needs to be
changed.

George

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 1 Mar 2001 06:29:11 -0500

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, February 28, 2001 11:58 PM
To: George Tsirtsis; [email-masked]
Cc: [email-masked]'
Subject: RE: Comments on draft-ietf-mobileip-fast-mipv6-00.txt

...

the

GT> OK.

...

...

...

...
have

GT> OK, will do, thanks.

...

have
working

George