RE: FW: /8s and filtering
Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. -ej -----Original Message----- From: N [mailto:nathan@stonekitty.net] Sent: Tuesday, December 10, 2002 1:01 PM To: Forrest Cc: nanog@merit.edu Subject: Re: FW: /8s and filtering comments inline On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote:
I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which
has an
allocation from the Class C space rather than one from the Class A space.
It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route.
Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their
ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate.
For the assigned block to be part of the same aggregate(of both providers), that implys that the providers sharing the responsibility for the aggregate. It happens, but is rare. In this case, the providers must accept more specific routes from each other, that is within the space being aggregated. If they do not share specifics, one uplink down will cause a large percentage ~50% for the customer. This scenario is valid for load balancing, but redundancy is fragile. The only advantage I see is no limit to prefix length. You can do this with a /28 if you want... given the above caveats are addressed.
If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong?
In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries.
What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from.
There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks. -- ,N ~Nathan - routing & switching dude/fly-boy/sport biker - San Jose CA~
Hello, No, this is not the case. I enquired and it seems multihoming is not a justification for a /24 in any RIR. Does a network have to be able to fully utilize a /26 (25% of /24) in order to multihome? Harsha. On Tue, 10 Dec 2002, Ejay Hire wrote:
Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24.
-ej
-----Original Message----- From: N [mailto:nathan@stonekitty.net] Sent: Tuesday, December 10, 2002 1:01 PM To: Forrest Cc: nanog@merit.edu Subject: Re: FW: /8s and filtering
comments inline
On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote:
I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which
has an
allocation from the Class C space rather than one from the Class A space.
It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route.
Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their
ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate.
For the assigned block to be part of the same aggregate(of both providers), that implys that the providers sharing the responsibility for the aggregate. It happens, but is rare. In this case, the providers must accept more specific routes from each other, that is within the space being aggregated. If they do not share specifics, one uplink down will cause a large percentage ~50% for the customer. This scenario is valid for load balancing, but redundancy is fragile. The only advantage I see is no limit to prefix length. You can do this with a /28 if you want... given the above caveats are addressed.
If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong?
In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries.
What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from.
There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks.
-- ,N
~Nathan - routing & switching dude/fly-boy/sport biker - San Jose CA~
many isps will automatically give a /24 if their client is multihoming, even if their usage is well below the 254 usable ips allocated by the above block size. Brian On Tue, 10 Dec 2002, Harsha Narayan wrote:
Hello, No, this is not the case. I enquired and it seems multihoming is not a justification for a /24 in any RIR.
Does a network have to be able to fully utilize a /26 (25% of /24) in order to multihome?
Harsha.
On Tue, 10 Dec 2002, Ejay Hire wrote:
Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24.
-ej
-----Original Message----- From: N [mailto:nathan@stonekitty.net] Sent: Tuesday, December 10, 2002 1:01 PM To: Forrest Cc: nanog@merit.edu Subject: Re: FW: /8s and filtering
comments inline
On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote:
I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which
has an
allocation from the Class C space rather than one from the Class A space.
It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route.
Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their
ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate.
For the assigned block to be part of the same aggregate(of both providers), that implys that the providers sharing the responsibility for the aggregate. It happens, but is rare. In this case, the providers must accept more specific routes from each other, that is within the space being aggregated. If they do not share specifics, one uplink down will cause a large percentage ~50% for the customer. This scenario is valid for load balancing, but redundancy is fragile. The only advantage I see is no limit to prefix length. You can do this with a /28 if you want... given the above caveats are addressed.
If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong?
In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries.
What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from.
There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks.
-- ,N
~Nathan - routing & switching dude/fly-boy/sport biker - San Jose CA~
Hello, But how will such an ISP justify this to the RIR? Thanks, Harsha. On Tue, 10 Dec 2002, Brian wrote:
many isps will automatically give a /24 if their client is multihoming, even if their usage is well below the 254 usable ips allocated by the above block size.
Brian
On Tue, 10 Dec 2002, Harsha Narayan wrote:
Hello, No, this is not the case. I enquired and it seems multihoming is not a justification for a /24 in any RIR.
Does a network have to be able to fully utilize a /26 (25% of /24) in order to multihome?
Harsha.
On Tue, 10 Dec 2002, Ejay Hire wrote:
Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24.
-ej
-----Original Message----- From: N [mailto:nathan@stonekitty.net] Sent: Tuesday, December 10, 2002 1:01 PM To: Forrest Cc: nanog@merit.edu Subject: Re: FW: /8s and filtering
comments inline
On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote:
I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which
has an
allocation from the Class C space rather than one from the Class A space.
It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route.
Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their
ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate.
For the assigned block to be part of the same aggregate(of both providers), that implys that the providers sharing the responsibility for the aggregate. It happens, but is rare. In this case, the providers must accept more specific routes from each other, that is within the space being aggregated. If they do not share specifics, one uplink down will cause a large percentage ~50% for the customer. This scenario is valid for load balancing, but redundancy is fragile. The only advantage I see is no limit to prefix length. You can do this with a /28 if you want... given the above caveats are addressed.
If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong?
In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries.
What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from.
There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks.
-- ,N
~Nathan - routing & switching dude/fly-boy/sport biker - San Jose CA~
Isn't it true that most bgp announcements with a mask longer than 24 bits hit the proverbial bit bucket? Brian On Tue, 10 Dec 2002, Harsha Narayan wrote:
Hello, But how will such an ISP justify this to the RIR?
Thanks, Harsha.
On Tue, 10 Dec 2002, Brian wrote:
many isps will automatically give a /24 if their client is multihoming, even if their usage is well below the 254 usable ips allocated by the above block size.
Brian
On Tue, 10 Dec 2002, Harsha Narayan wrote:
Hello, No, this is not the case. I enquired and it seems multihoming is not a justification for a /24 in any RIR.
Does a network have to be able to fully utilize a /26 (25% of /24) in order to multihome?
Harsha.
On Tue, 10 Dec 2002, Ejay Hire wrote:
Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24.
-ej
-----Original Message----- From: N [mailto:nathan@stonekitty.net] Sent: Tuesday, December 10, 2002 1:01 PM To: Forrest Cc: nanog@merit.edu Subject: Re: FW: /8s and filtering
comments inline
On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote:
>I was also curious about this - if I am a customer who wants to >multihome and can justify only a /24, I would go to an ISP which
has an
>allocation from the Class C space rather than one from the Class A >space.
It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route.
Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their
ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate.
For the assigned block to be part of the same aggregate(of both providers), that implys that the providers sharing the responsibility for the aggregate. It happens, but is rare. In this case, the providers must accept more specific routes from each other, that is within the space being aggregated. If they do not share specifics, one uplink down will cause a large percentage ~50% for the customer. This scenario is valid for load balancing, but redundancy is fragile. The only advantage I see is no limit to prefix length. You can do this with a /28 if you want... given the above caveats are addressed.
If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong?
In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries.
What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from.
There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks.
-- ,N
~Nathan - routing & switching dude/fly-boy/sport biker - San Jose CA~
Hello, No, this is not the case. I enquired and it seems multihoming is not a justification for a /24 in any RIR.
Does a network have to be able to fully utilize a /26 (25% of /24) in order to multihome?
Harsha.
You do err, not knowing the scripture. To multihome, you need to get (at least) two other providers to listen to your routing announcement(s). Wango'z'tango! multihoming done. Your announcement can be as small as a /32 (although there was a time when at least one /33 was delegated...) What's that? you want everyone running IP to reach your gopher server? Tough luck. then you must somehow meet/pass the byzantine filtering rules (unpublished sometimes) that parties which are three and four hops away from your edge will impose on whatever announcements you happen to propogate. The dead hand of the CIDR mafia will eat your lunch and you'll have no recourse. So, whats a poor'lil player todo? Some say that this works: ) build a rich peering mesh. (reduces your dependence on any one transit provider) ) buy transit (where you -MUST-) and insist that you understand BGP, peering, and how to prevent leakage. Demand that they accept your announcement(s). [ note that this may turn transit into peering, which may trigger other unpleasent SOPs from the salesdroids but hey, multihoming is -worth- the effort...] as usual, YMMV. --bill (who is earning the sobriquet "grumpy" today)
--On Tuesday, December 10, 2002 13:08 -0600 Ejay Hire <ejay.hire@isdn.net> wrote:
Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24.
I am not aware of ARIN taking such action. To which policy are you referring? Alec, ARIN AC member -- Alec H. Peterson -- ahp@hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com
--On Tuesday, December 10, 2002 13:08 -0600 Ejay Hire <ejay.hire@isdn.net> wrote:
Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24.
I was thinking about PI space. ARIN did in fact ratify a policy stating that a provider may allocate a customer a /24 of PA space if they are multihomed. Alec, red-faced AC member -- Alec H. Peterson -- ahp@hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com
Hello, The policy says that a /24 of PA space can be given if the customer can show that it has an immediate requirement of 25% of the /24 = /26. That is the reason I asked if the multihomer has to be able to fully utilize a /26=25% of /24 to be able to multihome. Thanks, Harsha. On Tue, 10 Dec 2002, Alec H. Peterson wrote:
--On Tuesday, December 10, 2002 13:08 -0600 Ejay Hire <ejay.hire@isdn.net> wrote:
Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24.
I was thinking about PI space. ARIN did in fact ratify a policy stating that a provider may allocate a customer a /24 of PA space if they are multihomed.
Alec, red-faced AC member
-- Alec H. Peterson -- ahp@hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com
--On Tuesday, December 10, 2002 11:41 -0800 Harsha Narayan <hnarayan@cs.ucsd.edu> wrote:
Hello, The policy says that a /24 of PA space can be given if the customer can show that it has an immediate requirement of 25% of the /24 = /26.
Policy 2001-2 was ratified recently, which is separate and says that if the customer is multihomed he may receive a /24 with multihoming being the only justification. Alec -- Alec H. Peterson -- ahp@hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com
My original question was how does this interact with the filtering policies - especially when the Class C space is used up - there are only three /8s left there. Harsha. On Tue, 10 Dec 2002, Alec H. Peterson wrote:
--On Tuesday, December 10, 2002 11:41 -0800 Harsha Narayan <hnarayan@cs.ucsd.edu> wrote:
Hello, The policy says that a /24 of PA space can be given if the customer can show that it has an immediate requirement of 25% of the /24 = /26.
Policy 2001-2 was ratified recently, which is separate and says that if the customer is multihomed he may receive a /24 with multihoming being the only justification.
Alec
-- Alec H. Peterson -- ahp@hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com
Did they ? When ? (I was involved with such a proposal, and it was turned down at the last ARIN meeting, so I am curious if something else did get approved.) Regards Marshall Eubanks On Tuesday, December 10, 2002, at 02:08 PM, Ejay Hire wrote:
Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24.
-ej
-----Original Message----- From: N [mailto:nathan@stonekitty.net] Sent: Tuesday, December 10, 2002 1:01 PM To: Forrest Cc: nanog@merit.edu Subject: Re: FW: /8s and filtering
comments inline
On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote:
I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which
has an
allocation from the Class C space rather than one from the Class A space.
It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route.
Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their
ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate.
For the assigned block to be part of the same aggregate(of both providers), that implys that the providers sharing the responsibility for the aggregate. It happens, but is rare. In this case, the providers must accept more specific routes from each other, that is within the space being aggregated. If they do not share specifics, one uplink down will cause a large percentage ~50% for the customer. This scenario is valid for load balancing, but redundancy is fragile. The only advantage I see is no limit to prefix length. You can do this with a /28 if you want... given the above caveats are addressed.
If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong?
In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries.
What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from.
There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks.
-- ,N
~Nathan - routing & switching dude/fly-boy/sport biker - San Jose CA~
T.M. Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html
participants (6)
-
Alec H. Peterson -
bmanning＠vacation.karoshi.com -
Brian -
Ejay Hire -
Harsha Narayan -
Marshall Eubanks