Subject: [nemo] Comments on draft-eddy-nemo-aero-reqs-00

From: "Roberto Baldessari" <[email-masked]>
Date: Thu, 31 May 2007 11:18:50 +0200

Dear Wesley,

I read your draft and found it to be well focused with the WG goal and also clear. Indeed, it helps us in refining the automotive requirements in order them to be more focused on RO.

In particular most of the described requirements are precise and, I think, helpful for solution designers (i.e. separability, latency, security and integrity). Some others are not clear to me or, better, I think they are not exclusively or directly related to RO:

- Req4 (availability): in my opinion any RO scheme will alleviate the problem of a single point of failure instead of creating it. Or do you mean that RO should work even if the HA is not available? We also pointed out this, but then I've realized that "internet-less" RO might distract the WG and prevent it to come to (at least) a basic RO scheme MIPv6-like. RO without infrastructure should better be the focus of other WGs

- Req6 (scalability): it is hard to determine whether an RO scheme is scalable in terms of signaling, as it depends on other variables (network capacity, mobility,...). More than a absolute requirement, I consider this as an important criterion in relative terms. I.e. a solution with lower signaling will be preferred compared with one with higher signaling

- Req8 (security): I think it would be beneficial to specify whether or not you require IPsec to be usable for LFN or only in the RO signaling or in the tunnel MR-HA. We will also try to specify something more about security in the automotive requirements.

Best regards,

Roberto

================================================
Roberto Baldessari
Research Staff Member
Network Laboratories, NEC Europe Ltd.
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-167
Fax:     +49 (0)6221 4342-55
e-mail:  [email-masked]
web:     http://www.netlab.nec.de/

NEC Europe Limited | Registered Office: 
NEC House, 1 Victoria Road, London W3 6BL 
Registered in England 2832014 
================================================

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 31 May 2007 09:19:18 -0400

On Thu, May 31, 2007 at 11:18:50AM +0200, Roberto Baldessari wrote:
> 
> Dear Wesley,
> 
> I read your draft and found it to be well focused with the WG goal and
> also clear. Indeed, it helps us in refining the automotive requirements
> in order them to be more focused on RO.

Good; thanks for the constructive comments.  Here are some responses:

> In particular most of the described requirements are precise and, I
> think, helpful for solution designers (i.e. separability, latency,
> security and integrity). Some others are not clear to me or, better, I
> think they are not exclusively or directly related to RO:

I think you're right, and we should at the very least refine the wording
on the 3 requirements you mention (availability, scalability, and
security).

> - Req4 (availability): in my opinion any RO scheme will alleviate the
> problem of a single point of failure instead of creating it. Or do you
> mean that RO should work even if the HA is not available? We also
> pointed out this, but then I've realized that "internet-less" RO might
> distract the WG and prevent it to come to (at least) a basic RO scheme
> MIPv6-like. RO without infrastructure should better be the focus of
> other WGs

Personally, I hadn't been thinking about the Internet-less case of not
being able to reach any HA, but rather I was trying to say that it won't
be acceptable for a solution to only work under the assumption that a
single MR services a mobile network, or a single HA or access router
services an MR (or set of MRs).

In other words, we need the solution to co-exist peacefully with both HA
reliability mechanisms (e.g. the one MIP6 is working on), multihoming
mechanisms, and with multiple MRs.

Do you think it would be more clear if I added a sentence that
specifically excluded Internet-less operation from being required?

> - Req6 (scalability): it is hard to determine whether an RO scheme is
> scalable in terms of signaling, as it depends on other variables
> (network capacity, mobility,...). More than a absolute requirement, I
> consider this as an important criterion in relative terms. I.e. a
> solution with lower signaling will be preferred compared with one with
> higher signaling

Agreed; this is an important metric, but one that's fairly
scenario-dependent in measurement and evaluation.  For aircraft, the
mobility patterns are tough to guess at because they depend on the link
technologies used.  Since many of the current links are very low-rate,
basing an analysis on them may not be particularly useful, although I
gave some rough estimate of the time between changing VDL channels in
the draft.  I will check and see if the COCR document from the
FAA/Eurocontrol Future Communications Study has any guidance on how we
can specify scalability in greater detail for aeronautics.

> - Req8 (security): I think it would be beneficial to specify whether
> or not you require IPsec to be usable for LFN or only in the RO
> signaling or in the tunnel MR-HA. We will also try to specify something
> more about security in the automotive requirements.

I think it should be possible to use in both cases, although it must be
understood that in some cases, the security mechanisms can undo the RO,
as Will Ivancic is very good at explaining :).  My goals for this
requirement were to (1) ensure that the data used to make RO decisions
can be authenticable, and (2) ensure that flows using transport-mode
IPsec can use RO between the two end-points, and flows using tunnel-mode
IPsec can get RO between the MR and the groundward side of the tunnel.
If I put some more explanation of this into the draft, would that help?

I would be interested in reviewing the automotive requirements, if/when
they are available.  I'm not sure how similar they will be to the aero
requirements, but it would be really neat if a common solution was
acceptable for both.

-- 
Wesley M. Eddy
Verizon Federal Network Systems