Subject: [mobile-ip] Comments on draft-ietf-mobileip-lowlatency-handoffs-v4-02.txt

From: James Kempf <[email-masked]>
Date: Mon, 15 Oct 2001 15:29:48 -0700 (PDT)

I have some comments on the latest low latency V4
draft.

General comment: There are many cases in the document
in which prescriptive, normative statements are made
about the protocol that are not phrased in RFC 2119
language. For example, pg. 16, paragraph 3:

"...Therefore tunneling advertisements is only
applicable where the TTL limitation of [1] can be
relaxed. This should be the case for unicast
messages."

Is the last "should" really a SHOULD? Or is it a MUST?
There are many other examples. The language here needs
to be tightened.

1) pg. 3 end of paragraph 2, Appendix B. 
Appendix B is very tentative and not very well tied to
the protocol discussed. There may well be ways to do
intertechnology handoff that do involve the protocol.
For example, suppose the 2nd interface has no IP
address, and the MN discovers the new AP/FA via either
L2 information on the second interface, or via a
capabilities discovery protocol through the configured
interface (such as the Seamoby CAR discovery
protocol). The MN could then issue a ProxyRtSol on the
configured interface for the new FA, and when it
received the ProxyRtAdv, it could tear down the home
IP address on the old interface and transfer it to the
new. This has nothing to do with low latency handoff,
but it is a use of the protocol that would allow
seamless handover to a new interface. Note that this
would avoid having the MN solicit a regular FA Advert
over multiple subnets.

I'm not sure how to address this issue. Perhaps
folding the Appendix into the text with a discussion
of about how the protocol could, in fact, support
intertechnology handover would be appropriate.
Alternatively, given the urgency of getting this
document out, perhaps sectioning it off into a
separate document would be better.

2) pg. 4, definition of bi-directional edge tunneling-
This still includes text implying that bicasting is
required. I would suggest changing the first and
second sentences to:

"A set of unidirectional tunnels established between
two FAs for purposes of temporarily routing a MN's
traffic to/from  it on a new subnet without requiring
the MN to change CoA."

3) pg. 22, point 4c
The requirements language needs tightening (specific
case of general comment.) How about:

"c) When the MN receives the L2-LU, it MAY initiate
the Mobile IP Registration process by soliciting an
Agent Advertisement as described in [1]. If the
Registration is successful, the nFA takes over the
role of anchor FA (aFA) from the oFA. The MN MAY also
choose to defer nCoA establishment, if real time
traffic is occuring (see Section 4.4)."

4) pg. 24, Section 4.2, paragraph 1.
The requirement level of MAY for HTT is too weak.
There are some radio protocols where HTT is required,
others where it may not be. It needs tightening. I
would suggest the following wording:

"For radio L2 protocols in which it is possible for
the MN to move so rapidly from one FA to another that
that a probability exists that nCoA establishment on
the initial nFA will not complete, HTT MUST be
implemented. For other radio L2 protocols with
sufficient L2 trigger support, HTT SHOULD be
implemented as it provides the opportunity for the MN
to optimize handover of real time traffic at the
expense of a certain amount of header overhead on the
backbone network."

5) pg. 30, Section 4.4, point 1)
"...sending the an Agent Advertisement to the MN..."
->
"...sending an Agent Advertisement to the MN"

6) pg. 30, Section 4.4
The discussion in this section is valuable and useful,
but too restrictive IMHO and also does not consider a
couple of other cases. First off, is the FA
necessarily
always the default router? Secondly, if not, then the
FA registration, and, in addition, the HA registration
need to be renewed as well. Thirdly, since the routing
through the tunnel for POST-REG is already set up,
what is the problem with simply renewing down the
tunnel to the old default router and/or FA, and to the
HA?

As a practical matter, I think most BETs will be
terminated well before the 30 min. lifetime of the
default router advert (phone calls reputedly last on
the average about 3 minutes). But unless there are any
specific issues affecting interoperability, I believe
exactly when the network or MN should demand
termination of the BET should be left up to the
implementation. One such case obviously is if HTT is
not implemented, in that case, the MN must terminate
the BET after the first handoff.

7) pg. 32, definition of Lifetime, pg. 33 definition
of Lifetime:
0xffff should be defined as "good until canceled",
not "infinite".

8) pg. 36, Section 6, first paragraph
This paragraph is trying to say that for particular
radio protocols, deployment situations, and
implementations, smoothing techniques may be required,
but it is very ambiguous and hard to figure out what
is being said, IMHO. The title of the section should
be changed to "Handoff Smoothing Considerations" and
the language should be tightened to address the issue
directly. 

9) Appendix A, also reference [2]
During IETF 51, there was some discussion about not
wanting to put a reference in to the abstract L2
triggers draft in order not to end up with a reference
to a draft that was not close to RFC, to avoid slowing
down the progress of low latency. Yet, here is a
potential reference to exactly such a draft. How close
to RFC is the regional registration draft? Would it
make sense to remove the reference, since, while
extremely useful in the global picture of optimizing
MIP signalling, the relationship between regional
registration and low latency handover is somewhat
tenuous.

                             jak

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com