Multihoming - Resilience or Independence

Hi,
The customer will of course use 2 ISP - as requested. He will use addresses
coming from a single PA block advertised by two providers. Of course you
need to ensure 100% up connection between border routers. If connection
between border routers is down one of them has to stop advertising PA block.
Otherwise you have problem with return traffic. Imagine provider B lost
connection to both customer and provider A. If B is still advertising common
block some ASes may decide to reach customer over B, but B cannot reach
customer network... In order to deliver proposed service providers A and B
have to be connected with redundant network, which is quite common. 

Vicious circle (sp) as I see it:
*Providers want small routing tables
*Customers 100% up service so they as for resilience
*Providers usually have single POP in area
*Customers go BGP creating problem for community (table grows) and
themselves (BGP expert costs)

Solution: 
Providers enter into cooperation so they can advertise customer addresses
over 2 independent BGP speakers. This idea is not very different from
existing aggregation. Specific routing information is hidden in a group of
ASes instead of single AS. Of course you need some administrative effort
(e.g. consistent billing) but from technical point of view it seems
feasible. I may be wrong, it won't be for the first time ;-)
Regards,
Jacek


-----Original Message-----
From: Lu, Ping [mailto:PLu at cw.net]
Sent: Thursday, October 11, 2001 5:02 PM
To: 'BLOCKI,JACEK (HP-Poland,ex1)'; lir-wg at ripe.net; routing-wg at ripe.net
Subject: RE: Multihoming - Resilience or Independence



> -----Original Message-----
> From: BLOCKI,JACEK (HP-Poland,ex1) [mailto:jacek_blocki at hp.com]
> Sent: Wednesday, October 10, 2001 1:10 PM
> To: lir-wg at ripe.net; routing-wg at ripe.net
> Subject: RE: Multihoming - Resilience or Independence
> 
> 
> Hi,
> It seems multihoming discussion is an example of vicious 
> circle (sp): More
> specific routes result in larger routing table but we want 
> those routes and
> small table... Let me suggest a blasphemy: CIDR being 
> advertised from two
> ASes. They say it should be only one, but why? In my opinion there is
> nothing wrong in advertising CIDR from two ASes as long as 
> you can guarantee
> each border router advertises CIDR only if it can reach it. 
> Imagine the
> following construction:
> AS-A--\
>           +(OSPF) --(CIDR)
> AS-B--/
> 

That's the problem. When customer want to be muitl-homed you can't tell them
to use which ISP ? If the original prefix are not in the CIDR with the other
ISP
then the customer have to change all their IP address. If they don't then
the second
ISP have to leak the original prefix into global routing table.

The question is how do you convince your customer to change all their IP
addresses to
have a second link without the risk of losing its business ? 


> Each BGP speaker advertises CIDR if and only if it learned 
> about it from
> OSPF. It can be done, if you don't know how I'll forward you a working
> example. Each border router generates a default router and 
> injects it into
> OSPF. From technical point of view I see no reasons why it 
> should not work.
> What you need is:
> * An agreement between ISPs
> * Change in procedure making such a union of ASes an 
> officially blessed
> solution so nobody would dare to hinder cooperation with filters.
> * Optionally you may need a separate CIDR, since both ASes 
> have to advertise
> same prefix. You need it if each ISP wants to have private 
> customers in
> addition to shared ones.
> 
> The customer has "an independent connection to two ISPs" 
> which is the quest
> item. I see more commercial than technical problems with such 
> a solution.
> However my expertise is limited and somebody can point 
> drawbacks I cannot
> see. Feel free to burn me on a stake, that's the right way of 
> treating a
> blasphemy ;-)
> Regards,
> Jacek
>

It is a good idea but not easy to implement under the pressure of making
revenue.


Ping Lu
Cable & Wireless USA
Network Tools and Analysis Group
W: +1-703-292-2359
E: plu at cw.net