Dear all, The first draft of the IPv4 and ASN policy document is now available on-line at: http://www.ripe.net/rs/ipv4policy.html It is available as html and can also be downloaded in .txt format. This document is currently under revision as an editorial team is being assembled to provide input on this draft. If you are interested in participating in the editorial team, please contact the LIR-WG chair, Hans-Petter Holen <hph@online.no> or indicate your interest on this list. Kind regards, Nurani Nimpuno RIPE NCC
At 11:21 21/09/01 +0200, Nurani Nimpuno wrote: I would like to discuss section 5.5 AS numbers. 1) No mention is made if an organization ceases to be multihomed. I think any organization that ceases to be multihomed has to return the ASN after a certain period of time - say 2 months. 2) I think it needs to be specifically stated that the two upstream ISPs must announce the ASN via BGP and must make that announcement to either the global Internet or to a well recognized exchange point. 3) The organization receiving the ASN is responsible for maintaining an up to date aut-num object in RIPE as well as creating route objects for all assigning prefixes with the stated ASN origin. -Hank
Dear all,
The first draft of the IPv4 and ASN policy document is now available on-line at: http://www.ripe.net/rs/ipv4policy.html
It is available as html and can also be downloaded in .txt format.
This document is currently under revision as an editorial team is being assembled to provide input on this draft.
If you are interested in participating in the editorial team, please contact the LIR-WG chair, Hans-Petter Holen <hph@online.no> or indicate your interest on this list.
Kind regards,
Nurani Nimpuno RIPE NCC
2) I think it needs to be specifically stated that the two upstream ISPs must announce the ASN via BGP and must make that announcement to either the global Internet or to a well recognized exchange point.
does mean that one can not be multi-homed to two tier >=twos, neither of which is at an ix? well, reading differently, i guess i don't know what the global internet is when it needs to be differentiated from being at an ix. what are you getting at? i am misunderstanding the criteria. randy
On Mon, 24 Sep 2001, Randy Bush wrote:
2) I think it needs to be specifically stated that the two upstream ISPs must announce the ASN via BGP and must make that announcement to either the global Internet or to a well recognized exchange point.
does mean that one can not be multi-homed to two tier >=twos, neither of which is at an ix?
well, reading differently, i guess i don't know what the global internet is when it needs to be differentiated from being at an ix.
what are you getting at?i am misunderstanding the criteria.
I'll try to explain what I am getting at. Very often a newbie ISP doesn't quite understand what this is all about. They get an ASN cuz everyone else has one. Their upstream does static routing to them so rather than having their /19 show up as AS34567, it shows up as origin=AS11111 (their upstream). If I go the Oregon router server and look up their /19 and find only 1 path to that /19 or I find that the ASN origin has disappeared and been replaced by their upstream then there is no justification for getting an ASN.
randy
Hank
I'll try to explain what I am getting at. Very often a newbie ISP doesn't quite understand what this is all about. They get an ASN cuz everyone else has one. Their upstream does static routing to them so rather than having their /19 show up as AS34567, it shows up as origin=AS11111 (their upstream).
If I go the Oregon router server and look up their /19 and find only 1 path to that /19 or I find that the ASN origin has disappeared and been replaced by their upstream then there is no justification for getting an ASN.
understood the motivation. did not understand the mechanism. in arin-land, i think they actually ask to see proof of dual-homing before issuing the asn. but you want to TEST that it is actually deployed. what is not clear to me is HOW to do that. please take into account the problem of bgp best-path-only propagation. randy
On Mon, 24 Sep 2001, Randy Bush wrote:
I'll try to explain what I am getting at.Very often a newbie ISP doesn't quite understand what this is all about.They get an ASN cuz everyone else has one.Their upstream does static routing to them so rather than having their /19 show upas AS34567, it shows up as origin=AS11111 (their upstream).
If I go the Oregon router server and look up their /19 and find only 1 path to that /19 or I find that the ASN origin has disappeared and been replaced by their upstream then there is no justification for getting an ASN.
understood the motivation.did not understand the mechanism.
in arin-land, i think they actually ask to see proof of dual-homing before issuing the asn.but you want to TEST that it is actually deployed.what is not clear to me is HOW to do that.please take into account the problem of bgp best-path-only propagation.
I do the same in RIPEland as well. BGP best-path-only does put a crimp in the works which is why one needs to check a few public route servers. I cycle thru all multihomers (that I have allocated) every few months and check 3-4 large route servers or LGs and see who doesn't show up at all (went bellyup) or has only 1 path (dropped the 2nd due to economic downturn).
randy
Hank Nussbacher
in arin-land, i think they actually ask to see proof of dual-homing before issuing the asn.but you want to TEST that it is actually deployed.what is not clear to me is HOW to do that.please take into account the problem of bgp best-path-only propagation. I do the same in RIPEland as well. BGP best-path-only does put a crimp in the works which is why one needs to check a few public route servers. I cycle thru all multihomers (that I have allocated) every few months and check 3-4 large route servers or LGs and see who doesn't show up at all (went bellyup) or has only 1 path (dropped the 2nd due to economic downturn).
expecting an ec-style bureaucracy (<g>) to do something like that seems unreasonable. what if one link is down for a day or a week (should a metric week have ten days?:-)? i suspect this is among the reasons the rirs use more administrative tests. all in all, it's a pain. randy
At 09:51 24/09/01 -0700, Randy Bush wrote:
in arin-land, i think they actually ask to see proof of dual-homing before issuing the asn.but you want to TEST that it is actually deployed.what is not clear to me is HOW to do that.please take into account the problem of bgp best-path-only propagation. I do the same in RIPEland as well. BGP best-path-only does put a crimp in the works which is why one needs to check a few public route servers. I cycle thru all multihomers (that I have allocated) every few months and check 3-4 large route servers or LGs and see who doesn't show up at all (went bellyup) or has only 1 path (dropped the 2nd due to economic downturn).
expecting an ec-style bureaucracy (<g>) to do something like that seems unreasonable. what if one link is down for a day or a week (should a metric week have ten days?:-)? i suspect this is among the reasons the rirs use more administrative tests. all in all, it's a pain.
One can't be too strict. I give them 2 months to fix. Then they get another email. Still not fixed - then they a registered postal letter. Of the 70 ASNs I have allocated since 1996, I have revoked 10 (and returned to the RIPE pool), 5 of which were this year. Its a pain, but unless ear LIR does it, then we will end up with the same problem we have with IPv4 address space. -Hank
randy
expecting an ec-style bureaucracy (<g>) to do something like that seems unreasonable. what if one link is down for a day or a week (should a metric week have ten days?:-)? i suspect this is among the reasons the rirs use more administrative tests. all in all, it's a pain. One can't be too strict. I give them 2 months to fix. Then they get another email. Still not fixed - then they a registered postal letter. Of the 70 ASNs I have allocated since 1996, I have revoked 10 (and returned to the RIPE pool), 5 of which were this year. Its a pain, but unless ear LIR does it, then we will end up with the same problem we have with IPv4 address space.
i applaud your efforts and the results. randy
Dear Nurani, Thanx for the update, though one question: What happened to the "Permanently and Temporarily online" policy of '99 as in Paulas mail to the list - http://www.ripe.net/ripe/mail-archives/lir-wg/19990101-19990401/msg00045.htm... ? Seems to be missing in the new policy text. Kindly Per On Fri, 21 Sep 2001, Nurani Nimpuno wrote:
Dear all,
The first draft of the IPv4 and ASN policy document is now available on-line at: http://www.ripe.net/rs/ipv4policy.html
It is available as html and can also be downloaded in .txt format.
This document is currently under revision as an editorial team is being assembled to provide input on this draft.
If you are interested in participating in the editorial team, please contact the LIR-WG chair, Hans-Petter Holen <hph@online.no> or indicate your interest on this list.
Kind regards,
Nurani Nimpuno RIPE NCC
-- Per DNS/IP Registry - - - - - - - - - Swedish IP Network - - - - - - - - - Tele2AB/Swipnet e-mail: per@swip.net Box 62 direct: +46 8 5626 4579 164 94 KISTA gsm: +46 704 26 4579 Sweden fax: +46 8 5626 4210
In the past I was confused about RIPEs standpoint on assignment of PA space to users that are going to be running BGP and be dual homed. I think it would be good to include something in the document that I read on the list before if this is a acceptable assignment practice. Below is part of an email from Nurani Nimpuno on 03 Aug 2001. "However, it is also possible to multi-home by having a PA address range announced through two providers. If the PA addresses come from ISP A's allocation, the customer would have to agree with ISP B to announce that range separately. ISP A would also have to announce the range as a more specific route together with their aggregate." Thanks, Keith Johnson Network Engineer WorldCom Joan Muyskenweg 22 1096CJ Amsterdam, NL Fri, Sep 21, 2001 at 11:21:34AM +0200, Quoting Nurani Nimpuno (nurani@ripe.net):
Dear all,
The first draft of the IPv4 and ASN policy document is now available on-line at: http://www.ripe.net/rs/ipv4policy.html
It is available as html and can also be downloaded in .txt format.
This document is currently under revision as an editorial team is being assembled to provide input on this draft.
If you are interested in participating in the editorial team, please contact the LIR-WG chair, Hans-Petter Holen <hph@online.no> or indicate your interest on this list.
Kind regards,
Nurani Nimpuno RIPE NCC
participants (5)
-
Hank Nussbacher -
Keith Johnson -
Nurani Nimpuno -
Per Lundberg -
Randy Bush