Re: [MEXT] comments todraft-bernardos-mext-aero-nemo-ro-sol-analysis-01.txt

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Mon, 17 November 2008 17:36 UTC

Return-Path: <mext-bounces@ietf.org>
X-Original-To: monami6-archive@megatron.ietf.org
Delivered-To: ietfarch-monami6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 449C03A69CC; Mon, 17 Nov 2008 09:36:16 -0800 (PST)
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68FEB28C1BC for <mext@core3.amsl.com>; Mon, 17 Nov 2008 09:36:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level:
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqEQmJ7SogNl for <mext@core3.amsl.com>; Mon, 17 Nov 2008 09:36:13 -0800 (PST)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 906463A677D for <mext@ietf.org>; Mon, 17 Nov 2008 09:35:38 -0800 (PST)
Received: from [130.129.63.219] (unknown [130.129.63.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id BAA8F5CBBDC; Mon, 17 Nov 2008 18:35:35 +0100 (CET)
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
In-Reply-To: <E09A4DB5-07C8-4731-AACC-693DF9193124@gmail.com>
References: <E09A4DB5-07C8-4731-AACC-693DF9193124@gmail.com>
Organization: Universidad Carlos III de Madrid
Date: Mon, 17 Nov 2008 18:35:33 +0100
Message-Id: <1226943333.4512.75.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Cc: mext@ietf.org
Subject: Re: [MEXT] comments todraft-bernardos-mext-aero-nemo-ro-sol-analysis-01.txt
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1341375509=="
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

Hi Ryuji,

El lun, 17-11-2008 a las 11:05 -0600, Ryuji Wakikawa escribió:
> Hi Carlos and Marcelo,
> 
> Thanks for writing this document.
> It summarizes the list of right questions to aviation industry.
> Unfortunately, I don't have answers to any of them :-)

Thanks for reading the draft and for your comments.

Some in line comments below...

> 
> Some comments
> 
> In section 3.1,
>     o  if a craft attached to an ANSP access network is communicating
>        with a CN attached to the same ANSP, is it required for the NEMO
>        RO solution to survive when the link of the ANSP to its gACSP  
> goes
>        down? or put in a different way, would it be OK for such a
>        communication to be broken?  It should be noted that the default
>        MRHA path used by the NEMO Basic Support protocol would likely
>        fail in this scenario.
> 
> Are you sure we need to consider the scenario of gACSP failure?
> gACSP failure seems very critical errors and MUST NOT be happened...

The point is that we don't know if this should be considered or not, we
just pointed out that this is a possible situation (we don't know if
this is likely to happen). This is something that the aviation people
should let us know...

> 
> 
> In section 3.2,
>     entities belong to the same administrative domain.  However, this
>     does not mean that this scenario is excluded from having trust
>     issues, since a particular solution might require to inject routes  
> in
>     some parts of the network (e.g., RO entities owned by an airline and
>     placed in networks not managed by the airline, anycast routing,
>     etc.), and this could require additional trust relationships.
> 
> This additional trust relationships are not always required to be  
> dynamic one.
> It might be just business agreements, isn't it?

They might be, yes, but they are required, right?. The point is that we
don't know whether these trust relationships/business agreements can be
assumed in the aviation scenario or not.

> 
> I think we need more information from aviation industry such as
> - How many CNs does each MR communicates with?
> - How many ANSPs does each MR communicate with?
> - The least HOPs path is not always the shortest latency path.
>    It depends on the topology (L1-L3) of gACSP and ANSPs.
>    Since the aviation network is somehow closed network and designed  
> by themselves,
>    we need more detailed information of topology information.
> 

	I agree this information would be also useful for the solution design.

	Thanks,

	Carlos

> regards,
> ryuji
> 
> 
> 
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
-- 
 Carlos Jesús Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext