At 12:25 -0400 7/24/97, Jan Novak wrote:
Nice lecture, thanks. But I saw always when thinking about multihoming some other problems also.
In the taxonomy I proposed, I tried to stay at the level of the customer requirement, rather than the specific details of addressability. The cases you cite are legitimate, but are in my mind at the next level of detail -- how one actually implements multihoming. I'll make some general comments. I need to think a bit whether these would be logically at a more detailed level of the taxonomy, or are in an implementation taxonomy of their own. Even beyond BGP capabiities (of either the enterprise or the ISP), your examples are going to be affected by the particular ISPs' (and their upstreams) aggregation and prefix filtering policies.
2] Multihomed to different ISP without BGP, supposing I need only one /24. It will be PA or PI addressing space ??
From the taxonomy standpoint, it could be either. Current registry
policies from RFC 2050 would generally say PA.
With respect to CIDR aggregation effort, make it sense to require /24 PI address block?? How will route the second ISP my PA from the other ISP (he will de-aggregate the block of the second provider to announce more specific prefix??) ??
2] Multihomed to different ISP with BGP , supposing I need only one /24. Again, make it sense to have my own AS and /24 PI block ??
Supposing to have IBGP to one ISP (to avoid assigning of independent AS) and EBGP to the second ISP, again will my router announce the /24 inside of the first ISP address block to the EBGP peer ??
Interesting approach. In general, the ISPs I know would be reluctant to run iBGP with a customer, unless they had total control of all BGP speakers. If I understand you correctly, the enterprise would have to tag its advertisements to the second ISP with the ASN of the first, since the enterprise doesn't have its own. Again, I think most ISPs would be reluctant to give up this amount of control.
2. Multi-homed. Enterprise connects to more than one ISP. May or may not use BGP. Wishes to protect against problems in the ISP routing system, and will accept additional complexity and router requirements to get this. May also have differing service agreements for Internet access for different divisions.