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 17:09:03 +0200

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

---

From: "Dul, Andrew L" <[email-masked]>
Date: Fri, 14 Apr 2006 12:30:22 -0700

> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:[email-masked]] 

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

I think people are referring to the presentation I made at IETF 62.  A
copy of the presentation was unfortunately omitted from the proceedings.
I've posted a copy here for people who are interested.
http://www.quark.net/docs/Global_IP_Mobility_IETF62.pdf  

The point of the presentation was to present the solution we had
deployed for ipv4 network mobility for our service and to spark
conversations about how network mobility might be done in the future. 

I've also recently written a whitepaper which describes our current
solution as well as some additional information.  I've attached a copy
to this message.

Andrew

---

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

> http://www.quark.net/docs/Global_IP_Mobility_IETF62.pdf

but this is not about globalHAHA at all, right?

I mean, i agree that providing support fro globally moving networks is 
a problem that needs to be addressed, but what i am missing here is the 
part when we actually define the problems, the requirements for the 
solution and consider different alternatives and then pick up a 
solution, which seems to me the way to solve problems...

however here it seems that we have a problem (so far i agree) and then 
just a single solution that can do the trick, without considering other 
alternatives, and not even properly defining the requirements for the 
solutions....

BTW, i think your paper and your presentation is a very good starting 
point for describing the problems and also the requirements, just that 
i would like to have this or other wg chartered to properly analyze the 
problem and anlyze different approaches to the problem at hand...

> conversations about how network mobility might be done in the future.

exactly this is the discussion that i would like to have

regards, marcelo

> <Global IP Network Mobility using Border Gateway Protocol.pdf>

---

From: "Dul, Andrew L" <[email-masked]>
Date: Tue, 18 Apr 2006 11:29:42 -0700

> From: marcelo bagnulo braun [mailto:[email-masked]] 
> >

yes, it is about our IPv4 current method of BGP route-injection.  

> I mean, i agree that providing support fro globally moving 
> networks is a problem that needs to be addressed, but what i 
> am missing here is the part when we actually define the 
> problems, the requirements for the solution and consider 
> different alternatives and then pick up a solution, which 
> seems to me the way to solve problems...

I guess there is a debate here about if we should be writing full
requirements documents before we actually start discussing and
designing.  I know there are two groups of people in the IETF regarding
this...  Some believe that writing full requirements documents first is
the best way, others think that they slow things down and you don't
necessarily come out with better results.

I think I am somewhere in the middle.  

I know Terry was working on a basic set of requirements for aircraft at
one point.  I'll have to ask him how that is going.

> 
> however here it seems that we have a problem (so far i agree) 
> and then just a single solution that can do the trick, 
> without considering other alternatives, and not even properly 
> defining the requirements for the solutions....
> 
> BTW, i think your paper and your presentation is a very good 
> starting point for describing the problems and also the 
> requirements, just that i would like to have this or other wg 
> chartered to properly analyze the problem and anlyze 
> different approaches to the problem at hand...
> 
> 

I think we are already having this discussion.  I think we have already
talked about the limitations of route-injection as well as clarifying
the operating models of global-HAHA.   

Andrew

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 19 Apr 2006 00:14:45 +0300

> I think I am somewhere in the middle.

i feel somehow the same way, but in this particular case, i think that 
we are dealing with a delicate and critical issues i.e. the scaling of 
the global routing table

If we are going to design a solution that contribute with additional 
routes in the dfz i would like to make sure that we are doing this 
because there is no other (more scalable) way of doing this.

The only way i can see to determine that this is the case is to figure 
out the requirements, look for alternative solutions and come to the 
conclusion that injection additional routes in the dfz is the way to go 
to provide an acceptable solutions.

I don't want to delay the process, and i think you have pretty much 
clear ideas about the requirements. After all you have a solution 
working right now and what the features and the problems are in this 
solution

i am willing to work on this if you need help

> one point.  I'll have to ask him how that is going.

that would be interesting indeed

regards, marcelo

---

From: "T.J. Kniveton" <[email-masked]>
Date: Fri, 21 Apr 2006 02:51:50 -0700

> copy of the presentation was unfortunately omitted from the  

Sorry it never made it to the proceedings, and I couldn't find a copy  
of it locally, so thanks for reposting. I put it on the NEMO IETF62  
slides web page at:

http://www.mobilenetworks.org/nemo/ietf62/nemo-ietf62-global-mobility- 
bgp.pdf