Subject: RE: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter proposal)

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 29 Mar 2006 17:56:01 +0200

>-----Original Message-----
>From: Dul, Andrew L [mailto:[email-masked]]
>Sent: Tuesday, March 28, 2006 11:15 PM
>To: Vijay Devarapalli; Davis, Terry L; T.J. Kniveton; ml-nemo WG
>Subject: draft-thubert-nemo-global-haha-01.txt (was: [nemo] Charter
proposal)
>
>> -----Original Message-----
>> From: Vijay Devarapalli [mailto:[email-masked]]
>> Sent: Monday, March 27, 2006 11:11 AM
>> To: Davis, Terry L; Zhigang Huang; T.J. Kniveton; ml-nemo WG
>> Subject: RE: [nemo] Charter proposal
>>
>> hi Terry,
>>
>> Global HAHA can address the two requirements.
>>
>(http://www.ietf.org/internet-drafts/draft-thubert-nemo-global-haha-01.
t
>xt)
>> but for some reason, the NEMO WG has not been able to take a
>> decision on Global HAHA (its been bouncing back and forth
>> between NEMO and
>> Monami6 WGs). the NEMO WG has been sitting on this draft for
>> more than two years now, even though you have expressed
>> interest in it numerous times. there is no home for it currently.
>>
>
>I think there are other reasons why this draft hasn't moved forward
>other than trying to figure out which working group should be solving
>the problems.
>
>Aviation & maritime platforms are globally mobile, because they are
>globally mobile this makes route optimization also an InterDomain
>Routing issue.
>
>Even if you had global-haha implemented it would require multiple ASNs
>to announce the mobile platform's address space.  That would likely
>require cooperation among a number of network operators to truly get
>route-optimization.   These network operators would also have to agree
>to provide transit to other operators where the mobile platform was
>currently homed.
>
>Alternatively the mobile service provider would have to setup
>infrastructure in multiple well connected and well peered global
>locations just to prevent triangle routing from occuring.  The mobile
>service provider would also have to provide a transit network to
>transport traffic between the HA and the current attachment point.
>
>I personally think there are interesting ideas in the global-haha
draft,
>but I'm not don't know if the operational deployment issues make it the
>best path forward.

[Pascal] This is interesting. 
Similar issues arise for the mobile phone roaming and when there's
business, it appears that Service Provider are ready to make the effort.
Maybe the protocol can be tuned to improve that? 
At least if we can match the draft with a WG, then people can discuss
that sort of thing. 

The good news is that TJ's revised charter has a line that could cover
these discussions:
Aug 2006          Submit -00 draft on Route Optimization for
geographically distributed HAs

We can propose global HAHA as a candidate, compete with other proposals
and try to keep the best from all. 

Pascal

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 30 Mar 2006 08:41:58 +0300

Hi all,

> geographically distributed HAs

right, but the proposed charted also states that:

The WG will:

- Ensure that solutions will scale and function for the different
mobile network configurations, without requiring changes to
Correspondent Nodes in the Internet. All solutions will aim at
preserving route aggregation within the Internet and will satisfy an
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
acceptable level of security (a thorough survey of new threats and an
analysis of their severity will be conducted for any changes introduced  
to the network).

I guess one of the points Andrew is pointing out is exactly with  

>> to announce the mobile platform's address space.  That would likely

how would this affect aggregation?

imho we should first discuss and figure out if the operational  
practices resulting from such a solution are acceptable before  
chartering the work. I mean we should first figure out at least if  
there seems to be a viable approach that fulfills the needs and  
preserves scalability of the routing system

Regards, marcelo

---

From: Simon Oosthoek <[email-masked]>
Date: Thu, 30 Mar 2006 11:17:05 +0200

> I guess one of the points Andrew is pointing out is exactly with respect 
> to this issues, namely:
> 
> imho we should first discuss and figure out if the operational practices 
> resulting from such a solution are acceptable before chartering the 
> work. I mean we should first figure out at least if there seems to be a 
> viable approach that fulfills the needs and preserves scalability of the 
> routing system
> 
> Regards, marcelo
> 

Hi all

[disclaimer: I'm not actively working on standardisation of NEMO, just 
lurking usually and trying to use the concepts of NEMO in 
www.ist-magnet.org]

To me it seems there are two problems under discussion, one is simply a 
moving network and how to reach it and the other is providing a VPN like 
structure with moving networks as part of the VPN.

In the first scenario, wouldn't it be enough to have the HA and MR 
inform corresponding nodes of a "via router" that is the actual care-off 
address of the MR for the address inside the MNP? That way the CNs can 
always directly communicate with the MR and if that fails, fall back to 
the HA until it gets an updated VIA.

The second case is much different, being a VPN, it might be desirable to 
hide the physical location of the MR from the CN and thus it would not 
be desirable to RO that communication. A proxy-HA might be interesting 
here, but only if it is part of the same VPN structure. And I think this 
will still reveal something about the physical location of the MR.

Cheers

Simon

---

From: "Ben McCarthy" <[email-masked]>
Date: Thu, 30 Mar 2006 10:48:58 +0100

-----Original Message-----
From: Simon Oosthoek [mailto:[email-masked]] 
Sent: 30 March 2006 10:17
To: ml-nemo WG
Cc: marcelo bagnulo braun
Subject: Re: draft-thubert-nemo-global-haha-01.txt (was: [nemo]Charter
proposal)

Hi all

Cheers

Simon

[Ben M]

Simon, 

In your 1st scenario, consider a MR providing an access network on a train,
conceptually providing connectivity to possibly 100's of nodes. With the RO
system you propose, every CN that every node is communicating with would
have to be updated, every time the MR changed its point-of-attachment. This
would result in having to perform something equivalent to the MIPv6 Return
Routability test (not a particularly lightweight procedure) with every CN
every time the MR picked up a new CoA. Then if you consider that the train
could be tarvelling at a few hundred Km/hr and handing off relatively
frequently, what you get is a lot of protocol overhead (Binding Update
Storms) when roaming. And that's without taking into account the added
complexity of a Nested Nemo scenario, i.e. if a PAN got on the train :).

Ben