Subject: [nemo] comments on requirements draft

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Tue, 18 Feb 2003 12:21:59 +0100

Hi Thierry/all, 

Some comments on the requirements draft. Apologies
if any othis was already discussed. 

Technical
---------
Section 4: 
  Performance transparency. Perhaps it's better to describe
  the seamlessness requirement in relative terms to MIP. I.e.
  the mobility will be as seamless as MIP can make it. Because
  after all MIPv6 (without optimisations) will not be seamless
  at all and we don't want to be responsible for that in nemo.

  Network mobility transparency. Shouldn't the 'should' in
  the last line be a 'must'?

  Scalability. I'm not sure I get this requirement, is this 
  measurable?

  Backward compatibility. I don't mind having this solution
  work with FMIPv6 (perhaps you should expand this term or 
  write it as a reference) but I think we might get basic support
  before FMIPv6! 

On R12: the draft does not mention any requirements 
on access selection by the MR in the case where
the mobile network is multihomed. There are two
cases I can think of: 

 1. The MR decides (unilaterally) to forward some
    flows on one interface and others on a different
    one. This is particularly possible when there is only
    one MR with multiple interfaces. 

  2. Some exchange of information between the MR
     and nemo-aware MNNs results in a preferred interface
     for certain flows originating from certain MNNs. 

So what is the requirement?` something like:
"The solution should allow nemo-aware MNNs to request 
that certain flows be forwarded on certain interfaces
and provide some recommendations that allow MRs to
select the right interface(s) for other MNNs."

On R15: Is this really needed? I would think that we 
want the solution to be transparent to the routing 
infrastructure on the home and visited links. But this
requirement is mandating running routing protocols over
the tunnel. I'm not sure that the requirements draft should
get into the specifics of the solution space. It already
does with the bidirectional tunnel but this is a high
level direction and is in the charter.

Editorial
---------

- You might want to reference the terminology draft
before the introduction since you already use terms like
MR/MNNs in the intro

- In many places you mention the 'IP layer level'. I think
that 'level' is superfluous.

- Remove '...' from R10.

- Any reason why R13.3's keyword is not upper case?
Also shouldn't R13.X be R12.X (like the way R14 is done)?

---

From: Alper Yegin <[email-masked]>
Date: Wed, 19 Feb 2003 16:21:08 -0800

> select the right interface(s) for other MNNs."

This sounds like a traffic engineering optimization,
that any multi-homed network can use. While it's
not specific to multi-homed "NEMO", probably the benefits of
such a capability is higher here since MR's links vary
greater in their characteristics and they come and go
more often.

IMHO, this is an additional optimization/feature that
can be considered later, not for the initial NEMO protocol.

alper

---

From: Christophe Janneteau<[email-masked]>
Date: Thu, 20 Feb 2003 09:21:15 +0100

Hi Hesham,

>   the last line be a 'must'?

yes and no :)
This is my understanding:
- It is a MUST for the basic mode as specified in section 5/R06
- However section 4 deals with general guidelines for both basic and
extended mode. So the SHOULD here is to leave the door open for MNN to
take part in RO for instance....This "should" could be changed to a
"must" once requirements for the extended mode will be produced...

Bye,
Christophe