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

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 10 Mar 2008 08:12:46 -0700

-----Original Message-----
From: Templin, Fred L 
Sent: Friday, March 07, 2008 3:31 PM
To: 'Julien Laganier'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]'; Davis, Terry L; Fleischman, Eric; Henderson, Thomas R; Templin, Fred L
Subject: RE: [MEXT] [WGLC] draft-ietf-mext-aero-reqs-01

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: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Tue, 11 Mar 2008 00:06:10 -0500

>the point that they almost warrant consideration under

Ok.  I suggest we add a couple sentences into the introductory
part of Section 3 that makes it more clear that different
solutions may be needed for the different domains.  We already
have some text that says that NEMO itself might not even be
the chosen technology for a particular domain, but it's not
early enough in the document or clear enough.

>applicability for the various domains.

We could at least give pointers and status of the ICAO
WGs that are working on data links that would/could be
used to support air-ground IP services, and have some
discussion of existing systems in the PIES domain.

>more about what is intended here.

I believe the increased risk of fragmentation may not
apply as much to the aero cases, as nesting is not as
great of a concern.  We can probably remove this
paragraph without loss of motivational meat for RO.
Not crossing continents unnecessarily is the main
driver, and the others are just icing.

>the internal network organization in future control

Hmmm, true.  Does "topologically close" work better?

>page. Can it be broken into multiple simpler sentences

Yes!  Sorry about that one :)

>approaches to meet the stated ICAO TC-1 other than

I don't think the intention is that multi-addressing be a
requirement for an RO scheme to support, but rather that
multi-addressing is one (of several) ways that the desired
separation could be created.  We could clarify the text.

>that this may be a requirement that is not easily

Agreed; and I notice this is very similar to one of Tom's
comments.

>and/or packet loss may occr.

Given that there are N proposals in the RRG, most of which
are not fully understood even within that RG, none are yet
adopted by the RG as work items, and it's after all an RG,
I *really* don't want to do this analysis ... IMHO, it's
the job of an RRG proposal to analyze how much it screws
up other things the IETF has specified, rather than vice-versa.

>domains would be appropriate.

Actually, the requirement is already in terms of specific
domains, as it says that PIES has no requirement beyond
normal MIPv6 RO, and it also does not lean towards CGA
very strongly, as it specifically lists "safe assumptions"
about ingress filtering and use of the decrypted alternate
CoA.

>be representative of all IPsec implementations.

Ok.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 11 Mar 2008 07:59:20 -0700

Wesley,

Responses below:

Fred

FT=> Works for me.	

FT=> Would be helpful.

FT=> OK.

FT=> OK.

FT=> OK.

FT=> Would be happy to review the clarified text.

FT=> OK.

FT=> Maybe it would have helped were I to have phrased this in
FT=> terms of the future routing system in general, and not the
FT=> RRG proposals in particular. I am sitting here in the RRG
FT=> meeting, and the topic of routing interactions with the
FT=> mobility system was discussed for about 30 minutes. My
FT=> takeaway is that most people seem to believe there are
FT=> interactions to be examined, but noone seems to have a
FT=> firm handle on them. The point is that it is a two-way
FT=> street; both the routing and mobility communities are
FT=> responsible examining the potential interactions.

FT=> I would be happier were the text to say something like
FT=> "validate an MR" instead of "validate the CoAs...". (Or
FT=> maybe there is some way to say "validate ... and/or ..."?)

	Ok.