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

[Alexandru Petrescu <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext
>