Subject: [nemo] Next steps in RO - was :draft-ietf-nemo-ro-space-analysis-01.txt

From: Thierry Ernst <[email-masked]>
Date: Tue, 1 Nov 2005 16:16:37 +0900

Hi,

On Mon, 31 Oct 2005 18:58:04 +0100
Alexandru Petrescu <[email-masked]> wrote:

> I agree with issue numbers that have been suggested by myself -
> they've been dealt with.  It was about CA and MNN terms.  The first
> one is integrated (became CE) and the last one isn't and probably will
> never be("MNN" is here to stay).

Note that I took the benefit of being late to send the terminology
document to the IESG to add this term in the terminology. (so it's
sometimes positive to be late - wasn't this on purpose, indeed ? ;-)

> The draft looks good to me overall, has good abstract and a relatively
> complete analysis of possible RO solutions for NEMO.  It's also good
> for me it doesn't have strong recommendations.
> 
> It should be used as a good starting point for designing a NEMO RO
> solution, when time arrives.

Time has arrived ! We need to discuss right now what will be the next
steps of the NEMO WG - shutting down, or rechartering ? - and if these
next steps include or not some work on RO and if so which one. 

I think authors of the drafts have done their part of the work, so now
it's our turn as a WG to decide where to go from now. 

Thierry

> Chan-Wah Ng wrote:
> 
> > Hello all,
> > 
> > Some "advertisements" for this draft :)
> > 
> > The change-log says:
> > 
> > o  draft-ietf-nemo-ro-space-analysis-01: *  Changed the term
> > "Correspondent Agent" to "Correspondent Entity" [Issue #13] *  Added
> > clarifying text to some benefits listed in Sect 2 [Issue #14] *
> > Added clarifying text to Sect 4.1, 4.3 and 4.4 [Issue #5, #6, #16] *
> > Added Section 4.9 [Issue #3] *  Added clarifying text to various
> > parts of Sect 5 [Issue #7, #8, #9, #11, and #16] *  Combined "MR as
> > a Proxy" and "MR as a Transparent Proxy" in Sect 5.5.1 [Issue #11] *
> > Changed the term "identity of MNN" to "address of MNN" in Sect 5.5
> > [Issue #12] *  Added text on signaling using upper layer protocols
> > in Sect 5.6 *  Added more security consideration to Sect 5.8 [Issue
> > #15]
> > 
> > 
> > As seen above, this version mainly addresses the issues brought up
> > for -00. The issues list is now available at:
> > 
> > http://www.mobilenetworks.org/~chanwah/rosa/issues.html
> > 
> > I would appreciate if the originators of the issues (i.e. Jari,
> > Carlos, Alexandru) check through to see if the issues are
> > sufficiently dealt with in -01.
> > 
> > Thanks,
> > 
> > /rgds /cwng
> > 
> > 
> > On Thu, 2005-10-27 at 10:50 -0400, [email-masked] wrote:
> > 
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories. This draft is a work item of the Network Mobility
> >> Working Group of the IETF.
> >> 
> >> Title		: Network Mobility Route Optimization Solution Space
> >> Analysis Author(s)	: C. Ng, et al. Filename	:
> >> draft-ietf-nemo-ro-space-analysis-01.txt Pages		: 40 Date		:
> >> 2005-10-27  With current Network Mobility (NEMO) Basic Support, all
> >>  communications to and from Mobile Network Nodes must go through
> >> the MRHA tunnel when the mobile network is away.  This results in 
> >> increased length of packet route and increased packet delay in most
> >>  cases.  To overcome these limitations, one might have to turn to 
> >> Route Optimization (RO) for NEMO.  This memo documents various
> >> types of Route Optimization in NEMO, and explores the benefits and 
> >> tradeoffs in different aspects of NEMO Route Optimization.
> >> 
> >> A URL for this Internet-Draft is: 
> >>
> >http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysi
> >s-01.txt>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 02 Nov 2005 12:06:07 +0100

Hi Chan-Wah,

I've checked the changes made in the new version of the I-D and I have
some minor comments (just typos):

Issue #3 (Support of LFR):

- Typo: "Optimization schemes" instead of "Optimization shcemes"

Issue #11 (MIRON cited as Transparent Proxy)

- Typo: "initiate the Return" instead of "initiate teh Return"
- Typo: "transparently alter" instead of "transparently alters"

I'm fine with the rest of the text.

Thanks a lot.

Kind Regards,

Carlos J.

El lun, 31-10-2005 a las 21:07 +0800, Chan-Wah Ng escribió: 
>    o  draft-ietf-nemo-ro-space-analysis-01:
>       *  Changed the term "Correspondent Agent" to "Correspondent
>          Entity" [Issue #13]
>       *  Added clarifying text to some benefits listed in Sect 2 [Issue
>          #14]
>       *  Added clarifying text to Sect 4.1, 4.3 and 4.4 [Issue #5, #6,
>          #16]
>       *  Added Section 4.9 [Issue #3]
>       *  Added clarifying text to various parts of Sect 5 [Issue #7, #8,
>          #9, #11, and #16]
>       *  Combined "MR as a Proxy" and "MR as a Transparent Proxy" in
>          Sect 5.5.1 [Issue #11]
>       *  Changed the term "identity of MNN" to "address of MNN" in Sect
>          5.5 [Issue #12]
>       *  Added text on signaling using upper layer protocols in Sect 5.6
>       *  Added more security consideration to Sect 5.8 [Issue #15]
> 
> As seen above, this version mainly addresses the issues brought up for -00.
> The issues list is now available at:
> 
> I would appreciate if the originators of the issues (i.e. Jari, Carlos,
> Alexandru) check through to see if the issues are sufficiently dealt
> with in -01.
> 
> Thanks,
> 
> /rgds
> /cwng
> 
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Network Mobility Working Group of the IETF.
> > 
> > 	Title		: Network Mobility Route Optimization Solution Space Analysis
> > 	Author(s)	: C. Ng, et al.
> > 	Filename	: draft-ietf-nemo-ro-space-analysis-01.txt
> > 	Pages		: 40
> > 	Date		: 2005-10-27
> > 	
> > With current Network Mobility (NEMO) Basic Support, all
> >    communications to and from Mobile Network Nodes must go through the
> >    MRHA tunnel when the mobile network is away.  This results in
> >    Route Optimization (RO) for NEMO.  This memo documents various types
> >    of Route Optimization in NEMO, and explores the benefits and
> > http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-01.txt
> > 
> > To remove yourself from the I-D Announcement list, send a message to 
> > [email-masked] with the word unsubscribe in the body of the message.  
> > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> > to change your subscription settings.
> > 
> > 
> > Internet-Drafts are also available by anonymous FTP. Login with the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > 	"get draft-ietf-nemo-ro-space-analysis-01.txt".
> > 
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html 
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	[email-masked].
> > In the body type:
> > 	"FILE /internet-drafts/draft-ietf-nemo-ro-space-analysis-01.txt".
> > 	
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> > 		
> > 		
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> > _______________________________________________
> > I-D-Announce mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/i-d-announce
> 
-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: BFF1 7C7A 6AA7 BCE3 885A  4DF1 ED0C 5952 BF89 B974

---

From: "T.J. Kniveton" <[email-masked]>
Date: Wed, 2 Nov 2005 10:02:09 -0800

> it's our turn as a WG to decide where to go from now.

Folks,

Please let's have some more discussion on this point. What are  
important aspects of RO that NEMO should work on, and why?

Is this area still too undeveloped for standardization? Perhaps RO in  
mobile networks should be turned over to MOBOPTS and the IRTF for  
further research?

TJ

---

From: Chan-Wah NG <[email-masked]>
Date: Thu, 03 Nov 2005 14:36:43 +0800

Hello all,

> mobile networks should be turned over to MOBOPTS and the IRTF for  

I am contributing my two cents.

Judging by the number of proposals since begining, I think there are
definitely interest in having a standardized RO solution.  The danger of
moving this to the IRTF is that (1) the IRTF is not chartered to produce
standard, (2) it will take a lot longer.

I do not know what is IETF's basis for moving work to IRTF.  Can someone
shed a light on this?  When there are too many competing proposals?  Or
when there is not enough knowledge in the particular problem area for
there to be a sound engineering solution to the problem?

Now that the solution space is starting to be analyzed, people should
have a better understanding of the scope of RO work in NEMO.  I don't
know whether the work we did would suggest to people that we know the
solution space well enough to engineer a solution, or that we do not
know enough and more research work has to be done. :)  I peronally would
like to think its the former though :).  But that is the first thing the
WG should decide: Based on what is documented in the two RO drafts, do
the WG feel that there is more research work that needs to be done?  If
yes, what are they?  If not, I don't wee why the NEMO WG should not be
re-chartered to develop the RO solution.

If we are to go forward and devise an RO solution, I think it is
definitely not a single piece of solution.  Instead, I see a lot of
different pieces to the puzzle. 

My personal views are that the following 3 main pieces are needed:

(1) A mechanism for MNNs to send packet from where the NEMO is attached.

This mechanism would allow MNNs, however deeply they are nested, to
appear to a node outside the NEMO as if they are a simple mobile node.
attached to the point of attachement of the root-MR.  This mechanism
would allow a solution to the nested mobile HA problem, and the security
policy prohitbiting visitor traffic problem.  Not only that, it also
allows VMN to operate MIPv6 RO without being subjected to NEMO-BS
tunnel.

(2) A mechanism for MRs to offer route optimization to LFNs.

This is less important, but it's a mean to complete the entire RO
process.  The mechanism above will allowed modified nodes (i.e. VMN) to
achieve RO in a way compatible to the more "legacy" MIPv6 RO.  This
mechanism, will allow RO to be achieved for unmodified LFNs.

(3) A correspondent router solution.

The deployment of such an entity would allow two benefits: (1) perform
RO for non-modified CNs, and (2) the discovery of MR by other mobile
nodes, if this MR is treated as a CR.

Some of the above may require future research, and may encompass a lot
of smaller but significant issues to be solved.  One can in fact have
the NEMO WG re-chartered to work on only 1 or 2 of the above, and have
the rest moved to IRTF for futher research.

/rgds
/cwng

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 03 Nov 2005 10:29:45 +0100

Dear all,

	I completely agree with Chan-Wah. I also think that there are people
interested in working on a NEMO RO solution and I also share his view
about that it's more likely to have a set of different solutions, each
of them, solving a different part/scenario of the NEMO RO problem.

	My two cents.

	Kind Regards,

	Carlos J.

P.S.: If the WG is also asking people about which NEMO RO topics they
are working on or they'd like to work on, we have been/keep working on
what Chan-Wah calls pieces 1 and 2.

---

From: "T.J. Kniveton" <[email-masked]>
Date: Fri, 4 Nov 2005 14:01:45 -0800

On Nov 2, 2005, at 10:36 PM, Chan-Wah NG wrote:

>  This
[...]
> RO for non-modified CNs,

I would assume that LFNs (by definition) and CNs (by convention)  
would be unmodified by NEMO/MIPv6. Any statement to the contrary  
should contain a really good motivation and explanation for what  
should be modified and why.

TJ

---

From: Thierry Ernst <[email-masked]>
Date: Sat, 5 Nov 2005 09:09:32 +0900

> > The deployment of such an entity would allow two benefits: (1)
> > perform RO for non-modified CNs,
> 

While I think this is desirable, I think the contrary is not a problem
(as long as there are motivations for changing nodes) since this is an
optimization. An optimization doesn't need to leave all nodes unchanged;
nodes with no extensions could just not use the optimized path, but
could still use the non-optimized path.

So, I share TJ concerns, but this is not a design requirement IMHO.

Thierry

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 24 Nov 2005 20:32:13 +0900

Hi,

I have some more comments on ROSA - see inline - but before I do so,
thanks very much for the nice writing of this draft !

The only real problem I have with the document is that the draft refers
to so many drafts that will be expired at some point in time but besides
this I think you have performed a very good and educative  work in a
very limited period of time !

      Network Mobility Route Optimization Solution Space Analysis
                  draft-ietf-nemo-ro-space-analysis-01

Abstract

1.  Introduction

   Network Mobility Route Optimization Problem Statement [1] describes
   operational limitations and overheads incurred in a deployment of
   Network Mobility (NEMO) Basic Support [2], which could be alleviated
   by a set of NEMO Route Optimization techniques to be defined.  For
   this purpose of NEMO, the term "Route Optimization" is accepted in a
   broader sense than already defined for IPv6 Host Mobility in [3], to
   loosely refer to any approach that optimizes the transmission of
   packets between a Mobile Network Node and a Correspondent Node.

The defintion of RO above will appear in the terminology document.

   It is expected for readers to be familiar with general terminologies

s / with general terminologies / with the terminology

   related to mobility in [3] and [4], and NEMO related terms defined in
   [5].  

The sentence above should better be moved to the section terminology
below.

   In addition, it is beneficial to keep in mind the design
   requirements of NEMO [6].  A point to note is that since this
   document discusses aspects of Route Optimization, the readers may
   assume that a mobile network or a mobile host is away when they are
   mentioned throughout this document, unless it is explicitly specified
   that they are at home.

Wouldn't it better to move this in a section "assumption" where it would
also be stated/ re-stated that NEMO Basic Support assumes a
bi-directional tunnel to be established between any pair of (MR, its
HAs)  ?

1.1.  Terminology

You should write here the sentence that the terminology is defined in
[3] and [4]. The terms below should still be in this section, but you
should clarify that these termed are defined in [5] and copied here for
purposes of clarity / reminder.

   Correspondent Router (CR)

      This refers to the entity which is capable of terminating a Route

s / entity / router ???

      Optimization session on behalf of a Correspondent Node.

   Correspondent Entity (CE)

      This refers to the entity which a Mobile Router or Mobile Network
      Node attempts to establish a Route Optimization session with.
      Depending on the Route Optimization approach, the Correspondent
      Entity maybe a Correspondent Node or Correspondent Router.

I wonder if "Mobile Entity" (MR, or MNN) wouldn't allow you to simplify
things later in the document.

2.  Benefits of NEMO Route Optimization

As the text is written, shouldn't this rather be entitled "Design Goals
of NEMO RO" ?

   o  Greater Data Efficiency

s / Greater Data Efficiency / Reduced Packet Overhead ????

      Depending on the actual solution for NEMO Route Optimization, the
      data packets exchanged between two end nodes may not require as
      many levels of encapsulation as that in NEMO Basic Support.  This
      would mean less packet overheads, and higher data efficiency.  In
      particular, avoiding packet fragmentation that may be induced by
      the multiple levels of tunneling is critical for end-to-end
      efficiency from the viewpoints of buffering and transport
      protocols.

   o  Avoiding the Bottleneck in Home Network

s / in Home / in the Home

      NEMO Route Optimization allows traffic to by-pass the Home Agents.

s / alows / would allow  [in paragraphs "may", "should" etc are
used]

      Apart from having a more direct route, this also avoids routing
      traffic via the home network, which may be a potential bottleneck
      otherwise.

   o  Avoid the Security Policy Issue

Don't you rather mean "Ingress Filtering" ?

      Security policy may forbid Mobile Routers from tunneling traffic
      of Visiting Mobile Nodes into the home network of Mobile Router.

s / of Mobile / of the Mobile 

      Route Optimization can be used to avoid this issue by forwarding
      traffic from Visiting Mobile Nodes directly to their destination
      without going through the home network of the Mobile Router.

      It should however be taken into consideration that a Route
      Optimization mechanism may not be an appropriate solution since
      the Mobile Router may still be held responsible for illegal
      traffic sent from its Mobile Network Nodes even when Route
      Optimization is used.  In addition, there can be a variety of
      different policies which might cause a conflict with the
      deployment of Route Optimization for Visiting Mobile Nodes.  Being
      a policy issue, solving this with a protocol at the policy plane
      might be more appropriate.

   o  Avoid the Instability and Stalemate

      [1] described a potential stalemate situation when a Home Agent is
      nested within a Mobile Network.  Route Optimization may circumvent
      such stalemate situations by directly forwarding traffic upstream.
      However, it should be noted that certain Route Optimization
      schemes may require signaling packets to be first routed via the
      Home Agent before an optimized route can be established.  In such
      cases, a Route Optimization solution cannot avoid the stalemate.

I'm not sure the paragraph above is clear enough.

3.1.  Basic NEMO Route Optimization

I would find another word instead of "Basic". What about "not nested" ?

   We start off with a scenario where nesting of Mobile Routers is not
   considered, and Route Optimization is initiated and performed between
   a Mobile Router and its peer Mobile Router, also known as a
   Correspondent Router.  Such solutions are often posed with a
   requirement to leave the Mobile Network Nodes untouched, as with the
   NEMO Basic Support protocol, and therefore Mobile Routers handle the
   optimization management on behalf of the Mobile Network Nodes.  Thus,
   providing Route Optimization for Visiting Mobile Node is often out of
   scope for such scenario because such interaction would require
   extensions to the Mobile IPv6 protocol.  This scenario is illustrated
   in Figure 1.

   From the definition of Correspondent Router, it does not limit itself
   to be mobile, but can also be an entity within the fixed
   infrastructure with similar functionalities.  As long as the

To me it looks like you are taking thinkgs from the reverse order and
not very logical. Why not starting with the fixed case in the first
place, and later in the section explain the a CR may indeed be mobile
and thus be a mobile router, etc ? 

   This form of optimization can carry traffic both directions identical
   to the previous example in Figure 1, or independently for the 2
   directions of traffic:

s / traffic both / traffic in both 

can carry traffic both directions identical = ?? Please rephrase.

   A straight-forward approach to Route Optimization in NEMO is for the
   Mobile Router to attempt Route Optimization with a Correspondent
   Entity.  This can be viewed as a logical extension to NEMO Basic

Here again, it's not very logical. Above, the term "CR" is used, so why
would one use "CE" now ? 

   Support, where the Mobile Router would send binding updates
   containing one or more Mobile Network Prefix options to the
   Correspondent Entity.  The Correspondent Entity having received the
   binding update, can then set up a bi-directional tunnel with the

3.2.  Nested Mobility Optimization

   Optimization in Nested Mobility targets scenarios where a nesting of
   mobility management protocols is created (i.e.  Mobile IPv6 enabled
   host inside a mobile network or multiple Mobile Routers that attach
   behind one another creating a nested mobile network).  Note that
   because Mobile IPv6 defines its own Route Optimization mechanism in
   its base protocol suite as a standard, collaboration with this and
   NEMO brings various complexity.

NEMO = NEMO Basic Support ?

3.3.  Infrastructure based Optimization

   Alternatively, another approach is to use prefix delegation.  Here,
   each Mobile Router in a nested mobile network is delegated a mobile
   network prefix from the access router using DHCP Prefix Delegation

>From which AR ? AR from the parent-NEMO or root-NEMO ?

   [14].  Each Mobile Router also autoconfigures its care-of address
   from this delegated prefix.  In this way, the care-of addresses of
   each Mobile Router are all from an aggregatable address space
   starting from the access router.  This may be used to eliminate the
   multiple tunnels caused by nesting of Mobile Nodes.

3.4.  Intra-NEMO Optimization

   Another possibility is for the "Basic NEMO Route Optimization"
   technique (see Section 3.1) to be applied here.  Using the same
   example of communication between MNN1 and MNN2, both MR3 and MR2 can
   treat MR5 as Correspondent Routers for MNN2, and MR5 treats MR3 and
   MR2 as Correspondent Routers for MNN1.  An example of this approach
   is [15] which have Mobile Routers announce their Mobile Network
   Preifxes to other Mobile Routers in the same nested Mobile Network.

s / which have / which has

4.  Issues of NEMO Route Optimization

Wouldn't it be better to phrase this as "requirements" rather than
"issues" ?

4.3.  Increased Delay during Handoff

   Another NEMO specific delay during handoff is that in a nested mobile
   network, a child Mobile Network Node may need to detect or be
   notified of the handoff of its parent Mobile Router so that it can
   begin signaling its own Correspondent Entities.  Apart from the
   compromise of mobility awareness and location privacy, this mechanism
   also increases the delay during handoffs.

Isn't this another issue/requirement: you are kind or releaving the
"mobilty support transparency" requirement. (you may group some text
from 4.3 and 4.7)

   Some of the solutions for Mobile IPv6, such as Fast Handoff for
   Mobile IPv6 [16], may be able to alleviate the increase in handoff
   delay.

4.4.  New Functionalities

Is this an issue ? Isn't there a better place ?

4.5.  Detection of New Functionalities

Is this an issue ? Isn't there a better place ?

   One issue that is related to the need for new functionalities as
   described in Section 4.4 is the need to detect the existence of such
   functionalities.  In these cases, a detection mechanism might be
   helpful to allow the initiator of Route Optimization to detect if
   support of the new functionalities are available.  Furthermore, it
   might be advantageous to have a graceful fall back procedure if the
   required functionalities are unavailable.

4.7.  Mobility Transparency and Location Privacy

   One advantage of NEMO Basic Support is that the Correspondent Nodes
   and Mobile Network Nodes need not be aware of the actual location and
   mobility of the mobile network.  With Route Optimization, it might be
   necessary to reveal the point of attachment of the Mobile Router to
   other nodes, such as the Mobile Network Nodes or their Correspondent
   Nodes.  This may mean a tradeoff between location privacy [17] (and
   mobility transparency) and Route Optimization.

Agree with location privacy, but mobility may still be transparent to
MNNs. You shouldn't group these issues/requirements togethers.

4.9.  Support of Legacy Nodes

   NEMO Basic Support is designed so that all legacy Mobile Network
   Nodes (such as those who are not aware of the mobility of the network
   they are in, and those that do not understand any mobility protocols)
   can still reach and be reached from the Internet.  Some Route
   Optimization shcemes, however, require that all Mobile Routers to

schemes

   implement the same Route Optimization scheme in order for them to
   operate.  For instance, a nested Mobile Router may not be able to
   achieve Route Optimization if it is attached to a legacy Local Fixed
   Router.

I cannot find a link between the sentence "For instance ..." and the
previous one.

5.  Analysis of Solution Space

   4.  How is address of Mobile Network Node represented?

s / is the address

   5.  How is address of Mobile Network Node bound to location of mobile
       network?

s / is the address

   6.  How is signaling done?

s / done / performed

   7.  How is data transmitted?

   8.  What are the security considerations?

5.1.  Which Entities are Involved?

   There are many combinations of entities involved in Route
   Optimization.  When considering the role each entity plays in Route
   Optimization, one has to bear in mind the considerations described in
   Section 4.4 and Section 4.5.  Below is a list of combinations to be
   discussed in the following subsections:

   o  Mobile Network Node and Correspondent Node

   o  Mobile Router and Correspondent Node

   o  Mobile Router and Correspondent Router

   o  Entities in the Infrastructure

5.1.1.  Mobile Network Node and Correspondent Node

   A Mobile Network Node can establish Route Optimization with its
   Correspondent Node, possibly the same way as a Mobile Node
   establishes Route Optimization with its Correspondent Node in Mobile
   IPv6.  This would achieve the most optimal route, since the entire
   end-to-end path is optimized.  However, there might be scalability
   issues since both the Mobile Network Node and the Correspondent Node

To the condition the MNN knows when it is located in a nested NEMO. 
This is just an observation, but, from this, I came to think you may be
able to draw a table issues/requirements vs scenarios 5.1.1-4.

   may need to maintain many Route Optimization sessions.  In addition,
   new functionalities would be required for both the Mobile Network
   Node and Correspondent Node.

What kind of functionalities ? In 5.1.3 you briefly detail what the
functionalities should be, I think the same should be done in each
section. Here there might be a need for the MNN to know its "depth" in
the NEMO.

5.1.2.  Mobile Router and Correspondent Node

   Alternatively, Mobile Router can establish Route Optimization with a

s / the Mobile Router 

   Correspondent Node on behalf of the Mobile Network Node.  Since the
   Mobile Router is merely one hop away from the Mobile Network Node,

Not in the nested case.

   this effectively achieves an optimal route for the entire end-to-end
   path as well.  Compared with Section 5.1.1, the scalability issue
   here may be remedied since it is possible for Correspondent Node to
   maintain only one session with Mobile Router if it communicates with
   many Mobile Network Nodes associated with Mobile Router.

s / with the same Mobile Router

I think that in most cases the sessions would be split between several
(potentialy nearby) CNs., so this observation is more realistic in the
CR case.

5.2.  Who and When to Initiate Route Optimization?

   A related question is how often signaling messages should be sent to
   maintain the Route Optimization session.  Typically, signaling
   messages is likely to be sent whenever there is topological changes.
   The discussion in Section 4.1 should be considered.  In addition, a
   Lifetime value is often used to indicate the period of validity for
   the Route Optimization session.  Signaling messages would have to be
   sent before the Lifetime value expires in order to maintain the Route
   Optimization session.  The choice of Lifetime value needs to balance
   between different considerations.  On one hand, a short Lifetime
   value would increase the amount of signaling overhead.  On the other
   hand, a long Lifetime value may expose the Correspondent Entity to
   the risk of having an obsolete binding cache entry, which creates an
   opportunity for an attacker to exploit.

Just wondering: shouldn't the tradeoffs be discussed in section 4, in an
independant paragraph ?

5.3.  How to Detect Route Optimization Capability?

   mechanism is using in-band-signalling.

s / signalling / signaling

5.4.  How is Address of Mobile Network Node Represented?

s / is / is the 

   Normally, Route Optimization would mean that a binding between the
   address of Mobile Network Node and the location of the mobile network

s / of / of a 

   is registered at the Correspondent Entity.  Before exploring into
   different ways of binding (see Section 5.5), one must first ask how
   the address of the Mobile Network Node is represented.  Basically,
   there are two ways to represent the Mobile Network Node's address:

   o  inferred by the use of Mobile Network Prefix, or

   o  explicitly specifying the address of Mobile Network Node.

s / of / of the

   Using the Mobile Network Prefix would usually mean that the initiator
   is the Mobile Router, and has the benefit of binding numerous Mobile
   Network Nodes with one signaling.  However, it also means that if
   location privacy is compromised, the location privacy of an entire
   Mobile Network Prefix will be compromised.

s / will / would

   On the other hand, using the Mobile Network Node's address would mean
   that the initiator is either the Mobile Network Node itself, or the
   Mobile Router is initiating Route Optimization on behalf of the
   Mobile Network Node.  Initiation by the Mobile Network Node itself
   means that the Mobile Network Node must have new functionalities
   implemented, while initiation by the Mobile Router means that the
   Mobile Router must maintain some Route Optimization states for each
   Mobile Network Node.

5.5.  How is Mobile Network Node's Address Bound to Location?

   In order for route to be optimized, it is generally necessary for the
   Correspondent Entity to create a binding between the address and the
   location of the Mobile Network Node.  This can be done in the
   following ways:

   o  binding the address to the location of the parent Mobile Router;

   o  binding the address to a sequence of locations of upstream Mobile
      Routers; and

   o  binding the address to the location of the root Mobile Router

Don't we need to discuss "binding a prefix" ?  Also, shouldn't we
use the term "locator" ?

   These will be described in the following sub-sections.

s / will be / are 

5.5.1.  Binding to the Location of Parent Mobile Router

   o  Binding Update with Mobile Network Prefix

      mobile network prefix will be routed through the bi-directional
      tunnel.

s / will / would

      Note that in this case, the address of the Mobile Network Node is
      implied by the Mobile Network Prefix (see Section 5.4).

   o  Sending Information of Parent Mobile Router

      This involves the Mobile Network Node sending the information of
      its Mobile Router to the Correspondent Entity, thus allowing the
      Correspondent Entity to establish a binding between the address of
      the Mobile Network Node to the location of the parent Mobile
      Router.  An example of such an approach would be [10].

   o  Mobile Router as a Proxy

      Another approach is for the parent Mobile Router to act as a
      "proxy" for its Mobile Network Nodes.  In this case, the Mobile
      Router uses standard Mobile IPv6 Route Optimization procedure to
      bind the address of a Mobile Network Node to the Mobile Router's
      care-of address.  For instance, when the Mobile Network Node is a
      Local Fixed Node without Mobile IPv6 Route Optimization
      functionality, the Mobile Router may initiate teh Return
      Routability procedure with a Correspondent Node on behalf of the
      Local Fixed Node.  An example of such an approach would be [19].

CN or CE ?

5.5.2.  Binding to a Sequence of Locations of Upstream Mobile Routers

   One question that immediately comes to the mind is how the Mobile

s / the mind / mind

   Network.  In addition, some amount of modifications or extension to
   existing protocols is also required, such as a new type of IPv6
   routing header, or new options in Router Advertisement messages.

please choose either "singular form" or "plural form".

5.5.3.  Binding to the Location of Root Mobile Router

   o  Neighbor Discovery Proxy

      This approach (such as [23]) achieves Route Optimization by having
      Mobile Routers to act as a Neighbor Discovery [24] proxy for its

s / its / their ?

      Mobile Network Nodes.  Mobile Router will configure a care-of
s / Mobile Router / the root Mobile Router ?

      address from the network prefix advertised by its access router,
      and also relay this prefix to its subnets.  When a Mobile Network
      Node configures an address from this prefix, the Mobile Router
      will act as a Neighbor Discovery proxy on its behalf.  In this

when ... will: no future tense after "if", "when" etc.

      way, the entire mobile network and its access network form a
      logical multilink subnet, thus eliminating any nesting.

      This approach has the advantage of keeping the implementations of
      Correspondent Nodes unchanged.  However, it requires the root
      Mobile Router to act as a Neighbor Discovery proxy for all the
      Mobile Network Nodes that are directly or indirectly attached to
      it.  This increases the processing load of the root Mobile Router.
      In addition, a change in the point of attachment of the root
      Mobile Router will require every nested Mobile Router (and
      possibly Visiting Mobile Nodes) to change their care-of addresses.
      Not only will this cause a burst of Binding Updates where every
      Mobile Router and every Visiting Mobile Node start sending Binding
      Updates to their Correspondent Entities, it will also cause a
      burst of Duplicate Address Discovery messages to be exchanged
      between the mobile network and the access network.  Furthermore,
      route optimization for Local Fixed Nodes is not possible without
      new functionalities implemented on the Local Fixed Nodes.

At LFNs, these are functionalities not related to mobility support.
I think we need to draw a line between mobility-related functionalities
and other. The other ones could be referred to as "requirements" to
distinguish between the two.

   o  Hierarchical Registrations

      Hierarchical Registration involves Mobile Network Nodes (including
      nested Mobile Routers) to register itself with either their parent

s / itself / themselves

      Mobile Routers, or the root Mobile Router itself.  After
      registrations, Mobile Network Nodes would tunnel packets directly
      to the upstream Mobile Router they register with.  At the root
      Mobile Router, packets tunneled from sub-Mobile Routers or Mobile
      Network Nodes are tunneled directly to the Correspondent Entities,
      thus avoiding nested tunneling.

5.6.  How is Signaling Performed?

   An entirely different method of signaling makes use of upper layer
   protocol to establish the bindings between the address of a Mobile

s / protocol / protocols 

   Network Node and the location of the mobile network.  Such binding
   information can then be passed down to the IP layer to insert the
   appropriate entry in the Binding Cache or routing table.  An example
   of such mechanism is [27] which uses the Session Initiation Protocol
   (SIP) to relay binding information.

5.7.  How is Data Transmitted?

   With Route Optimization established, one remaining question to be
   answered is how data packets can be routed to follow the optimized
   route.  There are the following possible approaches:

   o  Encapsulations

      For instance, if the Correspondent Entity knows the full sequence
      of points of attachment, it might be necessary for there to be
      multiple encapsulations in order to forward the data packet
      through each point of attachment.  This may lead to the need for
      multiple tunnels and extra packet header overhead.  It is possible
      to alleviate this by using Robust Header Compression techniques
      [29][30] to compress the multiple tunnel packet headers.

I think draft-minaburo-rohc-nemo-01.txt should be cited here - it's not
about RO but it is focused on NEMO BS.

8.  Security Considerations

   This is an informational document that analyze the solution space of

s / analyzes

10.  References

I've noticed that in many cases only the 1st author is mentioned.  Also,
when there is a published paper, wouldn't it be better in the
"informative section" to provide the reference of a published paper
rather than I-D which are bound to be deleted from the IETF reposirory
(if not already) ?  I think published papers exist for many of the
references.

Thierry.

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 24 Nov 2005 21:21:20 +0800

Hello Thierry,

thanks for the comments.  See responses in-line.

> The defintion of RO above will appear in the terminology document.

Ok, we will synchronize with the terminology draft, and see if it is
necessary to modify the text here.

> s / with general terminologies / with the terminology

OK.

> The sentence above should better be moved to the section terminology

Well, *IF* there is going to be one.  It has always been our intention
(or at least mine) that the terminology sub-section is a temporary one.
Once the terminologies we used are in the terminology draft, I see no
benefit in retaining this section.

> bi-directional tunnel to be established between any pair of (MR, its

Good point.  The usefulness of the "Assumption" section would depends on
whether we do have any general assumptions made.  

> purposes of clarity / reminder.

Possibly, if we (ie WG) what to do that.

>       This refers to the entity which is capable of terminating a Route

If this text remains, I would simply copy it from the terminology draft.
If you use 'router', we would use 'router' :)

> things later in the document.

Hmm, possibly.  Good point.  Will consider that.

> As the text is written, shouldn't this rather be entitled "Design Goals

Possibly.  I have no strong position here.

> s / Greater Data Efficiency / Reduced Packet Overhead ????

Possibly.  But that may arguably not cove rthe later sentence on e2e
efficiency.

> s / in Home / in the Home

I think its should instead be a swap of the position of "the", ie
"Avoiding Bottleneck in the Home Network".

> s / alows / would allow  [in paragraphs "may", "should" etc are

ok.

> Don't you rather mean "Ingress Filtering" ?

Nope.  Firstly, it could simply be a policy thing without any mechanism
to enforce the policy except the integrity of the owner of the MR.  Thus
it is not an ingress filtering problem.

Secondly, even if firewall at home network does agressively filtering,
it is not ingress filtering as I understand the term.  Ingress
filtering, as a term, has been used a long time in the IETF.  A very
narrow sense of interpretation, which most possibly is the prevalent
one,  is it refers to the filtering of packet if the source address does
not fit certain criteria.

However, packets from visitors would appear at the home network with
source address configured from the MNP.  The firewall should not discard
the packet based on ingress filtering.  Instead, it is because of
something else that the packet got discarded (eg the existence of a Home
Address Option that contains address not from the MNP, etc).

> s / of Mobile / of the Mobile 

Ok.  We may need to remove an 's' from the first 'Mobile Routers' too.

> I'm not sure the paragraph above is clear enough.

[1] is listed as "Normative".  After reading [1] and if you still feel
its not clear enough, I am open to suggestions on how to improve it :)

> I would find another word instead of "Basic". What about "not nested" ?

"Non-Nested" you mean?  Can, I have no strong position on this.

> and thus be a mobile router, etc ? 
Possibly, I will look into this.

> s / traffic both / traffic in both 

OK.
> can carry traffic both directions identical = ?? Please rephrase.

Opps, obviously some text get missed out by mistake.  Will look into
that.
> Here again, it's not very logical. Above, the term "CR" is used, so why

Because it may not be a CR, but a modified CN.
> NEMO = NEMO Basic Support ?

I don't so.  I think the text's intent was to refer to NEMO RO (and
possibly Basic as well).

> >From which AR ? AR from the parent-NEMO or root-NEMO ?

No restriction, both ways could be done.

> s / which have / which has

ok.

> Wouldn't it be better to phrase this as "requirements" rather than

Nope, this is not a requirements draft, I would avoid the term
"Requirement" as much as I can.  I could call it "Tradeoffs" but not all
items are tradeoff per se.  I could call it "General Consideration for
NEMO Roue Optimization", but that is as bad as "Issues".

> "mobilty support transparency" requirement. (you may group some text

I believe a simply reference to the later sub-section would suffice.

> Is this an issue ? Isn't there a better place ?

Of-course it is.  It is one of the main point of arguments: whether CN
is touched or not, whether LFN are touched or not.

> Is this an issue ? Isn't there a better place ?

Like?

> MNNs. You shouldn't group these issues/requirements togethers.

The previous sentence read "necessary to reveal ... such as the MNNs or
their CNs".  For MNNs, its mobility transparency.  For CNs, its location
privacy.  We could of-course break it into two parts, but they stamped
from the same thing: requiring the MR reveal its location to some other
nodes.

>    Optimization shcemes, however, require that all Mobile Routers to

Opps, how could aspell not catch that!!!!

> I cannot find a link between the sentence "For instance ..." and the

Hmm..., perhaps "s/For instance/Thus" would be better?

>    4.  How is address of Mobile Network Node represented?

OK.
>    5.  How is address of Mobile Network Node bound to location of mobile

OK
>    6.  How is signaling done?
OK

> section. Here there might be a need for the MNN to know its "depth" in

Possibly.  That is the thin line we are trying to thread here.  On one
hand, we want to give details to provide a complete analysis.  On the
other hand, we don't want to go into too much specifics, else it we
would be making too much assumptions about the approach.

In this case, however, I agree we could go into slight more detail such
as what new functionalities are required and all that.

>    Alternatively, Mobile Router can establish Route Optimization with a

OK.

>    Mobile Router is merely one hop away from the Mobile Network Node,

True, let see how we can rephrase it.  How about:

        Since all packets from/to the MNN must transit the MR, ...

> s / with the same Mobile Router

OK.

> (potentialy nearby) CNs., so this observation is more realistic in the

Possibly.  However, there are examples for a single CN.  (imagine all
MNNs in a corporate mobile network accessing the corporate mail server).

> Just wondering: shouldn't the tradeoffs be discussed in section 4, in an

Possibly, but we feel that it is too in depth more suitable for an
analysis section.

> s / signalling / signaling

OK. (Just Rambling: Why can't we just have one ENGLISH :<).

> 5.4.  How is Address of Mobile Network Node Represented?

OK.
>    address of Mobile Network Node and the location of the mobile network

OK.
>    o  explicitly specifying the address of Mobile Network Node.

OK.
>    Mobile Network Prefix will be compromised.

That is subjective I think.  But no harm changing :)

> Don't we need to discuss "binding a prefix" ?  Also, shouldn't we

Obviously you missed the debate between Alex and myself :)

Binding address and binding prefix is the same thing, just that you bind
more than one address at the same time with a prefix.  That's why there
is no "binding a prefix".  5.5.1 do go into detail of binding a prefix,
though.

As for locator, is that a useful term without the accompanying term --
identity?  I mean, without mentioning identifier, what is difference
between a locator and an address?

>    These will be described in the following sub-sections.

For a reader reading sequentially, "will be" is correct :)

But I agree on changing to "are",.  "Will be" is more suited for
something that is more distant.

>       mobile network prefix will be routed through the bi-directional

OK.
>       Local Fixed Node.  An example of such an approach would be [19].

Yep, CE is more correct.

>    One question that immediately comes to the mind is how the Mobile

ok.

> please choose either "singular form" or "plural form".

ok.

> s / Mobile Router / the root Mobile Router ?

I think we will stick to singular ...

> when ... will: no future tense after "if", "when" etc.

That is new.  You sure?
I think is more of whether you want to emphasize something.

> distinguish between the two.

What are functionalities required for mobility support then?

>       nested Mobile Routers) to register itself with either their parent

OK.

>    protocol to establish the bindings between the address of a Mobile

OK.
> about RO but it is focused on NEMO BS.

OK.

>    This is an informational document that analyze the solution space of
OK.

> 10.  References
> 
> I've noticed that in many cases only the 1st author is mentioned.

That you have to complain to the maintainer of xml2rfc.

>   Also,

Possibly ... but the fact is I am lazy.  It is easy to do a "touch
reference.xxx.xml; wget ...", especially when its is scripted, compared
to creating an xml reference for that paper from scratch :).

Will do what I can.

Thank you once again for your detailed comments.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: Fri, 25 Nov 2005 17:32:57 +0800

Pardon me for replying to my own post, but I have additional responses
while compiling the issues list for this mail.  I 'll snip out the less
important ones.

> >       Local Fixed Node.  An example of such an approach would be [19].

Sorry, on second thought, CN is correct.  The LFN will be communicating
with a CN, so MR is sending MIPv6 RO to a CN.  There is no CR for MIPv6
RO, so it is not necessary to use the CE generalization.

> to creating an xml reference for that paper from scratch :).

While I will try to add in the paper references I know of, I am just
wondering what is the normal IET/RFC-Editor position on referencing
expired drafts.  There are bound to be previous cases where an RFC have
to reference an expiring or expired I-D.

/rgds
/cwng

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 25 Nov 2005 19:00:58 +0900

> 
> > 
> >    related to mobility in [3] and [4], and NEMO related terms
> >    defined in[5].  
> > 
> (or at least mine) that the terminology sub-section is a temporary
> one. Once the terminologies we used are in the terminology draft, I
> see no benefit in retaining this section.

Unfortunately, you didn't comment this on my most important comment
which was:

1.1.  Terminology

Conclusion: don't dismiss the section; as discussed for other documents,
the doc should be self-contained. I don't mean to copy all terms, but to
keep in the present the new terms, while the original defintion would be
in draft-ietf-nemo-terminology.

> If this text remains, I would simply copy it from the terminology
> draft. If you use 'router', we would use 'router' :)

This doesn't help me with the document I have myself to take care about.
The term come from this draft authors, so please tell me what is the
conclusion, and not the other way round ;-)

> "Non-Nested" you mean?  Can, I have no strong position on this.

Yes, I meant "non-nested".

> >    A straight-forward approach to Route Optimization in NEMO is for
> >    the Mobile Router to attempt Route Optimization with a
> >    Correspondent Entity.  This can be viewed as a logical extension
> >    to NEMO Basic
> > 
> > Here again, it's not very logical. Above, the term "CR" is used, so
> > why would one use "CE" now ? 
> 

The point is that you may use CE more constantly (unless you really need
to make a distinction between the 2)

> >    because Mobile IPv6 defines its own Route Optimization mechanism
> >    in its base protocol suite as a standard, collaboration with this
> >    and NEMO brings various complexity.
> > 

So, you may write "NEMO RO" not just "NEMO".

> >    Another NEMO specific delay during handoff is that in a nested
> >    mobile network, a child Mobile Network Node may need to detect or
> >    be notified of the handoff of its parent Mobile Router so that it
> >    can begin signaling its own Correspondent Entities.  Apart from
> >    the compromise of mobility awareness and location privacy, this
> >    mechanism also increases the delay during handoffs.
> > 

Actually, this is linked with my comment on section 4.7. I think
"mobility support transparency" deserves an independant paragraph.

> is touched or not, whether LFN are touched or not.

4.5 says "Detection of New Functionalities" so here you may write "4.4
Extending Nodes with New Functionalities".

> > Is this an issue ? Isn't there a better place ?

For me it looks more like a requirement than an issue.

> >    One advantage of NEMO Basic Support is that the Correspondent
> >    Nodes and Mobile Network Nodes need not be aware of the actual
> >    location and mobility of the mobile network.  With Route
> >    Optimization, it might be necessary to reveal the point of
> >    attachment of the Mobile Router to other nodes, such as the
> >    Mobile Network Nodes or their Correspondent Nodes.  This may mean
> >    a tradeoff between location privacy [17] (and mobility
> >    transparency) and Route Optimization.
> > 
> > Agree with location privacy, but mobility may still be transparent
> > to MNNs. You shouldn't group these issues/requirements togethers.
> > 
> 
> The previous sentence read "necessary to reveal ... such as the MNNs
> or their CNs".  For MNNs, its mobility transparency.  For CNs, its
> location privacy.  We could of-course break it into two parts, but
> they stamped from the same thing: requiring the MR reveal its location
> to some other nodes.

I don't buy that "location privacy" is defined the way you seem to
define it. Location Privacy is about not providing my location to my
peers, not about not knowing where I am ! 

I advocate an independent paragraph on "mobility transparency" with text
taken from 4.7 and 4.3.

> 
> > I think that in most cases the sessions would be split between
> > several(potentialy nearby) CNs., so this observation is more
> > realistic in the CR case.
> > 
> 

I agree with you (of course). You may just point to the fact it's just
an example.

> >    Using the Mobile Network Prefix would usually mean that the
> >    initiator is the Mobile Router, and has the benefit of binding
> >    numerous Mobile Network Nodes with one signaling.  However, it
> >    also means that if location privacy is compromised, the location
> >    privacy of an entire Mobile Network Prefix will be compromised.
> > 
> > s / will / would
> > 
> 

Native English speakers will correct me if I'm wrong but I've learnt
that the future tense cannot be used after words like "if, when, after,
.." etc.

> >    In order for route to be optimized, it is generally necessary for
> >    the Correspondent Entity to create a binding between the address
> >    and the location of the Mobile Network Node.  This can be done in
> >    the following ways:
> > 
> > 

Didn't see a discussion on this ;-)
 
> Binding address and binding prefix is the same thing, just that you
> bind more than one address at the same time with a prefix.  That's why
> there is no "binding a prefix".  

Sure, but if you write "address" you kind of limit the scope of what
you are writing, no ? 

> 5.5.1 do go into detail of binding a prefix, though.

Yes, I've seen this, but the itemized text doesn't give a hint to this.

> something that is more distant.

I might be wrong and this is something only a native English speaker
could correct, but I think than in the situation where the text "one is
going to read" is just right after, the present tense is more
appropriate.

> I think is more of whether you want to emphasize something.

Let me know the final answer so that I can embrace or complain to my
past English teachers ;-)

> >       This approach has the advantage of keeping the implementations
> >       of Correspondent Nodes unchanged.  However, it requires the
> >       root Mobile Router to act as a Neighbor Discovery proxy for
> >       all the Mobile Network Nodes that are directly or indirectly
> >       attached to it.  This increases the processing load of the
> >       root Mobile Router. In addition, a change in the point of
> >       attachment of the root Mobile Router will require every nested
> >       Mobile Router (and possibly Visiting Mobile Nodes) to change
> >       their care-of addresses. Not only will this cause a burst of
> >       Binding Updates where every Mobile Router and every Visiting
> >       Mobile Node start sending Binding Updates to their
> >       Correspondent Entities, it will also cause a burst of
> >       Duplicate Address Discovery messages to be exchanged between
> >       the mobile network and the access network.  Furthermore, route
> >       optimization for Local Fixed Nodes is not possible without new
> >       functionalities implemented on the Local Fixed Nodes.
> > 
> > I think we need to draw a line between mobility-related
> > functionalities and other. The other ones could be referred to as
> > "requirements" to distinguish between the two.
> > 
> 

A mechanism to send a BU is a mobility support functionality.  A DHCP
functionality is not a mobility support functionality. DHCP is useful
for any node, fixed or mobile, in a fixed network or a mobile network
which needs a dynamic address.

> That you have to complain to the maintainer of xml2rfc.

Well, in the 1st place, did you include all the authors in the .xml file
?

> > rather than I-D which are bound to be deleted from the IETF
> > reposirory(if not already) ?  I think published papers exist for
> > many of the references.
> > 
> 
> reference.xxx.xml; wget ...", especially when its is scripted,
> compared to creating an xml reference for that paper from scratch :).
> 
> Will do what I can.

I recommend this - when you have one valid one, of course.

It would be nice from solution draft authors cited in ROSA to provide a
better published reference rather than for ROSA authors to seek for this
by themselves.

Thierry

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 25 Nov 2005 19:05:33 +0900

> > > "informative section" to provide the reference of a published
> > > paper rather than I-D which are bound to be deleted from the IETF
> expired drafts.  There are bound to be previous cases where an RFC
> have to reference an expiring or expired I-D.

For the RFC editor it doesn't matter when refs are "informational" but
for the reader it does matter when one cannot find a referred document
which is needed to understand what ROSA is talking about. 

I know that many authors have written papers, so they could do their
part of the work by providing their references.

Thierry.

---

From: Chan-Wah Ng <[email-masked]>
Date: Fri, 25 Nov 2005 19:10:36 +0800

> Unfortunately, you didn't comment this on my most important comment

I thought I commented (i.e. the text you quoted above) :)
> in draft-ietf-nemo-terminology.

I see.  I recall there is a discussion few years back on whether the
terms should be kept all in one place or something like that.  If the
decision was to have draft-ietf-nemo-terminology contains all terms, and
each individual contain a sub-set of these terms that are relevant to
their subject matters, than I'll be happy to oblige.

> conclusion, and not the other way round ;-)

Ah, opps.  Stalemate :)

Ok, I will fix it to "router".

> to make a distinction between the 2)

This I humbly disagree, though I am not too strongly positioned about
it.  My view is that as much as possible we should be specific.  Use
CN/CR instead of CE, unless there it is clearly that either will do.

However, your point is taken (since it will leads to less error).

> So, you may write "NEMO RO" not just "NEMO".

I need the co-author who wrote this text to confirm, but if the
intention was indeed to imply NEMO-RO and NEMO Basic, then I will keep
NEMO.  If it was only one of them, of-course we would switch to that.

> "mobility support transparency" deserves an independant paragraph.

See below.

OK.

> For me it looks more like a requirement than an issue.

I am unwillingly to write a "Requirements" section, for fear of being
accused trying to sneak in requirements for RO in a problem statement
draft.  I would have it remained in the "Issues" section.  If you feel
that "Issue" has a more specific meaning, then I would change the title
of this section to "General Considerations".

> peers, not about not knowing where I am !

I don't see the difference between your interpretation and mine.

"Location Privacy is about not providing my location to my peers" is
equivalent to how I see it: "For CNs, its location privacy".

"about not knowing where I am" is equivalent to how I see it "For MNN,
its mobility transparency".

> I advocate an independent paragraph on "mobility transparency" with text
I could attempt a split and get back to you.  My feeling is that the
text will be largely similar (which is why I made the editorial decision
not to split).  Please note that we are NOT trying to say location
privacy = mobility transparency.  They are clearly distinct
considerations. It is just that I feel that the text describing the two
has so much overlapping that I grouped them into one sub-section. In the
text, we have clearly use the terms location privacy and mobility
transparent distinctly so that it shouldn't create the impression that
they are the same thing (which apparently, we failed, judging on your
comments).

OK.

> that the future tense cannot be used after words like "if, when, after,

I am not a native english speaker, but I think I have heard expressions
such as "if you XXX, I will kill you!" numerous times :). 
I think your rule refers to the "XXX" part (e.g. there is no "If you
will do ..."), not the "then" part.

> Didn't see a discussion on this ;-)

Its ISSUE #12.

> Sure, but if you write "address" you kind of limit the scope of what

Which is why there is a sub-section "5.4" that explains the case when a
MNN's address can be derived from a prefix.

> Yes, I've seen this, but the itemized text doesn't give a hint to this.

Do you think it better to add a bullet on "binding a prefix", making it
four bullets where there is only three sub-sub-sections?
 
> going to read" is just right after, the present tense is more
You are not wrong.  This is precisely what I mean by "more distant" :).

I am guilty of writing the text as if I am speaking to an audience.  It
is not uncommon in speech for you to say "I will next describe foo and
bar".

> which needs a dynamic address.

Agree, but the text is about mechanism to send BU for LFN.  Sure , for
ND-proxy, you can always used DHCP or similar to have the LFN change
their addreses.  That is not mobility.  However, this defeats the
purpose of NEMO.  The ideal of NEMO is so that MNNs can retain their
original source address.  So, the LFN we have would need some mobility
management functionality in order to enjoy the benefits of RO, which is
precise what we meant by "Furthermore, route optimization for Local
Fixed Nodes is not possible without new functionalities implemented on
the Local Fixed Nodes".

> Well, in the 1st place, did you include all the authors in the .xml file

I most certainly did not, since I downloaded the xml files from
xml.resource.org.  Sorry, I meant "you have to complain to the
maintainer of xml.resource.org" instead of "xml2rfc" in my original
response.

But I concede that it is my job to ensure that the resources I am using
are functioning within normal parameters.  Will try to do what I can.

> better published reference rather than for ROSA authors to seek for this
Yes, authors please do so.

/rgds
/cwng

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 25 Nov 2005 14:17:48 +0100

[...]
> [1] is listed as "Normative".  After reading [1] and if you still 
> feel its not clear enough, I am open to suggestions on how to improve
>  it :)

About the "stalemate" problem.  [1] is the ro problem statement draft,
which in turn cites the home network models draft which cites back
 the ro problem statement draft.

For example, the home network models draft says:
> But note that SFO should never attach to one of its own Cabs.  This 
> would create a stalemate situation, as documented in the NEMO RO 
> problem statement [11].

... which leaves one wonder what exactly is the "stalemate" situation.
So one goes to the ro ps draft and reads:
> Several configurations for the Home Network are described in [9]
> [home net models].  In particular, there is a mobile home scenario
> where a (parent) Mobile Router is also a Home Agent for its mobile
> network.  In other words, the mobile network is itself an aggregation
> of Mobile Network Prefixes assigned to (children) Mobile Routers.
> 
> A stalemate situation exists in the case where the parent Mobile 
> Router visits one of its children.  The child Mobile Router cannot 
> find its Home Agent in the Internet and thus cannot establish its 
> MRHA tunnel and forward the visitors traffic.  The traffic from the 
> parent is thus blocked from reaching the Internet and it will never 
> bind to its own (grand parent) Home Agent.

This last paragraph in the ro ps draft is the essence of the "stalemate"
problem.  If that paragraph is not enough for clear explanation, here's
more detailed text about how the "stalemate" situation may occur
(substitute "stalemate" for "cross-over tunnels":

   Two MR-HA tunnels are "crossing over" each other when the path
   between one tunnel's endpoints includes only one of the other
   tunnel's endpoints.

   Support of nested mobile networks is possible only when the path
   from MR2 to MR1's HA does not go through MR1 (path considered when
   both mobile routers are at home and no tunnels are in place).

  Consider a mobility configuration depicted below.  MR1 is served by
  HA1/BR and MR2 is served by HA2.  Both MR1 and MR2 are at home in
  the initial step.  HA2 is placed inside the first mobile network,
  thus representing a "mobile" Home Agent.

                                                  /-----CN
                                       ----------/
     home link1            -------    |          |
   -----------------------| HA1/BR|---| Internet |
       |                   -------    |          |
       |                               ----------
     -----    -----
    | MR1 |  | HA2 |
     -----    -----
       |        |
      -------------mobile network 1 / home link2
       |
     -----    -----
    | MR2 |  | LFN |
     -----    -----
        |        |
       ------------mobile network 2

  In the picture above, communication between CN and LFN follows a
  direct path as lons as both MR1 and MR2 are positioned at home.  No
  encapsulation intervenes.

  In the next step, consider that the MR2's mobile network leaves home
  and visits a foreign network, under Access Router (AR) like in the
  figure below:

                                            /-----CN
                                 ----------/
     home link 1     -------    |          |
     ---------------| HA1/BR|---| Internet |
       |             -------    |          |
     -----    -----              ----------\
    | MR1 |  | HA2 |                        \
     -----    -----                          -----
       |        |                           | AR  |
      ------------mobile net 1               -----
                  home link2                   |
                                             -----    -----
                                            | MR2 |  | LFN |
                                             -----    -----
                                               |        |
                                  mobile net 2------------

  Once MR2 acquires a CoA under AR, the tunnel setup procedure occurs
  between MR2 and HA2.  MR2 sends BU to HA2 and HA2 replies BAck to
  MR2.  The bi-directional tunnel has MR2 and HA2 as tunnel endpoints.
  After the tunnel MR2HA2 has been set up, the path taken by a packet
  from CN towards LFN can be summarized as:
  CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN.  Non-encapsulated packets
  are marked "->" while encapsulated packets are marked "=>".

  Consider next the attachment of the first mobile network under the
  second mobile network, like in the figure below:

                                   /-----CN
                        ----------/
            -------    |          |
           | HA1/BR|---| Internet |
            -------    |          |
                        ----------\
                                   \
                                    -----
                                   | AR  |
                                    -----
                                      |
                                    -----    -----
                                   | MR2 |  | LFN |
                                    -----    -----
                                      |        |
                         mobile net 2------------
                                      |
                                    -----    -----
                                   | MR1 |  | HA2 |
                                    -----    -----
                                      |        |
                         mobile net 1------------

  After this movement, MR1 acquires a CoA valid in the second mobile
  network.  Subsequently, it sends a BU message addressed to HA1.
  This BU is encapsulated by MR2 and sent towards HA2, which is
  expected to be placed in mobile net 1 and expected to be at home.
  Once HA1/BR receives this encapsulated BU, it tries to deliver to
  MR1.  Since MR1 is not at home, and a tunnel has not yet been set up
  between MR1 and HA1, HA1 is not able to route this packet and drops
  it.  Thus, the tunnel establishment procedure between MR1 and HA1 is
  not possible, due to the fact that the tunnel between MR2 and HA2
  has been previously torn down (when the mobile net 1 has moved from
  home).  The communication between CN and LFN stops, even though both
  mobile networks are connected to the Internet.

  If both tunnels between MR1 and HA1, and between MR2 and HA2
  were up simultaneously, they would have "crossed over" each other.
  If the tunnels MR1-HA1 and MR2-HA2 were drawn in the above picture,
  it could be noticed that the path of the tunnel MR1-HA1 includes
  only one endpoint of the tunnel MR2-HA2 (the MR2 endpoint).  Two
  MR-HA tunnels are crossing over each other if the IP path between
  two endpoints of one tunnel includes one and only one endpoint of
  the other tunnel (assuming that both tunnels are up).  When both
  endpoints of one tunnel are included in the path of the other
  tunnel, then tunnels are simply encapsulating each other.

Alex

---

From: Chan-Wah Ng <[email-masked]>
Date: Mon, 28 Nov 2005 15:31:36 +0800

Hello, Alex,

Thank you for the text.  I am now considering which is the most
appropriate place to hold the text.  Currently, I am inclined to add it
as an appendix to RO-PS draft.  

It could, also be added to the home network model draft as an appendix
as well.

Pascal, what do you think?

/rgds
/cwng