Subject: RE: [nemo] My simple thoughts on HAHA

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 19 Nov 2004 17:31:40 +0100

> -----Original Message-----
> From: Christophe Janneteau [mailto:[email-masked]]
> Sent: vendredi 19 novembre 2004 15:47
> To: Pascal Thubert (pthubert)
> Cc: Ryuji Wakikawa; [email-masked]; Alexandru Petrescu
> Subject: Re: [nemo] My simple thoughts on HAHA
> 
> Pascal,
> 
> Please read below....
> 
> Pascal Thubert (pthubert) wrote:
> >
> >> -----Original Message----- From: Christophe Janneteau
> >> [mailto:[email-masked]] Sent: vendredi 19
> >> novembre 2004 11:02 To: Pascal Thubert (pthubert); Ryuji Wakikawa;
> >> [email-masked] Cc: Alexandru Petrescu Subject: Re: [nemo] My simple
> >> thoughts on HAHA
> >>
> >> Ryuji, Pascal, Alex,
> >>
> >> Sorry to jump into the discussion....
> >>
> >> Pascal Thubert (pthubert) wrote:
> >>
> >>> The draft says that the CN reaches Home via the closest point of
> >>> presence, so if CN does not move, then this does not change. MR
> >
> > keeps
> >
> >>> its MNP, and the MNP information is distributed by a routing
> >
> > protocol
> >
> >>> over a mesh of tunnels between HAs. The CN is not supposed to see
> >>>
> >
> > the MR
> >
> >>> HoA (it's just a binding ID), unless it is formed from the MNP.
> >>> The whole concept of Home link is gone.
> >>
> >> In my understanding of HAHA, several HAs will annouce a route in an
> >>  _internetwork_ to the same MNP. The packet sent by CN (addressed
> >> to a node of MNP) will reach the closest HA (e.g. HA annoucing MNP
> >> with the smallest metric). And HA will tunnel the packet to MR.
> >> Correct?
> >>
> >> Now the question is: what type of internetwork are we talking
> >> about? 1- The global Internet?, or 2- Only a site? in which case
> >> all HA would belong to the same site,
> >
> > and
> >
> >> there would be only one route advertised from the site gateway to
> >> the Internet.
> >>
> >> I think 1 would be an issue, especially for IPv6 (see multi6 work).
> >>
> >
> > No?
> >
> > Could you please elaborate?
> 
> In case 1, several HAs in _different_ sites would announce a route for
> the same MNP in the Internet, possibly up to the default free zone
> (DFZ). When the number of MNPs announced in this way in the DFZ
becomes
> large, the DFZ becomes overloaded with these routes (scalability
issues).
> 
> While it seems that such route injection in the DFZ is a common
approach
> in IPv4 to support multi-homing, it is also desirable to find more
> scalable ways to support multi-homing in IPv6. This is what the multi6
> WG is working on AFAIK. The charter provides a good description of the
> issue.
> 
> In my understanding the HAHA approach in case 1 would rely on the fact
> that (as for IPv4) route injection in the DFZ is possible. But this
may
> not be the recommended approach for IPv6 however.
> 
> What do you think?

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.

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.

So A and B do not have agreements, then the nearest reachable proxy for
a MR from A within B's AS will be in the closest of A's ASes.

Pascal

---

From: Christophe Janneteau <[email-masked]>
Date: Mon, 22 Nov 2004 11:39:17 +0100

Hi Pascal,

Thanks a lot for your fast and detailed answer :)

Below are some additional comments/questions...

> Maybe a checking on multipath operations here and there, but it should

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.

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.

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.

> and reciprocally A will do the same for B. But those routes will not

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?

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.

Thanks,
Christophe.