Subject: RE: About the proposed charter and global HAHA (was Re: [nemo] RE: About route aggregation in global HAHA

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 12 Apr 2006 15:18:50 +0200

Hi Marcelo:

>you stated that:
>
>>
>> - The NEMO part for this discussion is enabling Route optimization
>> within the infrastructure. There are a number of use cases to sustain
>> the need. IP mobile telephony (4G?) is an example, where Service
>> Providers do not necessarily wish to have the phone perform the RO
>> themselves.
>>
>> - Global HAHA introduce proxy HAs which enable this route
optimization
>> with a trust model in place. I'd say that defining how that works is
>> enough work for NEMO; whereas proposing the deployment model should
be
>> a
>> request from us to other WGs.
>>
>
>IMHO, we should first decide on which forms of RO for nemo are we going
>to work on, and then move on to specific solutions.
>
>I mean, as specified in the RO taxonomy draft there are several and
>very different approaches to RO. I think that in order to do the
>charter for future work, we need first to decide which one of the RO
>approaches are we going to work on.
>
>However, the proposed charter only has Global HAHA as a RO solution for
>nemo, so it seems to imply that this is the RO that we have selected.
>I would propose to open the general discussion about which RO
>approaches are we going to work on first rather than focussing in if we
>are going to work on global haha or not...
>
[Pascal] 

My understanding is that the new charter covers a transition time.
Global HAHA, which covers the RO within the infrastructure, is well
advanced; it has been supported up to the plenary, so there's a common
thinking that we can go ahead and move it forward. 

Now, it is also my expectation is that NEMO will recharter again in a
year or so to solve more RO problems. If you have in mind a MR to MR RO
such as covered by MIRON, then I believe that if a group accepts the
document, it should definitely be discussed within NEMO at that point.

Finally, some RO schemes might not belong to NEMO as a WG. For instance,
there's a question whether MANET for NEMO (MANEMO) should be done within
NEMO or as a separate WG, because of the specific skills and interests
involved.

>
>Second, a more focussed issue with respect to routing system
>scalability and business model
>
>you stated that:
>
>> Let me give you an example. Say that 3-4 ISPs from different
continents
>> form a mobile ISP consortium.
>>
>> That consortium obtains a short prefix from one of the NICs, call it
>> the
>> mobile prefix. Internally, the consortium shares that addressing
space
>> between members, leaving big chunks free for new comers. The rule is
>> that only the big aggregation is redistributed over the Internet BGP,
>> from most POP of members ISPs. But internally, the consortium of
>> service
>> providers runs a second BGP which deals with the subnetting of mobile
>> prefix, over a mesh of tunnels and private links.
>
>but this seems to be complettelly different that what other people have
>been claiming here on the list.
>Past comments have strongly argued that global mobile network need PI
>addressing and global HAHA seemed a mechanisms to provide access to
>this PI prefix that the airline company gets.
>
>This is completelly different than the mobile ISP model that you are
>suggesting.

I was stretching the picture, but the ideas were their. The mobile
prefix I proposed might not clearly fit in PA, and is not PI in the geo
sense either. 

If you consider that the consortium becomes a virtual provider, then it
is a form of PA. But the prefix is not subnetted, as far as the Internet
BGP can see, so the aggregate looses some sense. 

You might consider that the consortium is provider independent, but the
prefix is surely not geo based. In fact, it is ubiquitous (close to you
wherever you are). This is why I proposed to go back to IPv6 or IPv6Ops
to discuss what that prefix is really and what the rules are for the RIR
to allocate it.

In any fashion, if there are few large consortiums, then this is surely
not a burden for the DFZ.
In fact, there would be another DFZ within the consortium to handle that
prefix as a sub-internet.
GTP proves that providers are willing to congregate when they find that
such is their interest.

>
>What worries me is that i don't see any mobile ISP in the list claiming
>that they need global HAHA to deploy their business, but there are end
>users (air companies) that claim that want PI addressing for deploying
>this.
>
If I understand well Tony's draft, NEMO is not the right forum for
Provider Independent (PI) allocation policy. And that work is still
ongoing, somewhere else...

As for ISP side, I'm copying Masafumi-san who co authored the NEMO RO
PS.

Note that the work on global HAHA started with voice ISPs and 4G design.
There was a strong requirement to make the phones unaware of RO. Some of
the reasons:

- privacy: one should not know where the mobile correspondent. In other
words, a phone should only see the other phone's Home Address, not its
CoA.

- phone: RO might cause interoperability problems between generations of
phones. You want the phone software to be simple - limited resources -
and conservative -protocol ha to remain stable for years - so changes
must occur centrally in the ISP side.

- radio: client based RO consumes additional resources on the first hop
whereas it saves resources globally. When the first hop is a radio and
the rest of the way is high speed wire, you might prefer the
infrastructure based RO to maintain the benefits of RO while preserving
radio resources.

- trust model: The global HAHA trust model is similar to classical
(phone) roaming. It is something that ISPs can understand and deploy. In
particular, it is possible to push policies to the proxy, acting like a
LMM anchor. 

I hope this helps...

Pascal

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 12 Apr 2006 16:58:33 +0300

Hi Pascal,

> My understanding is that the new charter covers a transition time.

not sure what you mean, and i am not sure why we need a transition nor 
a transition time... in any case, i guess we need to discuss in the wg 
whether this is the right approach...

> advanced;

what do you mean by "well advanced"? there are several nemo RO that has 
proposed ID and has implementations and so on...

moreover, there are RO solution that don't even require new protocols, 
so i guess those are really advanced, in the sense that they are 
possible with current specs...

>  it has been supported up to the plenary,

what plenary? ietf plenary? since when IETf plenary supports solutions? 
I guess this is the wg to decide, not the plenary...

>  so there's a common

not sure what common thinking you are talking about, but i would really 
amazed if there is a common thinking in the community to support a PI 
based solution....

> document, it should definitely be discussed within NEMO at that point.

not sure why do you think that we need two different stages... is this 
has been discussed in this wg? wouldn't this be part of the 
rechartering discussion that is having place right now in this wg?

> NEMO or as a separate WG, because of the specific skills and interests

agree

> prefix I proposed might not clearly fit in PA, and is not PI in the geo

not sure what do you mean by "PI in the geo sense"
current PI allocations are unrelated to geo-PI schemes, they are simply 
independent of any provider but not related to any geography

> wherever you are).
>  This is why I proposed to go back to IPv6 or IPv6Ops

this has no relationship at all with geo-PI

it is about allocating prefixes directly to end users of allocating 
them to providers so they can aggregate all the prefixes of their 
customers in a single bgp announcement.

In this case, it is a single end user that is requiring to burn a bgp 
slot, my question is why would them be allowed to do so? what are their 
special requirements that make other RO solutions not suitable for 
them, but yet suitable for the rest of the people? I am not saying that 
there is no such requirements, but if they are, i think they should be 
presented to the wg and discussed in order to figure out that there is 
no alternative solution, that does not imposes additional stress to the 
global routing tables, that would fulfill the requirements. That is 
why, imho the first step is to flesh out these special requirements... 
I mean it is really hard to determine if this si the only acceptable 
solution if we don't know what the requirements are...

> not a burden for the DFZ.

yes, right and there are really few people called Marcelo Bagnulo and 
this is not a valid reason for allocating a PI prefix to those who are 
called Marcelo Bagnulo.
The reason to define a solution that relies in the injection of PI 
prefixes in the global routing table is that there is no other solution 
that will be suitable for the requirements imposed. So again the first 
thing would be to agree in what the requirements are

> prefix as a sub-internet.

i may be fine with they bloating their internal routing tables, but i 
don't feel the same in the case of the global DFZ

> ongoing, somewhere else...

i am not claiming for PI and even less for geo PI
actually i am claiming for exactly the oposite, to avoid solutions that 
require PI addressing to work

> There was a strong requirement to make the phones unaware of RO. Some 

this is a good starting point for the requirements discussion

> words, a phone should only see the other phone's Home Address, not its

i think privacy considerations are an interesting issue and it deserves 
careful analysis, in particular, we need to understand what information 
is being protected and what information the user would like to hide 
(wee the work done in the ALIEN bof)... for instance in the case of 
global HAHA, the mobile node would be using this special prefix that is 
reserved to the airline, so it would be disclosing the fact that it is 
flying somewhere.
If PA addresses from the provider are used, it would only be disclosing 
that it is using a given provider (that depending on the area of 
coverage of the ISP may be bigger or smaller)

so, exactly what is what is what we are trying to hide?

> must occur centrally in the ISP side.

but this is true for almost any widespread deployed device... i mean 
this is true for hosts also... that is why protocols need to be defined 
in a way that they are extensible and allow future features in a 
backward compatible way

> whereas it saves resources globally.

exactly, that is why the scale so well, because no central resourses 
are required

>  When the first hop is a radio and

i agree that this is good in some cases, however, i think that it may 
be possible to design such a solution without requiring announcing 
routes globally

> particular, it is possible to push policies to the proxy, acting like a

yes, but e2e RO is similar to mipv6 RO, which is also an existent model 
that i guess people are starting to adopt.

fwiw, i think this is the type of discussion that is needed before 
deciding which type of RO solution is required

regards, marcelo

---

From: Masafumi Watari <[email-masked]>
Date: Fri, 14 Apr 2006 10:19:25 +0900

Hi,

>> are going to work on global haha or not...

The charter is still open for discussion :)  The only reason for Global
HAHA being mentioned in the charter I believe is because it's been
presented several times in different WGs, though originally it wasn't
about RO but more on HA redundancy I believe(local HAHA?).

> thinking that we can go ahead and move it forward. 

I don't know about the plenary, but in the sense that Global HAHA seems
deployable compared to other solution, I guess it is advanced.  But note
however that other RO solutions have not had their chance to present
their work because the WG was not chartered to work on it.

> As for ISP side, I'm copying Masafumi-san who co authored the NEMO RO

We are now migrating our network based on MMD and NGN, and within the
next two years all of our mobile and fixed network would be based on IP.
Once that's done, I would imagine that something like global HAHA would
be needed.  But if global HAHA is for NEMO and not MIP6, I don't see
a strong need at this point in time.

> must occur centrally in the ISP side.

It's also true that operators need to have control of their service too.

watari

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 18 Apr 2006 14:40:42 +0300

> about RO but more on HA redundancy I believe(local HAHA?).

My question is then:

what are the RO approaches that we want to include in the charter as 
work items?

By this, i don't mean what solutions we want to include, but what 
problems that require RO are we going to work on...
I can see the RO for globally moving networks is an important issue 
that seems to have a lot for interest, so i would suggest to include 
two items in the proposed charter:

- Defining the requirements for a RO approach for globally moving 
networks
- Propose a solution for globally moving networks

But are there any other RO scenarios that people have a need for?

Regards, marcelo

---

From: Masafumi Watari <[email-masked]>
Date: Thu, 20 Apr 2006 21:39:43 +0900

Hi Marcelo,

On 2006/04/18 20:40, marcelo bagnulo braun wrote:
> I can see the RO for globally moving networks is an important issue that 
> seems to have a lot for interest, so i would suggest to include two 
> items in the proposed charter:
> 
> - Defining the requirements for a RO approach for globally moving networks

When you say "Globally moving networks", it would potentially include
any NEMO, so I suggest we rephrase this, but I agree.

 > - Propose a solution for globally moving networks

Just curious. would this be HAHA based approach or something different?

BTW, I personally support the HAHA based approach, but I also agree that
draft-thubert has a BGP/routing scalability issue that it needs to
solve.

> But are there any other RO scenarios that people have a need for?

Well, there hasn't been much discussion on this and I don't know if
people have interest in it either.  I've seen this question a couple
of times, but nobody has spoken up.  One of the problem is that if you
take a look at the analysis draft, the problem of NEMO RO is that it is
quite complex.  There were comments that NEMO WG isn't the right place
to handle some solution, like MANEMO, while others think that we are too
early in stage to work on other scenarios.

watari

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 20 Apr 2006 15:58:51 +0300

> Just curious. would this be HAHA based approach or something different?

depends on the requirements we agree on i guess and whether alternative 
solutions can fulfill the requirements without burden on the global bgp 
table, i guess

> of times, but nobody has spoken up.

agree, nobody seems to care for the other cases so far

regards, marcelo

>   One of the problem is that if you

---

From: "Ben McCarthy" <[email-masked]>
Date: Thu, 20 Apr 2006 15:17:36 +0100

Hi all,

In relation to the topic of re-chartering, has the WG considered the
possibility of splitting the charter in two? With one charter concentrating
on researching the single roaming NEMO scenario and the other concentrating
on the Nested NEMO scenario? It seems to me from the work I've done that the
scenarios which require a single NEMO model (such as ITS) and those that may
require a Nested NEMO model are often (but admittedly not always) quite
distinct. 

With two separate charters the WG could focus on topics such as RO and
multihoming that are specifically suited to the two different scenarios,
rather than attempt to produce a one-fits-all solution. The later charter
could also conceptually house the MANEMO work as well possibly?

I am not particularly pushing my own agenda here, I just had this idea and
thought I'd push it out on the ML to see what other people think about it. 

Regards,

Ben

-----Original Message-----
From: marcelo bagnulo braun [mailto:[email-masked]] 
Sent: 20 April 2006 13:59
To: Masafumi Watari
Cc: ml-nemo WG
Subject: Re: RO approahces and the proposed charter (was Re: About
theproposed charter and global HAHA (was Re: [nemo] RE: Aboutroute
aggregation in global HAHA

regards, marcelo