Subject: RE: [Mipshop] AD review of draft-ietf-mipshop-lmm-requirements-02.txt

From: "[email-masked]" <[email-masked]>
Date: Fri, 5 Mar 2004 21:09:31 -0500

Hi Thomas,

   First thanks for the AD review.

   The document was a "requirements" document at one time
   (until recently:) and based on discussion on the alias there
   was a name change to "goals".  However,
   in this same vain, I noticed that DNA
   is working on a document that is similar
   in the use of language: i.e., "should", 
   "must"... and they are calling it a 
   "goals" document as well. However, when
   you read it, it reads as a requirements
   document. There seems to a fear by some
   to use the word "requirements".  So I am
   not sure what to do in terms of this
   aspect of your comments.

   Regarding the other comments, I will review
   more throughly (and hopefully others will
   as well) before commenting and moving forward.

   Carl

Original Message:
-----------------
From: Thomas Narten [email-masked]
Date: Sat, 06 Mar 2004 10:22:53 +0900
To: [email-masked]
Subject: [Mipshop] AD review of draft-ietf-mipshop-lmm-requirements-02.txt

The WG asked that this be published as an informational document. Here
are my review comments.

General comment. This document really reads like a "requirements"
document, in that it is full of MUST/SHOULD type language. However, a
number of the requirements are vague, don't entirely make sense, or I
simply can't agree with them (and suspect others won't either). I
don't really think the document is publishable in this form. Note: I
see that the title says "goals", but the document reads like this was
a superficial change made to title and intro but not the rest of the
document.

Some examples:

> 3.2.3 No new vulnerabilities
> 
>    LMM protocol MUST NOT introduce new security holes or the possibility
>    for DOS-style attacks.

Unrealistic. How can you have a new protocol that introduces no DOS
possibilities?

> 3.3.3 No additional messages to peer entities
> 
>    The LMM framework MUST NOT increase the number of messages between
>    the mobile host and the respective peer entities. Indeed, the LMM
>    framework MUST minimize the global signaling between the MN and its
>    peers. The amount of regional signaling MUST NOT surpass the amount
>    of global signaling that would have otherwise occurred if LMM were
>    not present.

This doesn't make sense to me. By defn, LMM is not supposed to be
visible to peers. So why is the first requirement needed?
Second,  how can LMM "minimize" (in a MUST sense) the global
signaling? I thought LMM was supposed to not impact global
signalling. I.e., it reduces the the need for it.  The last sentence
also  seems like the wrong way to capture the tradeoff. Seems to me
that increasing the local signaling if it reduces the global
signalling may well be a good tradeoff - since local signalling is by
defn. lower latencey.

> 3.4.1 Linear complexity
> 
>    The LMM complexity MUST increase at most linearly with the size of
>    the local domain and the number of Mobile Nodes.

Umm, how do you define "LMM complexity"? What is the metric you are
measuring?

> 3.4.4 No worse performance
> 
>    The LMM framework MUST NOT degrade in any way the basic IP mobility
>    performance of a mobile host communications with a peer entity.

This is too strong. Indeed, there are way to many "MUST NOTs" in this
document.

Misc comments:

>    for IP layer mobility, such Mobile IP and Mobile IPv6.  These goals

s/such/such as in/

>    The same approach applies also to a number of other IP layer mobility
>    management protocols.  For example, in the Host Identity Protocol
>    (HIP) mobility management scheme, a Mobile Node sends an Readdress
>    (REA) packet to its peer; this is very similar the Binding Updates

reference to HIP?

>    entities processes mobility management messages. If the Mobile Node

s/processes/process/

>    old Access Router. Recently, Mobile IP has been extended by certain

What's an Access Router? Do we need to use  this term in this document
(since we are talking about IP-level stuff)?

>    old Access Router. Recently, Mobile IP has been extended by certain
>    local mobility mechanisms, aiming to alleviate the above performance
>    limitations; they are identified as hierarchical/regional or more
>    generically Localized Mobility Management (LMM).

rather than "MIP has been extended" say something like:

   Several proposals for extending ... [and then cite some of them in
   an informative fashion]

>    Identifying a solid set of requirements that will render the protocol
>    internals, for some LMM scheme, robust enough to cater for the
>    aforementioned considerations becomes essential in designing a widely
>    accepted solution.  The remainder of this document present a set of
>    requirements that encompass essential considerations for the design
>    of an LMM scheme. It is with this foundation that we can seek to
>    ensure that the resulting LMM solution will best preserve the
>    fundamental philosophies and architectural principles of the Internet
>    in practice today.

the word "requirements" shows up here. Shouldn't this  be "goals" or
"desirable properties" or some such?

>    efforts that, due to gained wisdom, may wish to depart from it."

s/"//

>    Peer entity A generic name used for nodes that communicate with a
>       mobile node.  In Mobile IP and IPv6, the Home Agent and
>       Correspondent Node are peer entities.
>

Better(?):

    Peer entity: A generic name used for nodes that communicate with a
       mobile node using mobility-specific signaling.  In Mobile IP
       and IPv6, the Home Agent and Correspondent Node are peer
       entities.

(Previous definition would include any node communicating with a MN,
including the correspondent. Actually, I'm sort of confused now,
because you immediately start using "peer entity" and indicate it also
refers to a correspondent node, so why )       

> 3.1 Intra-domain mobility
> 
>    LMM is introduced to minimize the signaling traffic to the peer
>    entities, e.g. Home Agent and/or Correspondent Node(s), for
>    intra-domain mobility (within a Local Coverage Area). This is the
>    fundamental reason for introducing localized mobility management.  In
>    the LMM infrastructure a peer entity outside the administration
>    domain MUST always be able to address the mobile host by the same IP
>    address, so that from the point of view of hosts outside the
>    administration domain, the IP address of the mobile host remains
>    fixed regardless of any changes in the Mobile Node's subnet.

Seems like one thing you want to capture in the above definition is
that the from the peer entity's perspective, the MN is not moving, and
it isn't aware of any intr-domain movement.

need reference to 2119 terms.

>    The security of exchanging LMM specific information and signaling
>    MUST be ensured.  Security provisioning includes protecting the
>    integrity, confidentiality, and authenticity of the transfer of LMM
>    specific information within the administration domain. If applicable,
>    replay protection MUST exist mutually between the LMM agents.

why is confidentiality a requirement? We don't have this in MIP4 or
MIP6. Why is the requirement more imporant here (I'd think it was less
important in the LMM case compared with the global case).

> 3.2.3 No new vulnerabilities
> 
>    LMM protocol MUST NOT introduce new security holes or the possibility
>    for DOS-style attacks.

Unrealistic. How can you have a new protocol that introduces no DOS
possibilities?

> 3.3.3 No additional messages to peer entities
> 
>    The LMM framework MUST NOT increase the number of messages between
>    the mobile host and the respective peer entities. Indeed, the LMM
>    framework MUST minimize the global signaling between the MN and its
>    peers. The amount of regional signaling MUST NOT surpass the amount
>    of global signaling that would have otherwise occurred if LMM were
>    not present.

This doesn't make sense to me. By defn, LMM is not supposed to be
visible to peers. So why is the first requirement needed?
Second,  how can LMM "minimize" (in a MUST sense) the global
signaling? I thought LMM was supposed to not impact global
signalling. I.e., it reduces the the need for it.  The last sentence
also  seems like the wrong way to capture the tradeoff. Seems to me
that increasing the local signaling if it reduces the global
signalling may well be a good tradeoff - since local signalling is by
defn. lower latencey.

> 3.4.1 Linear complexity
> 
>    The LMM complexity MUST increase at most linearly with the size of
>    the local domain and the number of Mobile Nodes.

Umm, how do you define "LMM complexity"? What is the metric you are
measuring?

>    those ARs/ANRs involved in implementing the LMM protocol at hand.

what is an ANR?

> 3.4.2 Linear routing state growth
> 
>    Any Localized Mobility Management protocol MUST assure that that LMM
>    routing state scales at most linearly with the number of Mobile Nodes
>    registered, and that the increase in routing state is confined to
>    those ARs/ANRs involved in implementing the LMM protocol at hand.
>    While host routes apparently cannot be eliminated by any mobility
>    management protocol including base IP mobility, any LMM protocol MUST
>    keep the number of host routes to a minimum.

Are their proposals do not meet the above?

> 3.4.4 No worse performance
> 
>    The LMM framework MUST NOT degrade in any way the basic IP mobility
>    performance of a mobile host communications with a peer entity.

This is too strong. Indeed, there are way too many "MUST NOTs" in this
document.

> 3.4.5 Scalable expansion of the network
> 
>    The LMM framework MUST allow for scalable expansion of the network
>    and provide for reasonable network configuration with regard to
>    peering, inter-administrative domain connectivity, and other
>    inter-administrative domain interoperability characteristics of
>    interest to wireless ISPs. The LMM framework MUST NOT introduce any
>    additional restrictions in how wireless ISPs configure their network,
>    nor how they interconnect with other networks beyond those introduced
>    by standard IP routing.  In addition, the amount of regional
>    signaling MUST NOT increase as the Local Domain expands in size.

I don't really understand what this is trying to say.

> 3.4.6 Resilience to topological changes
> 
>    The LMM protocols MUST be topology-independent. The LMM protocols
>    MUST be able to adapt to topological changes within the domain. The
>    topological changes may include the addition or removal/failure of
>    LMM agents or that of changes in the routing of the local domain over
>    which the LMM scheme is applied.

dont understand. Or is this  so obvious that I trying to look for a
more significant requirement?

> 3.4.8 Optimized signaling within the Local Coverage Area
> 
>    By its very nature, LMM reintroduces triangle routing into the base
>    IP layer mobility protocol in that all traffic must go through the
>    LMM agent. There is no way to avoid this. The LMM framework SHOULD be
>    designed in such a way as to reduce the length of the unwanted
>    triangle leg.  The LMM design SHOULD not prohibit optimal placement
>    of LMM agents to reduce or eliminate additional triangle routing
>    introduced by LMM.
>    NOTE: It is not required that a LMM scheme specify LMM agents as part
>    of its solution.
> 

This is the first mention of the LMM agent. Shouldn't  this be near
the front, as part of a general overview?

> 3.5.1 No increase of latency or packet loss
> 
>    The LMM framework MUST NOT increase the amount of latency or amount
>    of packet loss, compared to what exists with the core Mobile IP and
>    Mobile IPv6 specification [1][2]. Indeed, the LMM framework SHOULD
>    decrease the amount of latency or amount of packet loss that exists
>    with the core mobility protocols.

again a must not. Does this mean it can never ever happen? Even in
weird configurations? How can you prevent this from ever happening?
Seems like a silly MUST NOT. Clearly, its a SHOULD NOT, and if a
protocol doesn't acheive this in general, nobody is going to deploy
it.

> 3.6 Auto-configuration capabilities for LMM constituents
> 
>    It is desirable that in order to allow for simple incremental
>    deployment of an LMM scheme, the local mobility agents MUST require
>    minimal (if any) manual configuration. This plug-and-play feature

"MUST require minimal"? How  do you evaluate this sort of requirement?

> 3.12 Quality of Service requirements

I do not understand what is  being said here.

>       unauthorized redirection traffic, and

s/traffic/of traffic/

(didn't read the security section yet.)

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Thomas Narten <[email-masked]>
Date: Mon, 15 Mar 2004 14:02:19 -0500

>    The document was a "requirements" document at one time (until
>    recently:) and based on discussion on the alias there was a name
>    change to "goals".  However, in this same vain, I noticed that
>    DNA is working on a document that is similar in the use of
>    language: i.e., "should", "must"... and they are calling it a
>    "goals" document as well. However, when you read it, it reads as
>    a requirements document. There seems to a fear by some to use the
>    word "requirements".  So I am not sure what to do in terms of
>    this aspect of your comments.

Please don't look towards the DNA document for justification for what
you are doing here. They may be copying the example in your
document... :-)

The problem with upper case language SHOULD (and especially MUST) is
that it comes across as very absolute. That can be fine (sometimes),
but not if the point is actually not a clear or a real requirement (as
in some of the cases I cite below) or where you end up with two or
three MUST/SHOULD requirements that clearly conflict with each
other. For example, having two conflicting MUST/SHOULds just isn't
helpful, generally.

If you want the document to be goals, it is also helpful to explain
where one goal might be in conflict with another goal. Lack of this
sort of discussion can make it seem like the requirements are just a
marketing wish list with no real understanding of whether its possible
to achieve them.

Thomas