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

[Ryuji Wakikawa <[e-mail]>]

Hi Marcelo,

Thanks for summary.


On 2008/07/25, at 2:01, marcelo bagnulo braun wrote:

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

what's differences of these two?
IMO, Anycast routing is used to sink traffic for the propose anchor  
point.

> - strong state synchronization between HAs/anchor points

There are several approaches to sync MN's state.
As described in Pascal's ID, there are several approaches how to  
manage MN's state such as on-demand, proactive, even predictive mode.
Airflights' movements can be easily traced and expected, there are  
many ways to optimize this state sync functionality.


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

agree on deploying HAs in gACSP. I also want to know the relationship  
of gASCP, ASCP, ANSP and aviation companies.
Are there any peering points such as IX in aviation networks?

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

I think this is reasonable approach for aviation case.
do you see any potential issue? We inject HAHA experimental prefix   
from different ISPs(i.e. AS) to BGP. We don't have any issues so far.
>
>
> 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.

It is very important to know WHO will manage HA. I am not sure each  
airline company will operate HA by themselves..

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

Do we need to discuss this redundancy requirement in this RO discussion?

As I mentioned in the other mails, this is not correct behavior of  
MobileIP/NEMO.
Both protocols rely on HA reliability and requires HA accessibility in  
order to provide mobility support.
That's why we are working on HA reliability protocol (local  
redundancy) and globalHAHA (global redundancy).

BTW, I don't think we should consider the case of gACSP down.
Is this realistic scenarios? If so, shall I return to Japan by sailing!?

regards,
ryuji



> 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