Subject: [nemo] Requirements Update

From: Thierry Ernst <[email-masked]>
Date: Tue, 29 Oct 2002 13:49:19 +0900 (JST)

Hi all,

I've also updated my requirement draft with the new name:

http://www.nal.motlabs.com/nemo/drafts/draft-ernst-nemo-requirements.txt

Changes: 
- text has been much refined.

- a section "Observation" takes much of what was previously in the
  terminology draft. (so, the terminology draft is now just about the
  terminology)

- new section "Requirements for Basic Support" where I've itemized the
  requirements based on the discussion in the previous section.

  Those requirements are listed in the same fashion as proposed by
  Pascal Thubert a long time ago on the mailing list: clear short
  sentences. 

  It's not a complete list - I've not included requirements proposed
  by other people, but I've expressed them in a way that should
  clarify my point of view on the case. At least that the objective.

Don't forget that the terminology draft has also been re-structured:
http://www.nal.motlabs.com/nemo/drafts/draft-ernst-nemo-terminology.txt

Thierry

---

From: Alexandru Petrescu<[email-masked]>
Date: 29 Oct 2002 13:09:37 +0100

> http://www.nal.motlabs.com/nemo/drafts/draft-ernst-nemo-requirements.txt

Thierry, thank you for keeping your requirements draft updated.

I have remarks related to R1-18 of the new section 4 Requirements for
Basic Support.  It's excellent to have them short and concentrated in
one place of the draft, easier to discuss.

Most of the requirements still look a bit high-level to me, but maybe
that's what requirements are about, to be high-level and easy to
understand.

I'm trying to figure out whether it's possible to find a way to put
requirements on other entities than the MR.  For example, I agree with
the definition of a VMN as being a Mobile IPv6 Mobile Node that comes
into and leaves a mobile network.  But I have difficulty in thinking
that this is more than a definition, which you seem to imply, i.e.  a
requirement.

Case in point is R4.  The way in which the nemo-mrha (mobile network
with bidir tunnel MR to HA) supports VMNs and LMNs is by having MNs
that run vanilla Mobile IPv6 and that can move in two ways: (1) only
internal to the mobile network, or (2) coming from outside, move
inside the mobile network and then leave the mobile network.  This can
be accomplished by using vanilla Mobile IPv6 only, no need to
distinguish LMN and VMN for more than a scenario discussion purpose.
If we distinguish, one might be tempted into believing VMNs and LMNs
will behave differently than a Mobile IPv6 MN.  I might have lost
something in this view, please correct me if I'm wrong.

This is partly solved by R6, if I understand correctly, where it says
that MNN's are not nemo-enabled.  But then we must be sure that MR's
are not part of MNN's; the current definition says that an MNN can be
an MR, but MR's are clearly nemo-enabled.

And we should solve the "MN" problem where the name "MN" stands for
either MH and MR, while we are mostly accustomed to say "MN" for "MH"
only.

"R8: A VMN that gets attached to a link within the mobile network
obtains an address on that link."  is a requirement?  If it does not
obtain an address valid on that link then nothing works.  Or maybe we
should leave it there in order to be sure.

R13, 14: please, why do you believe that horizontal and vertical
handoffs must be supported?  If those two are MUSTs then I would also
suggest support of diagonal handoff is a MUST as well.  Or maybe
neither?

For the rest of R's I'm mostly agreeing with them and I find they are
more correctly formulated, and useful for designing an mrha solution.

Alex