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

["Pascal Thubert \(pthubert\)" <[e-mail]>]

>> Global HAHA, which covers the RO within the infrastructure, is well
>> 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...

[Pascal] An informational draft would be enough, then. Do you have an
example?

Now, go through the MLs (at least NEMO and MONAMI) and you'll find the
numerous discussions on global HAHA. AFAIR, it was also discussed at all
IETFs meetings for at least 4/5 sessions - chair help please. This makes
it well advanced and explains its advanced position.


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

[Pascal] It was presented at the IETF plenary as something wanted. Was
that IETF 62 or 63?


>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....
 
[Pascal] Please browse the global HAHA draft. You will not find a
mention of PI. 

With global HAHA, only the most aggregated prefix appears in the DFZ
(like a PA). And since it is in the best interest of ISPs to form a
single (or a minimum set of competing) consortium, then ideally you end
up with a single prefix.

I thought you agreed on that considering your answer to Keiichi-san.


>
>> 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.
>>
>
>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?
>
[Pascal] Please browse TJ's proposed charter:
<snip>
Mar 2006	  	Submit final doc(s) on Analysis of the Solution
Space for Route Optimization
<snap>
Mar 2007	  	Shut down or recharter the WG to solve further
identified topics




>>
>> 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.
>>
>
>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
>
[Pascal] I might be misinformed but last I checked, IPv4 type PI was not
an accepted model in IPv6 and you have to trick to get something
equivalent, proving that you interface with a number of other ISPs. 

My reference about geographic PI addresses is:
http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-09.txt 


>> 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.
>
>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.
>
[Pascal] The prefix of the phone (Mobile Router) is obtained from its
ISP. 
It can be expected that it comes from a subnet that the ISP allocated to
a region where the user lives. In turn, that subnet part of the share
that this ISP got from the mobile prefix of the consortium, which is the
only entry in the DFZ for the whole thing. 

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

[Pascal] Well, I tried to interrupt that discussion which was creating
its own problems and then could not solve them, by giving an example of
what a mobile prefix could be. 

>
>>
>> In any fashion, if there are few large consortiums, then this is
surely
>> 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
>
[Pascal] sorry, we are completely off sync. Global HAHA is not injecting
Marcelo into the internet. 

The requirement imposed is to advertise a short prefix from multiple
points in the internet. That does not mean PI, does it? The traditional
problem with PI is that the prefix for every site (every corp and so on)
ends up in the DFZ, causing an explosion of the BGP tables of the core.
>From reading Tony's draft, you might realize that this is not
necessarily true anymore.

Now, If there were only a handful of prefixes, even if you rated them PI
for some semantic reason, that would not be an issue. Global HAHA is
designed for a handful of short prefixes injected ubiquitously into the
Internet. Any of the global HAHA POPs is an entry to a sub-internet
where another routing hierarchy takes place, like within a VPN.

MIP proxy HAs, located at the POP, enable POP to POP RO, and the routing
between the POPs takes place within the internal network, which is a
mesh of private lines and tunnels.

Pascal