Subject: Re: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 7 Mar 2008 15:30:57 -0800

See below for my comments:

Fred
[email-masked]

1) The document does a good job of separating the ATS/AOS
and PIES domains, but it should stress more clearly that
the candidate mobility solutions for ATS/AOS may have no
commonalities at all with candidate PIES solutions. The
domains and their requirements are simply too diverse to
the point that they almost warrant consideration under
separate documents.

2) The document touches on available and near-term link
technologies, but does not seem to take a position on
which technologies are appropriate for each of the
domains and why. For example, what is the use case
motivation for selecting between VHF, satellite, HF,
etc. within the ATS domain? Would like to see more
about availability of link technologies and their
applicability for the various domains.

3) Section 1, the paragraph beginning "Increased chances
of packet fragmentation", it would be helpful to know
more about what is intended here. Is it that unoptimized
paths might require fragmentation due to excessive
tunnels-within-tunnels? Or, that unoptimized paths might
reuqire traversal of multiple physical links with
constrained MTUs?

AFAICT, the limiting physical link MTU is likely to be
that of the aircraft access link itself and unoptimized
routes would not be likely to cross even more-constrained
physical links. So, is this meaning to say fragmentation
due to excessive tunneling?

4) Section 2.1.1, final paragraph, "The set of CNs may
be assumed to all share the same network prefix." I
don't understand the *assumed* part, as it pre-supposes
the internal network organization in future control
facility networks.

5) Section 2.2, 5th paragaph, the sentence beginning
"In this case removing..." is 8 lines long on my printed
page. Can it be broken into multiple simpler sentences
that are easier to read?

6) Section 3.1.1, it is difficult to understand to which
of the three air domains this refers. If ATS, earlier
sections motivated the anticipated case of a small set
of CNs that are co-located.

Gnereally speaking, is this section meaning to say that
multi-addressing is a requirement, e.g., with QoS tied
to a network prefix? Because there may be other acceptable
approaches to meet the stated ICAO TC-1 other than
multi-addressing.

7) Section 3.5.1, loss, delay and duplication (also
reordering) are all possible in a best-effort systems.
Recommend changing the "MUST NOTs" to "SHOULD NOTs",
also in keeping with the statament: "It is understood
that this may be a requirement that is not easily
implementable...".

8) Section 3.6, routing scaling requirements need to be
analysed with respect to the next-generation routing
proposals emerging from the routing research group. It
may not be possible, for example, to expect always-available
routes to the targets of RO signalling such that delays
and/or packet loss may occr.

This aspect in particular clearly suggests a need to deal
with the ATS/AOS and PIES domains as completely separate
problem spaces. Moreover, this whole subject begs the
question as to whether the mobility framework should
determine the routing framework, whether the routing
should guide mobility, or whether both must be designed
in a coordinated fashion. IMHO, this overlap needs to be
examined before a RO requirement can be articulated.

9) Section 3.7.1, nit, "VDL links the bandwidth is 8kbps",
does this mean to say "VDL-2" (old VDL/ACARS is 2kbps).

10) Section 3.8, "The RO scheme MUST permit the receiver
of a BU to validate the CoAs claimed by an MR." This
requirement seems to be leaning toward a particular
solution alternative, i.e., CGAs. Such a use case would
seem to be seperable from SEND.

Here again, this requirement needs to be examined on a
per-domain basis. For example, in the ATS domain it may
be easy for a CN to authenticate a MN w/o requiring
validation of the CoA itself. At a minimum, additional
discussion wrt requirements specific to the individual
domains would be appropriate.

11) Section 3.9.1, please drop the phrase "due to the
US Department of Defense HAIPE work" as this may not
be representative of all IPsec implementations.

(end of commemts)       

>-----Original Message-----
>From: Julien Laganier [mailto:[email-masked]] 
>Sent: Monday, February 25, 2008 4:41 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01
>
>Folks,
>
>Hereby we're issuing a WGLC for draft-ietf-mext-aero-reqs-01
>
>This is a 2 weeks WGLC that will last until Monday, March 10th. We 
>kindly ask the WG to review the last changes that were made 
>and provide 
>comments if needed.
>
>If you have no comments and think the document is ready to be 
>submitted 
>to IESG, please do send a note stating that to the WG ML.
>
>Additional information about the document is below:
>
>        Title           : NEMO Route Optimization Requirements for
>                          Operational Use in Aeronautics and Space
>                          Exploration Mobile Networks
>        Author(s)       : W. Eddy, et al.
>        Filename        : draft-ietf-mext-aero-reqs-01.txt
>        Pages           : 27
>        Date            : 2008-02-24
>
>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.
>This version has been reviewed by members of the International Civil
>Aviation Orgnanization (ICAO) and other aeronautical communications
>standards bodies, and contributed to by a number of aeronautical
>communications experts outside the normal IETF process.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-mext-aero-reqs-01.txt
>
>Thank you for your support.
>
>--julien and marcelo, MEXT chairs
>_______________________________________________
>MEXT mailing list
>[email-masked]
>http://www.ietf.org/mailman/listinfo/mext
>
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 10 Mar 2008 08:47:57 -0700

> kindly ask the WG to review the last changes that were made 

Here are some more comments on the above draft:

Major comment:    I read this draft from the perspective of "If I were
to try to design a solution to these requirements, do I have enough
requirements information to proceed?"  However, I did not find many
statements on the assumptions on the CNs in the various domains.  Are
they IPv4, IPv6, unmodifiable, modifiable, behind a proxy, etc.?  It
would be hard to design a solution without such information.  

Jari seems to have raised a similar comment in his review posted on
2/7/2008.

Other comments:
- it would be nice if the draft stated some assumptions on how the
aeronautical networks use name services (DNS) and whether it has any
bearing on the solution

- it would be nice if the draft stated some further assumptions on the
MNN:  whether they are expected to be mixed IPv4 and IPv6 or solely IPv6

- it would be nice to quantify the expected number of hosts, flows,
routers, etc. in the system, or perhaps for the domains for which this
information can be estimated.  

- The way Req5 (Packet Loss) is stated seems to be unattainable.  I
think it is impossible for any multihoming scheme to guarantee this.
Suggest weakening the wording to "must not cause more than transient
loss or duplication of data..."

Tom

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Mon, 10 Mar 2008 23:25:37 -0500

>From: Henderson, Thomas R [mailto:[email-masked]]
>Sent: Mon 3/10/2008 10:47 AM
>

For PIES, the CNs are IPv4 mostly, though IPv6 CNs should also be supported.
They are unmodifiable since they are typical Internet hosts, that can't be
expected to make special upgrades in order to work with people on planes.
For ATS/AOS, there is more capability to require CN modifications, however
the less impact the better.  For ATS, at least, we can assume the CNs are
all IPv6.  Some of these points may be discussed in the section of desirable
requirements, though since you mention it, we will certainly go back and
either make them more clear or mention them earlier in the requirements
section.

>aeronautical networks use name services (DNS) and whether it has any

Ok; as I recall, there is a bit of information on this for ATS in one of
the Eurocontrol studies.  For PIES, it would be the same as typical Internet
applications already use DNS.

>MNN:  whether they are expected to be mixed IPv4 and IPv6 or solely IPv6

For PIES they may be mixed, but for ATS we can assume IPv6.

>information can be estimated.  

Agreed, though it's tricky :).  I think we could make some statements
that are predicated with "at least" like "at least 2 routers per aircraft",
"at least 10,000 aircraft", and "at least N passengers per plane" (based
on the capacity of one of the new behemoth planes).

>loss or duplication of data..."

Do we then have to define transient?
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 13 Mar 2008 05:08:11 -0700

I do not speak for Boeing, but regarding Hesham's statement to
me at the mike yesterday about the MEXT focus on MIPv6 we have
also been exploring other mobility management alternatives.

Fred

---

From: Ashutosh Dutta <[email-masked]>
Date: Thu, 13 Mar 2008 09:35:08 -0400

Fred,
      Although it appears from the current charter that MEXT focuses on 
MIPv6 related mobility management, I personally think we need a platform 
within IETF to discuss and explore other mobility management 
alternatives as well.

I think MEXT as the name stands for (Mobility EXTensions for IPv6) could 
be a possible platform to help exploration of other types of mobility 
protocols in future and discussion of other types of mobility protocols 
could be considered as part of the future charter.

Regards
Ashutosh