Subject: RE: Impact of HAHA route injection (was Re: [nemo] My simple thoughts on HAHA)

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 23 Nov 2004 15:29:57 +0100

> >
> >
> > First, this does not need to create any new area nb into the DFZ.
> >
> > But if your question is about a potential fragmentation of the ISP
> > aggregation, then it's possible. WRT multi6, I'm not too sure it
> > compares. Depends on which home we are talking about. I wrote this
draft
> > with (4G VoIP capable) ISPs in mind, managing a Home Network as part
of
> > their services, as opposed to sites which would be given an address
> > block to make a Home of it. So that would not be the same order of
> > magnitude. They could partition that home into mobile address blocks
for
> > the corporate customers, but that's another story (eg, mobile home).
> >
> > An ISP would split its mobile and non mobile worlds, and they would
be
> > advertised separately. That could up-to double the size of the DFZ
> > tables. A non mobile aggregation would be advertised from its
location.
> > A mobile aggregation would be advertised from all of the owner SP
> > locations. BGP routers would keep the closest one anyway, as usual.
> > Maybe a checking on multipath operations here and there, but it
should
> > be OK.
> 
> Is my reading correct that the "doubling" of the size of the DFZ
tables
> would be due to the fact that mobile aggregation are advertised from
> multiple locations with HAHA?
> 
> In that case, I am still wondering whether HAHA, as a global route
> optimization solution, is worth such an impact on the DFZ.

Right. 

That would be if all the SPs split their networks to make a half mobile.
The key is that the non mobile part is not advertised the same way in
BGP then the mobile part. Whether it's worth it is not mine to judge.
Depends if SPs want to control/manage the mobility of their phones and
use an infrastructure based solution. And if so, and if the cost is not
affordable, we'll have to find an alternate to global HAHA. I think it's
at least a good exercise.

> 
> I can see HAHA as an interesting feature, as long as we are able to
> control its impact on the Internet as a whole. Such control seems easy
> if HAHA is deployed in a single site. It seems also doable to use HAHA
> between different sites that share the same ISP (so that MNP routes
> aggregate at this ISP, and does not go deeper in the Internet). On the
> other hand, IMHO, it is not possible to control the impact of HAHA
> "multiple route injection" if used between any site....with
potentially
> significant impact on the Internet routing tables.

Note that the multiple injections are for the ISP aggregations, not per
MNPs, right?
The impact of the mobility is hidden within one ISP "VPN". And that
could be on-demand (secondary bindings).

> 
> If the above is correct (please correct me if not :) then it seems
> important IMHO to explicitly list such issues in the draft, and
> recommend the use of HAHA only in specific / well-controlled
> environments. A technical solution preventing any mis-usage of HAHA
> could also be needed.
> 

Right. HAHA and global in particular are going deep in hopes and
consequences. Being fully L3 is a major step. It's way beyond the
current charter of NEMO. If a WG is formed that takes it, I'm sure it
will require more then one doc to cover it and usage applicability will
be key.

> > The way I see it (but I'm not network architect):
> >
> > BGP should be configured to filter out mobile routes if they are
> > injected by proxies on behalf of partner ISPs. So if ISP B proxies
for
> > ISP A, B's proxy HAs will inject A's mobile aggregation into B's AS
-
> > and reciprocally A will do the same for B. But those routes will not
> > leak into eBGP.
> 
> 
> If the mobile routes for ISP-A (e.g. MNP-A) does not leak into ISP-B's
> eBGP, then only one route for MNP-A will be exposed in the Internet
> (i.e. towards ISP-A), which is fine.
> 
> On the other hand, because of that, it seems to me that all packets
from
> any CN in the Internet (but CNs in ISP-B) will reach A's HA. While
only
> CNs in ISP-B will reach B's HA proxying the MNP-A. Thus HAHA RO
> capability is only enabled for CN-in-ISP-B, but not for all nodes in
the
> Internet. Right?

The idea would be that the proxies can RO using a route projection. So
if CN_X has a proxy that is trusted by ISP A then a proxy for MR_A can
establish RO with CN_X. If I understand well your case, the problem you
are evoking is more like when MR_A is roaming into domain_X. In which
case it will not find a proxy locally.

> I am asking this just to make sure my understanding is correct, I
don't
> think such "restricted" RO support is an issue since it is possible
that
> (in specific deployement scenarios) one want to enable RO only for a
> certain set of CNs (e.g. CN-in-ISP-B) but not for all of them.
> 
> 
Agreed. Note that in the case of voice, many providers ended up with
cross-agreements :)

Pascal