Subject: [MEXT] comments to draft-bernardos-mext-aero-nemo-ro-sol-analysis-01.txt

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 17 Nov 2008 11:05:06 -0600

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 :-)

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...

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?

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.

regards,
ryuji

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

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 17 Nov 2008 18:35:33 +0100

Hi Ryuji,

> Unfortunately, I don't have answers to any of them :-)

Thanks for reading the draft and for your comments.

Some in line comments below...

> 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...

> 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.

>    we need more detailed information of topology information.

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

	Thanks,

	Carlos

-- 
 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
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 17 Nov 2008 11:42:50 -0600

Hi Carlos,

> this is likely to happen). This is something that the aviation people

Right.
Is gASP failure equal to the BGP DFZ failure on the Internet, no?

> assumed in the aviation scenario or not.

My point was that
this trust relationship issue is not always technical one, but  
political one.

thanks,
ryuji