Re: [MEXT] Thoughts on the different nemo ro approaches

["Templin, Fred L" <[e-mail]>]

Thanks Marcelo,

Nonetheless, link performance characteristics are an important
consideration (e.g., see RFC3819). I tried to raise this at the
mike at one of the past meetings but didn't do a very good job
of it, so it seemed necessary to raise it again here.

Fred
[e-mail] 

>-----Original Message-----
>From: marcelo bagnulo braun [mailto:[e-mail]] 
>Sent: Thursday, July 24, 2008 10:38 AM
>To: Templin, Fred L
>Cc: mext
>Subject: Re: [MEXT] Thoughts on the different nemo ro approaches
>
>Hi Fred,
>
>thanks for the input
>
>according to draft-bauer-mext-aero-topology-00
>
>   Meanwhile
>
>   ICAO is currently producing an amended version of the manual that
>
>   allows the ATN to be an internetwork based on IPv6 for both ground-
>
>   ground and air-ground communications.  States have already begun
>
>   deployment of the ground portion.  Definition of the 
>mobility support
>
>   for aircraft within this new ATN architecture is underway 
>in the ICAO
>
>   and will form the basis of new ATN manual [icao9896].
>
>I guess you can find similar statements in other places as well.
>So it seem that there are some people that think this will be possible 
>in the future and now it is good time to design the solution, in order 
>to deploy the solution within the required timing
>
>Regards, marcelo
>
>
>
>Templin, Fred L escribió:
>> Marcelo,
>>
>> What is the timeframe you are looking for a RO solution
>> for aeronautical use cases? To my understanding, ATS/AOS
>> communications require safety-of-flight certified links
>> and I am not seeing near-term safety-of-flight certified
>> links with performance characteristics capable of handling
>> IPv6 let alone the additional signalling required for RO
>> (at least not in terms of scaling to the anticipated numbers
>> of aircraft in a multiple access domain).
>>
>> Asked another way, can the aeronautical use cases be
>> considered as a near-term driver for a RO solution when
>> the links may not yet be ready to handle even IPv6?
>>
>> Thanks - Fred
>> [e-mail]
>>   
>>   
>>> -----Original Message-----
>>> From: marcelo bagnulo braun [mailto:[e-mail]] 
>>> Sent: Thursday, July 24, 2008 10:02 AM
>>> To: mext
>>> Subject: [MEXT] Thoughts on the different nemo ro approaches
>>>
>>> Hi,
>>>
>>> I have been reading the drafts people have submitted for 
>the nemo ro 
>>> work for the aviation case.
>>> In particular, i have read
>>>
>>> draft-bauer-mext-aero-topology-00
>>> draft-wakikawa-mext-haha-interop2008-00
>>> draft-wakikawa-mext-cr-consideration-00
>>> draft-wakikawa-nemo-orc-01
>>> draft-thubert-mext-global-haha-00
>>> draft-bernardos-mext-nemo-ro-cr-00
>>>
>>> Essentially we have two different approaches, one based on 
>distributed 
>>> HAs and another one based on the concept of the 
>correspondent router.
>>> It seems to me that the CR based approach is more complex 
>than the ha 
>>> based approach, so i guess that a first legitimate question 
>to ask is 
>>> where does the complexity springs from?
>>> One observation that i would like to contrast with the group 
>>> is that the 
>>> HA based approach makes the following fundamental 
>assumption: A set of 
>>> globally distributed anchor points that are within the _same_ 
>>> administrative domain are available and are enough to 
>provide the RO 
>>> capabilities required.
>>>
>>> OTOH, the CR based approach makes a different assumption, 
>>> which is that 
>>> a set of distributed anchor points with which is possible to have a 
>>> trust relationship are available and are enough to provide the RO 
>>> capabilties required.
>>>
>>> The difference as i understand it, is that the HA based 
>>> approach assumes 
>>> that the anchor points are in the same admin domain (or 
>that they are 
>>> within domains with strong admin relationship, which allows 
>them to do 
>>> functions that are usually not acceptable across domains) 
>and the CR 
>>> based approach does not makes that assumption.
>>>
>>> By assuming that these anchor points are in the same admin 
>domain, the 
>>> HA based approach can take advantage of the following 
>>> functions that are 
>>> not available across domains (i may be missing some function):
>>> - anycast routing
>>> - host/MNP route injection to sink traffic for the proper 
>anchor point.
>>> - strong state synchronization between HAs/anchor points
>>>
>>> The usage of these tools indeed make life easier, but they 
>impose some 
>>> constraints.
>>> I think that we need to understand these constraints, and 
>figure out 
>>> whether they are acceptable for the aviation community. In 
>>> other words, 
>>> i think that a relevant exercise at this point is to try to 
>figure out 
>>> how a HA based approach can be deployed within the aviation 
>scenario 
>>> described in draft-bauer-mext-aero-topology-00
>>>
>>> So, let's consider how this could be deployed.
>>>
>>> A first deployment scenario would be that the HAs are deployed 
>>> within a 
>>> gACSP. This seems like the perfect match. The gACSP has global 
>>> infrastructure, so it can be assumed to have HAs 
>distributed along the 
>>> globe and they can provide reasonable good enough rute 
>>> optimization. So, 
>>> if an aricraft is using the gACSP all the way, this seems to work 
>>> reasonably. A first question may be posed though in this 
>>> scenario about 
>>> addressing. From which prefix the MNP is extracted from? I 
>mean, one 
>>> option is that the gACSP has a prefix for this, and uses it to 
>>> assign to 
>>> all the different companies that it serves. However, this 
>would result 
>>> in a form of provider dependent addressing and maybe the 
>problems of 
>>> provider dependent addressing would rise here.  In other 
>>> words, is it ok 
>>> for the aviation companies to use a prefix that is owned by 
>the gASCP? 
>>> This basically means that if they want to change the 
>provider (i don't 
>>> know if this is possible), they will need to renumber.
>>> A related question to this one, about what is the normal relation 
>>> between the aviation company and the gASCP? Is it normal 
>that a given 
>>> aviation company works with one or both the gACSP that 
>exists? If they 
>>> work with one, the provide lock in effect could be an 
>issue. If they 
>>> work with two, then would this approach implies that they 
>need to have 
>>> two prefixes, one for each gACSP? That would probably be 
>problematic 
>>>     
>> >from the network management perspective. In both cases, 
>either if they 
>>   
>>> decide to use two prefixes, or they use a single gACSP with 
>only one 
>>> prefix, the next question is whether they can acquire a CoA 
>from the 
>>> other gACSP? if they can, it is possible that the gACSP 
>performs cold 
>>> potato routing and the RO benefits are not achieved.
>>> The other option of course is that the aviation companies have a 
>>> provider indepedent prefix and that the gACSP announces it on 
>>> behalf of 
>>> their clients. In this case both gACSP can announce the 
>client prefix. 
>>> The potential issue here is what is the impact for the 
>global routing 
>>> table of such practice.
>>>
>>> A second scenario is where other than gASCP are considered.
>>> At this point, i don't even grasp how the scenarios are. 
>For instance, 
>>> is it possible that some airlines do not have any relationship 
>>> with any 
>>> of the two gASCP? In that case, they only have contracts 
>with smaller 
>>> providers and in that case i this not clear to me how the ha 
>>> infrastructure can be deployed. I mean, would this imply 
>that each of 
>>> the smaller players will have a HA and they would run HAHA protocol 
>>> between them? I don't know if the implications of these are 
>acceptable 
>>> for the relationship that those players have.
>>>
>>> One particular case where this is significant is when the 
>>> communication 
>>> with the gACSP is down for whatever reason. If this is the 
>>> case, and the 
>>> HA infrastrucutre is not reachable, the direct communication 
>>> between the 
>>> aircraft and the CNs that are directly attached to the same 
>>> ACSP is not 
>>> possible, even if they have direct connectivity. I am not 
>sure if this 
>>> is acceptable.
>>>
>>> So, imho, what needs to be understood a bit more in depth is the 
>>> possible deployment models of a HA based approach in the aviation 
>>> reality. I am hoping that we can have this discussion in dublin
>>>
>>> Regards, marcelo
>>>
>>>
>>>
>>> _______________________________________________
>>> MEXT mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mext
>>>
>>>     
>>
>>   
>
>
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext