[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MEXT] AD review of draft-ietf-mext-aero-reqs

Just one particular point about looping issues...

Jari Arkko a écrit :
[...]

draft says:

4.2. Des2 - Nesting


   It is desirable if the RO mechanism supports RO for nested MRs, since
   it is possible that for PIES and astronaut spacesuits, that PANs with
   MRs will need to be supported.  For oceanic flight, ATS and AOS may
   also benefit from the capability of nesting MRs between multiple
   planes to provide a "reachback" to terrestrial groundstations rather
   than relying solely on lower rate HF or satellite systems.  In either
   case, this mode of operation is beyond current strict requirements
   and is merely desirable.  It is also noted that there are other ways
   to support these communications scenarios using routing protocols or
   other means outside of NEMO.


Jari says:
Is loop detection a requirement? That is something that we do not currently support in NEMO...
I am not sure what do you mean Jari, by saying that loop detection is not supported in NEMO(?)
With Mobile IP based network mobility packets can not travel in loop paths (a typical risk of badly behaving distributed algorithm of path construction), simply because packets get encapsulated each time, every same-level path can't loop.
On another hand, I am not aware of any analysis of Mobile IP based network mobility protocols from a looping standpoint.
I wanted to point to a 'stalemate' situation described in RFC4888 Appendix B which shows a mobility configuration leading to impossibility to set up the MR-HA tunnel. This configuration can occur with a small capsule detaching from a larger station, attaching to another larger station; subsequently the initial station tries to attach to the capsule. This may lead to a 'stalemate' situation from the Mobile IP and RFC4888 standpoint. A NEMO RO protocol should help avoid this situation.
I am wondering about similar description of what looping and NEMO can be in the framework of aero-reqs draft. 

Alex




Editorial comments:


This document describes the requirements and desired properties of
NEMO Route Optimization techniques for use in global networked
communications systems for aeronautics and space exploration.


Expand NEMO in the title and abstract.



As background the NEMO terminology and NEMO goals and requirements
documents are suggested reading [4] [5].  The drafts produced as part
of the Mobile Platform Internet (MPI) effort are also of relevence,
and some of the material in this document is borrowed from the MPI
drafts [6] [7].
This part jumps out a little bit as the first paragraph, particularly when [6] and [7] are expired I-Ds. I would suggest the borrowing part should move to the acknowledgment section, and NEMO goals and requirements could be placed a little bit later in the Section, e.g., after the current second paragraph. 


   The base NEMO standard [1] allows Mobile IPv6 [2] to be used by
   mobile routers, although NEMO does not support Mobile IPv6's Route
   Optimization (RO) features for mobile network nodes other than the
   NEMO Mobile Router (MR) itself.
Again, the part that begins with "although" is a little bit early as you have not explained even the basic NEMO yet. Explain the basic NEMO first, and then put the lack of RO support to the end of the paragraph. 


   imposed by using the MRHA tunnel.  Avoiding the delay from


Expand the acronym MRHA before first use.


using Plain
      Old Aircraft Communication Addressing and Reporting System (ACARS)
Unless "Plain Old" is the formal name, I would use "using the old Aircraft ..." instead.
It would be good to get references to a few of the concepts and technologies. E.g., Section 2 talks about ACARDS, VDL modes, Electronic Flight Bags, B-AMC, AMACS, P34, LDL, WCDMA, 802.16, etc. Some of these acronyms were not defined either. 


Both current and planned datalinks used
   for PIES and/or AOS


Undefined acronyms.
satcom links employed by Connexion by Boeing support much higher data rates than current ATS links.
Isn't this history now? I would suggest rephrasing this without any mention of specific products. E.g, satcom links employed by passenger Internet access systems support much higher... 


it may tolerable be if some
   special configuration is required for NEMO RO

... may be tolerable ...



new ATN architecture



Expand the acronym and provide a reference if one exists.


As a minimum, if an RO solution is
   integrable with the MONAMI6 basic extensions
It would be better to find a non-WG name for these extensions. Please refer to draft-ietf-mext-multiplecoa specification, for instance. 


 (Note: this is particularly subject to MEXT discussion)
This should be removed or reformulated, as this draft becomes published as an RFC the context may no longer be there for the readers. 

Jari

_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext