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

["CERASI Eivan" <[e-mail]>]

Just another thought on the subject.

In their own way, both solutions assume that a service provider between
the MR and CN is capable of providing managed value-added services to
perform RO.

This is very different to RO for MIP; I was wondering if it would make
sense to apply the NEMO RO solution as a means to enhance MIP RO. I
recognise it is not really within the charter but it may be an
additional aspect to support solution space and make more universal that
for the aviation sector.

Eivan

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

This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.

Any views expressed in this message are those of the sender.

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