[arin-ppml] Rationale for /22

[Kevin Kargel]

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Tuesday, July 28, 2009 7:16 PM
> To: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> On Tue, Jul 28, 2009 at 1:46 PM, Kevin Kargel<kkargel at polartel.com> wrote:
> >> AFAIK, there are no ISPs allowing customers to multihome with less
> >> than a /24 currently but many who are allowing those /24s.  So if that
> >> Org gets a /24 from ARIN or a /24 from it's ISP, there is the same 1
> >> entry in the table.
> >
> > This is incorrect.  If the Org gets a /24 from it's upstream ISP there
> is
> > the same entry in the routing table.  If the Org gets a discontiguous
> /24
> > from ARIN there is an additional entry in the routing table.
> 
> Kevin,
> 
> For the multihomed case we're discussing, this statement is in error.
> In order to aggregate small routes into a larger route, two things
> must be true:
> 
> 1. The covered address space must be contiguous in a netmasky way
> 2. The network topologies for the two routes must be the same. That
> is, the entrances from "the Internet" must be the same for both
> routes.
> 
> In the multivendor multihomed case, each of the customers ISPs
> connects to the rest of the Internet differently. The network topology
> for the multihomed customer generally differs from the network
> topology of any of the ISPs serving the customer. As a result, his
> route is not aggregable.
> 

I don't remember a topology discriminator in the BGP algorithm.  I have dual
homed customers who use IP's from me.  When I advertise those out my BGP
portal they are aggregated.  

For example if I advertise 66.231.96.0/19 in my BGP and I have allocated
66.231.103.0/23 to one of my customers his network will be aggregated to be
within my BGP advertisements without adding a specific route.

Of course there is no way the ISP on the other side of the customer can
aggregate, hence my statement that it would inject one additional route to
the routing table upstream from my customers peers.

For my customers that have their own portable IP's, those are not agregable
by my BGP nor by the BGP on the far side of the customer.  Those IP's inject
two new routes in the tables outside of the customers peers.

For example, if my BGP has a network statement for 66.231.96.0/19 and my
customer has an IP of 66.231.128.1/24 , even though it is contiguous it will
not be aggregated.  It does not fall within my network and it does not
extend to a CIDR boundary contiguous to my network.  If I choose to
advertise via BGP to transit traffic for them  the customers IP will be
advertised as a separate network with a discrete route entry.




> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090729/5564b4a6/attachment.bin>