Subject: RE: [mobile-ip] LMM for IPv6 requirements draft (new revision .01 )

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 15 Nov 2001 14:56:17 +0100

Hi James, 

Also, I'd like to register an objection to the following wording in
Section 3.9:

   These enhancements are intended to minimize handoff latency
   and reduce packet loss.  LMM and FMIP protocols MUST BE able
   to be deployed independently of each other.  However, when
   the two classes of protocols co-exist, LMM and FMIP MUST
   maintain compatibility in their signaling interactions for
   fulfilling complementary roles with respect to each other.

This wording essentially rules out any solution that would combine with
fast handoff. I think that is a mistake because it may be possible to
obtain a solution that is simple and easy to deploy and implement which
is tightly bound with one of the fast handoff algorithms. This is not to
say that it should be the only solution, so that if another fast handoff
algorithm were deployed, another LMM solution might be required.

I think what this requirement is getting at is that there must be an LMM
solution that is available regardless of the handoff algorithm. The
current text does not cover standard MIPv6, so, given the current text,
it would be possible to develop a LMM

=> I don't really see a problem with the requirement. 
All it says is that the two solutions MUST interwork, 
which is a good thing. If the two solutions are actually
one, which is what I think you want to allow ;), then
by default they can interwork. 

3.9 Support for MIPv6 Handover.

   An LMM solution MUST be available for all standardized MIPv6 handover
algorithms. The signaling interactions
   between the handover algorithms and LMM MUST maintain compatibility.
This requirement SHOULD NOT be interpreted
   as ruling out useful optimizations of LMM and MIPv6 handoff that
simplify the implementation or deployment of LMM or
   MIPv6 handover.

=> This is a bit confusing, especially the last sentence. 
   I don't get the advantage between this one and the one 
   in the doc. 

Cheers,
Hesham

----- Original Message -----
From: "Cedric Westphal" <[email-masked]>
To: <[email-masked]>
Cc: "Carl Williams" <[email-masked]>
Sent: Tuesday, November 13, 2001 6:18 PM
Subject: Re: [mobile-ip] LMM for IPv6 requirements draft (new revision
.01)

> great work!
> thanks for putting together the LMM requirements draft, and I have a
> couple comments.
> I organize them as: comments on the reqs, new reqs, and editorial
> comments.
>
> ----------------------
> Comments on the requirements
> ---------------------
> 1.2 Principles of the LMM
>
> It seems to me that this subsection belongs to the solution space.
"This
> is done
> by [...] assigning two care-of addresses..." and other sentences like
> this one describe how to implement LMM. This should not be in a req
> draft. The principles should be at a concept level. Or the whole
> paragraph should
> be scrapped. (Same issue in 2.0 Terminology:  the LMA is defined in
> solution space,
> and not concept space).
>
> 3.3 Induced LMM functional requirements
> ("Functional requirements induced by LMM" would be better0
>
> 3.3.1 and 3.3.3: I do not see the difference. Please merge or clarify.
>
> 3.4 Scalability
>
> Shouldn't 3.3.2 be filed in there?
>
> 3.4.1:  "Scalability guarantees to support millions of nodes for an
AD"
> Is this about scaling, or about supporting a large number of users?
> This, unlike
> other subsection headings, is not phrased as a requirement. I'd
replace
> it with
> the first sentence, but then again, I don't know what the scaling of a
> _framework_
> means. Get rid of number references. There is a billion cell phone
users
> on this
> earth today, so millions are already not enough. There are two
> requirements in the
> paragraph anyway (and they contradict: one says "it should scale", the
> other
> says "it should be distributed so as to avoid scaling effects").
> Also, replace "linearly" with "at most linearly", as we can accept
> better than linear
> performance.
>
> 3.4.4: The last MUST NOT seems hard to enforce. It is expected, and I
> don't think
> it is bad, that the amount of signaling would increase as the number
of
> users, as the
> Local Domain expands in size.
>
> 3.4.7 Technically, it is not triangular routing, as uplink is
optimized
> and downlink is
> triangular. Actually, it assumes that "all traffic MUST go through the
> LMM agent"
> (MUST emphasis mine), uplink and downlink. More on this later.
>
> 'The LMM framework SHOULD support optimal placement...LMM"
> This is an implementation issue.  Should be removed.
>
> 3.4.8 link layer
> I am confused here by this requirement. Is LMM a MIPv6 extension, as
> described in
> the document? So why does it care about L2 in general, and L2
> optimizations in particular?
>
> 3.5.1/2/3 Add a mention that if MUST NOT increase is the least
expected,
> SHOULD decrease
> would not be too bad either
>
> 3.5.4 Should be removed or clarified. Who is detecting the movement
> between seperated domains?
> The MN, the CNs, the HA, the LMA? Is it a domain addressing issue
(which
> should be
> left out here). The sentence: "The reason for this ...is that there is
a
> need...for the mechanism
> to work..." is pure casuistic. If it is a non-LMM mechanism, what is
it
> doing here? Etc.
>
> 3.7 LMM disrupts IP routing by adding host routes. Should be rephrased
> as: LMM MUST
> NOT disrupt IP routing outside of the LM domain.
>
> 3.8 Last paragraph "To avoid concentration....populate the
> administrative domain". Remove the
> paragraph. There is no concern that MNs mobility patterns would be
> affected or influenced
> by the LMM-agents (btw, it is LMA in the terminology). Is this
paragraph
> saying that
> MN will flock to an access point close to a LMA? Do cell phone users
> aggregate in front
> of building carrying base stations?
>
> 3.12.1 is redundant with 3.4.5 (and 3.4.2 to some extent). As a
general
> comment, reliability is
> dealt in both 3.4 and 3.12, maybe both sections should be merged.
>
> 3.14 Quality
>
> What exactly is meant by Quality. Is it QoS, then say so. Otherwise,
> clarify.
>
> ------------------------------------
> Missing reqs
> -----------------------------------
> Even though you request that no new reqs be provided, let me make the
> case for one:
>
> 3.15 QoS
>
> The LMM MUST interwork with the QoS schemes to:
> 3.15.1-hide the mobility of the MN to its peer by avoiding end-to-end
> QoS signaling.
> 3.15.2-facilitate the new provisioning of both uplink and downlink QoS
> after a handoff
>
> 1- means that the uplink traffic MUST be tunneled through the LMA.
> (this is assume in the document, it must be explicited. Current LMM
> proposals
> (HMIP, RegRegv6) have an uplink that is not tunneled through the LMA.
> This allows the CN to be aware of the local mobility of the MN by
> looking at
> the source IP address.) This draft makes the assumption that the
> uplink traffic is tunneled through the LMA (section 3.4.7). It also
> mention
> provisioning in 1.3 as one of the goals of the LMM.
>
> Having an optimized (non-triangular) uplink means that in case of QoS
> renegotiation
> after handoff end-to-end for the uplink, the location is not hidden to
> the CN. It also introduces
> delays and extra signaling in having to renegotiate e2e. By having a
> potentially
> distinct uplink and downlink, it introduces the need for distinct QoS
> signaling uplink
> and downlink for re-establishment after handoff. On the other hand, by
> having
> both uplink and downlink going through the LMA, the handoff implies
> changing
> on the paths only below the LMA. One QoS re-establishment request can
be
> sent
> to the LMA for both up and downlink.
>
> 2-means that LMM and QoS (like LMM and IP routing) MUST work
> hand-in-hand.
>
>
> -----------------------------------
> Editorial comments:
> -----------------------------------
> Abstract:
> -add a sentence about relationship between administration domain
> and LM domain, or some introduction about what is LM domain.
> -"The identified requirement listed": get rid of listed, it's
redundant.
>
> -"They are intended to be used as....schemes": split in two or three
> clear sentences.
>
> 1.0 Introduction:
> -"Mobile IPv6 is presented with a number...". replace with: 'is
facing',
>
> as Mobile IPv6 is not presented in this document.
>
> 1.1 Motivation:
> -"It is well established that...loss[1]". Why quoting a paper not yet
> published if it
> is well established? Get rid of the quote, or quote a well-established
> result.
> -typo in "with its curent mobility bindings that YIELD".
> -"an interdomain Binding Update signal". Replace with "Binding
Updates"
> -Replace all both "it's" and the "it?s" with "its"
> -place the acronym "(BUs)" after "Binding Update", a couple lines
> higher,
> and not "mobility binding".
> -again, why quote [1] to say that the MN time at one AR has to be
longer
> than
> a RTT if it hopes to receive a packet.
>
> 1.2 Principles of the LMM:
> -First two sentences are redundant. Chop one.
> -"This is achieved by introducing LMM Agens....similar to a HA": this
> sentence should
> disappear, as it is solution space. Replace with something like:
> "A LMM agent concept is introduced in this draft. LMMA are the logical
> entities
> hiding the mobility within the LMMD to the outside of the LMMD" and
> modify the end
> of the paragraph accordingly.
> -this paragraph needs more editing, but I advocate to suppress it
> altogether. "regional
> care-of (RCoA) address" replaced by "regional care-of address", etc.
>
> 1.3 Consideration points for LMM design:
> -"principals" replace with "principles"
> -replace "consideration points (goals)" with "goals"
> -"when designing an LMM framework": this is not design nor framework.
> "when specifying
> LMM reqs".
> -replace "reducing" in the item list with "reduce" twice, or make all
> other introductory verbs in
> the items in the participle "ing" form.
> -the last paragraph ("Identifying..." till "...inpractice today")
> is patting itself on the back, on how "solid" the reqs in this draft
> are, "robust",
> "essential", and a sounde "foundation". While it is true, and the team
> should be thanked for
> the good work, maybe the self congratulations should be left out.
>
> 2.0 Terminology:
>
> LMM: replace "the true peers entity" with "its peers"
>
> 3.3.1 The last sentence: "this is so, since experience ...convergence"
> should be removed or rephrased.
> It is true that it is better to leave routing to routers. However, LMM
> is one big contradiction
> to this principle.
>
> 3.3.2 Maybe add "at most linearly", as "linearly" is good, but better
> than linear is even better.
>
> - "This would involve MIP-specific eliminated by any mobility
management
> protocol including
> routing state as binding caches in addition to standard routing table
> host routes. While host routes cannot be base IP mobility, any LMM
> protocol MUST keep the number of host routes to a minimum."
> This sentence should be reworded. At least, I cannot make sense of it.
>
> 3.3.5 Again, replace "true peer entities" with "peers"
>
> 3.4.5 replace " effected in the routing of the ...applied" with "in
the
> routing of the LM domain".
>
> 3.4.6 Make two sentence of the first paragraph "Any..compression",
> "Transfer of compressor...disruption".
>
> 3.4.8 replace "doesn't" with "does not"
>
> 5.0 References
> [1] Replace 'localised' with 'localized'
> [3] get rid of question marks
>
> ---------------------------------------------------
> That's about it.
> Thanks again for putting it together, hope you'll find my comments
> useful,
>
> Cedric.
>
>
>
>
>
>
>
>

---

From: "James Kempf" <[email-masked]>
Date: Thu, 15 Nov 2001 09:00:39 -0800

Hi Hesham,

> by default they can interwork.

It also says that the two MUST be deployable independently.

>    I don't get the advantage between this one and the one

For one thing, the original requirement says nothing about standard
MIPv6 handover. I think the requirements must cover all handover
possibilities, not just fast handover.

For another, as you mention, I would like to allow a solution in which
the fast handover and LMM solutions are deployable together. For
example, suppose there is a possibility of optimizing HMIPv6 to take
advantage of BETH tunnels. The current requirement would not allow this,
because it would mean that HMIPv6 and BETH would have to be deployed
together. That is the purpose of the last sentence.

            jak