Subject: [MEXT] comments on draft-ietf-mext-aero-reqs-00

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 20 Jan 2008 20:02:45 +0100

Hi,

i have reviewed this document and i think it is in very good shape.  
The Requirements are clear and there is enough background information  
to understand why requirements are there (at least in most of the  
cases, see below)

My main concern is that i am afraid that the 3 cases considered ATS,  
AOS and PIES are very different from each other. In particular, i  
think the impose very different requirements and that they have  
different underlying trust models, which will make solutions very  
different in the different scenarios (at least security wise)
My main problem with the way the requirements are described, is that  
it seems that since the ATS case is more critical, the requiremetns  
for the ATS case are the MUST while the other cases are just desired  
features. The problem with that, is that the requirements for ATS are  
imposed to all the cases, so when designing a solution for PIES, we  
also would need to fullfill the requiremetns for ATS making the  
design of such a solution extremely hard imho. So, bottom line is  
that while i do agree that having a single solution for all the 3  
cases would be great, i am skeptical that we will be abl to do so and  
i think that at least some modules, like security ones, will differ  
from the mechanisms for ATS and the one for PIES.

So, i would like to propose that we actually divide the requirements  
in 2 or 3 lists, one for ATS (and maybe also for AOS) and another one  
for PIES, so we could design a different solution for ATS and for  
PIES. (this of course does not preclude the posibility of having a  
single solution for all the 3, but makes easier to understand imho to  
which scenario a given solutions fits better). (more comments about  
this below)

In section 2.1.  Aeronautical Communications Scenarios it is stated  
that:

    During en-route flight, handovers between VDL mode 2
    channels may occur every 30 to 60 minutes, depending on the exact
    flight plan and layout of towers, cells, and sectors used by a
    service provider.

What is the implication of changing between VDL mode 2 channels? does  
this means that a new CoA is acquired every 30 to 60 min during en- 
route flight? I think this should be clarified, since it is important  
to be able to translate into IP terms what the conditions mean imho

Are there multiple links active during the flight or are the links  
sequentially available? I mean, would it be possible to use multiple  
different links simultaneously or just sequentially?

Next the following paragraph states:

    The characteristics of a data flow between a CN and MNN varies both
    depending on the data flow's domain, and the particular application
    within the domain.  Even within the three aeronautical domains
    described below, there are varying classes of service that are
    regulated differently, but this level of detail has been abstracted
    out for the purposes of this document.  It is assumed that any  
viable
    NEMO RO solution will be able to support a granularity of
    configuration with many sub-classes of traffic within each of the
    specific domains listed here.

It is hard for me to understand the point being made in this  
paragraph. What are the different constraints imposed to the  
different services? More precisely, what does the "support a  
granularity f configuration" means here? Does this refer to Des1 -  
Configuration?

Bottom line, i think this paragraph as stated is confusing and it is  
hard to extract what is the conditions that are assumed, so it would  
be good either to include a pointer where this is described more  
clearly in the document, either to describe more clearly here either  
to remove it.

Next in section 2.1.1.  Air Traffic Services Domain it is stated that:

    These
    MNNs will mostly be Local Fixed Nodes (LFNs), with a few Local  
Mobile
    Nodes (LMNs) to support Electronic Flight Bags, for instance.

According to the terminology document a LMN is

Local Mobile Node (LMN)

    A mobile node (MN), either a host or a router which can move
    topologically with respect to the MR and whose home link belongs to
    the mobile network. It's address is taken from a NEMO-prefix.

So, are you saying that there will be mobile nodes which Home Agent  
will be located within the aircraft?
I don't have a problem with that, just that i find it strange...  
(FWIW i don't know what an Electronic Flight Bag is, so... what can  
you expect? :-)

Later on, it is stated that:

    An MR used for ATS will be capable of using multiple data links (at
    least VHF-based, satellite, HF-based, and wired), and will likely be
    supported by a backup unit in the case of failure, leading to a case
    of a multi-homed MR that is at least multi-interfaced and possibly
    multi-prefixed as well, in NEMO terminology.

So, there will be two MR for this, but they are never used  
simultaneously, since one is the backup of the other one, right? Can  
we assume that only one MR is on and the other one takes over only  
when the primary one is down?
However, each router will do have multiple interfaces. What do you  
mean that the MR is multiprefixed? Does it mean that it has multiple  
MNPs? If yes, why do you say that? does it have multiple CoAs in the  
same interface?

Later on, in this same section, it is stated that:

    Many of these may be
    aircraft-to-aircraft, but the majority of current exchanges are
    between the MNNs and a very small set of CNs within a control
    facility at any time due to the full transfer of control as a plane
    moves across sectors of airspace.

A few questions about the CNs? You mention before that software  
updates can be performed at the MNN, is this also the case for the  
reduced set of CNS? i.e. would it be possible to update the CNs in  
this case? Furthermore, the CNs is a reduced set, would it possible  
to assume a pre-existing trust relationship between the nemo and all  
the potential CNs in this case? (for instance, that it would be  
possible to create a SA using that pre-existing trust relationship,  
like in the case of the MN and the HA). Same question for AOS CNs.

Later on, in section 2.1.3.  Passenger Services Domain it is stated  
that:

    The majority of these MNNs are VMNs and personal
    property brought onboard by passengers for the duration of a flight,

I don't think these are VMNs actually. According to the nemo  
terminology document, VMN is

Visiting Mobile Node (VMN)

    A mobile node (MN), either a host or a router which can move
    topologically with respect to the MR and whose home link doesn't
    belong to the mobile network. A VMN that gets temporarily  
attached to
    a NEMO-link (used as a foreign link) obtains an address on that link
    (i.e. taken from a NEMO-prefix).

 From that perspective, i think that most nodes attached to the  
aircraft network will be LFN. I mean, when i bring my laptop and i  
connect it to the aircraft network, i acquire a address using dhcp,  
my laptop is working as a LFN rather than as a VMN, since my laptop  
has no Home Address in any remote link. A VMN would be a node that  
wants to keep using its HoA located in a remote network and acquires  
a CoA from the MNP. While this is possible and i wouldn't rule it  
out, i think that the most common case today would be that the laptop  
and other devices of the passengers will act as LFN rather than VMN.  
 From that perspective, i would guess that there will be LFN in the  
PIES network.

So trying to understand the impact of the different type of traffic  
with the resulting required and desirable features in sections 3 and  
4, i find the following texts relevant

For AOS:

    For these reasons, in this document,
    we consider AOS data flow concerns with RO mechanisms to not be full
    requirements, but instead consider them under the desirable
    properties in Section 4.

For PIES

    Due to the lack of
    criticality and the likelihood of being treated independently, in
    this document, PIES MNN concerns are not considered as input to
    requirements in Section 3.  The RO solution should be optimized for
    ATS and AOS needs, and consider PIES as a secondary concern.

So i understand from that that the requirements described in section  
3 take only into account the needs of ATS while the Desirable  
features in section 4 take into account all the 3 type of traffic,  
namely, ATS, AOS, and PIES, would that be correct?

I am kind on doubtful if this is the best way to put it. I mean, it  
seems clear to me at this stage that at least the ATS and the PIES  
are very different problems and that are likely to be completely  
different networks. The AOS lies somewhere in between and it does  
seem to have the same trust model than ATS but require similar  
reliability than PIES, so it may be possible that either a ATS  
solution or a PIES type of solutions can be used for ATS.
However, I am certainly not sure whether it make sense to have a  
single set of requirements mixing all the requirements from ATS, AOS  
and PIES.
I mean, it certainly would be good if a single solution (with maybe  
some different security tools and some extensions could be used for  
all 3 type of traffic. But i wonder if it wouldn't be useful to have  
3 different sets of requirements (possible with some overlapping) one  
for each type of traffic. The nice thing of such requirements would  
be that they would be have an internal logic, since each of them  
would clearly respond to the logic of the particular type of traffic  
that is being considered.
Finally, while i do understand that from the safety perspective the  
ATS is the most critical by far, from a standardization perspective,  
probably the PIES is the most challenging one, so i wouldn't want to  
discard it just yet. So, if we do a single requirement list, of  
course the ATS requirements are more important than the PIES  
requirements, but i wouldn't discard the PIES requiremetns as second  
class requirements. If we put this as 3 lists of requirements, one  
per type of traffic, then each category would have the requirements  
and the desirable features, responding to its own internal logic.

Comments?

With respect to Space Exploration scenarios, would it be ok to say  
that it is very similar to the ATS case? I mean, from the type of CNs  
and MNN, it seems to be very similar. There may be some specifics,  
like the asymmetry of data links and maybe the existence of nested  
nemos due to the PANs, but maybe if the similarities with the ATS  
case are important it would be valuable to state this up front and  
identify the differences, so that we could easily understand what  
would be the additional features that a ATS solution would need to  
provide support for this scenario, would that make sense?

With respect to Req1- Separability, is it relevant who decides which  
traffic goes through which path? I means, is it the MR that needs to  
be able to enforce that or is it enough that the MR is able to  
suggest that, or could it be the MNN who decides which path to use?  
(Note that it may be ok that anyone decides, which seems to be what  
is described right now, just want to understand who is supposed to do  
this)

With respect to Req2- Multihoming:
- What do you mean by the nemo having multiple prefixes? Does this  
means that it has multiple MNPs? What do you want to support with the  
multiple MNPs?
- What does the expression "in the MONAMI6 context" means?
- Similarly, later on, the text talks about monami6 basic extensions,  
what does that means? I assume that means multiple CoAs and flow  
policy distribution, would that be it? What about fault tolerance  
would that be needed or not? I mean, neither MCOAS nor flow policy  
deals with fault tolerance, wouldn't this be needed? Wouldn't be  
important that in case a link goes down, the existnet communications  
that are being RO can be diverted to an alternative path? Wouldn't it  
be important that if there is a failure, all new communications can  
be RO using an alternative path? What about multiple HoAs?

With respect to Req4- Availability
The goal is clear, but i wonder if replicated elements should be  
placed in differnet geographical location, in order to support cases  
where a whole site crashes.

With respect to Req6- Scalability
I am not sure i understand this. I mean, AFAIU, these requirements  
are mostly for the ATS case. So, it is mostly a communication with  
the ground network. But i understand that there will be many grounds  
networks and that not all the 10000 aircrafts will be using the same  
ground network, i guess. So, i guess that we are not requiring that  
the system scale for all the aircrafts installing state in the same  
ground network. How many aircrafts do you think will be per ground  
network?
(I do understand the 10000 figure for the routing case but not for  
the ground network)

With respect to Req8 Security.
I would like to include something more general here (in addition to  
what it is already there), something like RO solutions MUST NOT  
introduce any new vulnerability compared to the NEMO basic case.  
Moreover, i think we should also include something about the  
different networks here, i mean, that ATS, AOS and PIES cannot  
conflict to each other. In other words, if the same solution supports  
all the tree type of traffic, security issues may arise from the fact  
that the PIES traffic may interfere with the ATS traffic and so on.

With respect to Des2 Nesting
Maybe it would be good if you expalined a bit more what do you mean  
to support nesting. I mean, does it means that complete RO would be  
supported, meaning direct communication btween the CN and the first  
MR or that the RO of the root nemo still works for nested networks.  
Same w.r.t. to overhead. I mean, is the additional overhead of  
nesting (i.e. 2 tunnels) a big problem (as big as the panoramic  
routing) or less/more relevant?

With respect to Des4 - VMN support
As i mentioned before, i fail to understand the need for LMN, since  
this would require a HA located in the nemo, which seems strange to  
me (just to be clear, i am not arguing with this point, just wanting  
to make sure that we all understand the same thing by LMN)

_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext