Dear Colleagues, Within the RIPE community the AS policy (ripe-245) is based upon RFC 1930. The RIPE policy states that "a network [is required] to be multihomed for an AS number to be assigned". However, there is no clear policy on returning unused AS numbers to the pool. We would be grateful if the community would clarify the policy so that it is clear when an unused AS number should be returned to the pool. Specific questions we would like to ask are: 1. How long does the community believe it is reasonable to take to bring an AS 'on-line'? 2. After how many months of not being in use should an AS be returned? Due to a lack of time in the LIR Working Group session at RIPE 42 (May 2002) we were not able to discuss the community's policy for AS numbers. We would like to raise the issue now so that there is ample time for a discussion before RIPE 43, on Rhodes, in September. We welcome the community's input on this policy matter. Kind regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager
At 11:53 AM 09-07-02 +0200, leo vegoda wrote:
Dear Colleagues,
Within the RIPE community the AS policy (ripe-245) is based upon RFC 1930. The RIPE policy states that "a network [is required] to be multihomed for an AS number to be assigned". However, there is no clear policy on returning unused AS numbers to the pool.
We would be grateful if the community would clarify the policy so that it is clear when an unused AS number should be returned to the pool.
Specific questions we would like to ask are:
1. How long does the community believe it is reasonable to take to bring an AS 'on-line'?
3 months.
2. After how many months of not being in use should an AS be returned?
3 months. 3. After how many months of being single-homed should an AS be returned? 9-12 months. -Hank
Due to a lack of time in the LIR Working Group session at RIPE 42 (May 2002) we were not able to discuss the community's policy for AS numbers. We would like to raise the issue now so that there is ample time for a discussion before RIPE 43, on Rhodes, in September.
We welcome the community's input on this policy matter.
Kind regards,
-- leo vegoda RIPE NCC, Registration Services Assistant Manager
Leo,
Specific questions we would like to ask are:
1. How long does the community believe it is reasonable to take to bring an AS 'on-line'?
3 months. Any thing else can be done on an exception basis. But you better carefully define "'on-line'"! :)
2. After how many months of not being in use should an AS be returned?
Again I think 3 months, but as you assuming that this is when the AS is no longer "'on-line'" ? I think there should then be a period of non-use [6 months or so?] before that ASes that are returned get reused, and some form of communications plan around the re-allocation of an AS. Imagine what might happen when 1755 gets re-issued? :) Regards, Neil.
On Tue, Jul 09, 2002 at 11:53:14AM +0200, leo vegoda wrote:
Dear Colleagues,
Within the RIPE community the AS policy (ripe-245) is based upon RFC 1930. The RIPE policy states that "a network [is required] to be multihomed for an AS number to be assigned". However, there is no clear policy on returning unused AS numbers to the pool.
Would it be possible to define term multihomed more clearly? Does it mean that AS just should have more than one eBGP peer? Lets see the following example: +-----------+ +-------+ | AS-UPLINK | | AS-IX | +---------o-+ +o------+ | | +o-----------o+ | AS-CUSTOMER | +-------------+ AS-CUSTOMER is world-visible through AS-UPLINK and limited visible to some ASes through AS-IX. Should AS-CUSTOMER be considered as multihomed? -- Regards, Vladimir.
I'd say yes, also if it perhaps once was intended differently. There are a number of ISPs out there which have for cost reasons only one upstream provider, but want to (also for cost reasons) peer at an exchange. This might not be the most redundant approach, but we should not tell them how to run their business. What would happen if we'd not allow this? Just more wrong entries in the RIPE database..... best regards, Wolfgang
-----Original Message----- From: owner-lir-wg@ripe.net [mailto:owner-lir-wg@ripe.net]On Behalf Of Vladimir A. Jakovenko Sent: Tuesday, July 09, 2002 1:08 PM To: leo vegoda Cc: lir-wg@ripe.net Subject: Re: [lir-wg] AS Number Policy
On Tue, Jul 09, 2002 at 11:53:14AM +0200, leo vegoda wrote:
Dear Colleagues,
Within the RIPE community the AS policy (ripe-245) is based upon RFC 1930. The RIPE policy states that "a network [is required] to be multihomed for an AS number to be assigned". However, there is no clear policy on returning unused AS numbers to the pool.
Would it be possible to define term multihomed more clearly? Does it mean that AS just should have more than one eBGP peer?
Lets see the following example:
+-----------+ +-------+ | AS-UPLINK | | AS-IX | +---------o-+ +o------+ | | +o-----------o+ | AS-CUSTOMER | +-------------+
AS-CUSTOMER is world-visible through AS-UPLINK and limited visible to some ASes through AS-IX.
Should AS-CUSTOMER be considered as multihomed?
-- Regards, Vladimir.
Or, like me, you only have one *transit* provider, but a number of (small) private peering connections. Yes, the use of private/fake AS space is feasible, but the same issues arise as with the misuse of RFC1918 space between organisaions. Peter ----- Original Message ----- From: "Wolfgang Tremmel, WT5-RIPE" <wtremmel@vianetworks.com> To: "Vladimir A. Jakovenko" <vovik@lucky.net>; "leo vegoda" <leo@ripe.net> Cc: <lir-wg@ripe.net> Sent: Tuesday, July 09, 2002 1:10 PM Subject: RE: [lir-wg] AS Number Policy
I'd say yes, also if it perhaps once was intended differently.
There are a number of ISPs out there which have for cost reasons only one upstream provider, but want to (also for cost reasons) peer at an exchange. This might not be the most redundant approach, but we should not tell them how to run their business.
What would happen if we'd not allow this? Just more wrong entries in the RIPE database.....
best regards, Wolfgang
-----Original Message----- From: owner-lir-wg@ripe.net [mailto:owner-lir-wg@ripe.net]On Behalf Of Vladimir A. Jakovenko Sent: Tuesday, July 09, 2002 1:08 PM To: leo vegoda Cc: lir-wg@ripe.net Subject: Re: [lir-wg] AS Number Policy
On Tue, Jul 09, 2002 at 11:53:14AM +0200, leo vegoda wrote:
Dear Colleagues,
Within the RIPE community the AS policy (ripe-245) is based upon RFC 1930. The RIPE policy states that "a network [is required] to be multihomed for an AS number to be assigned". However, there is no clear policy on returning unused AS numbers to the pool.
Would it be possible to define term multihomed more clearly? Does it mean that AS just should have more than one eBGP peer?
Lets see the following example:
+-----------+ +-------+ | AS-UPLINK | | AS-IX | +---------o-+ +o------+ | | +o-----------o+ | AS-CUSTOMER | +-------------+
AS-CUSTOMER is world-visible through AS-UPLINK and limited visible to some ASes through AS-IX.
Should AS-CUSTOMER be considered as multihomed?
-- Regards, Vladimir.
Hello,
We would be grateful if the community would clarify the policy so that it is clear when an unused AS number should be returned to the pool.
Specific questions we would like to ask are:
1. How long does the community believe it is reasonable to take to bring an AS 'on-line'?
3 months (it seems there is agreement)
2. After how many months of not being in use should an AS be returned?
6 months Companies get bought, ASes get merged, companies got sold, ASes get split again We should allow a slightly longer period here. Wolfgang
On Tue, 9 Jul 2002, leo vegoda wrote:
We would be grateful if the community would clarify the policy so that it is clear when an unused AS number should be returned to the pool.
Let's try to summarize things a bit: this issue is not only about numbers and timescale. A complete AS number revokation policy must comprise of 4 components: * Audit policy on AS number usage. * Clear definition of policy violation. * Revoking AS numbers from customers violating AS number usage policies. * Reusing revoked AS numbers. RIPE NCC reserves the right to perform periodic audits on AS number usage and take appropriate actions if necessary, to enforce compliance with ripe-245 and RFC 1930. RIPE NCC will use RIS to check if an AS number is used with compliance with those documents. RIPE NCC must never consider RIS as the ultimate source and must always raise an audit ticket towards the LIR and/or an end customer of an AS before taking any further action. A possible violation of the policy happens if an AS number: (1) Does not appear in the routing table at all: (a) Assigned, but never appeared (startup case) within S months. (b) Missing completely for more than D months. (2) Appears in the routing table via a single AS path for more than M months. While we can discuss on the values of S, D and M special care must be taken on revokation and reusal policy. For (1a) - there seems to be a consensus that S would be 3 months. For (1b) - just to be on the safe side D should be at least 6 months. For (2) - also to be on the safe side M should be at least 12 months. If a violation if found, RIPE NCC reserves the right to notify the LIR that requested the AS number about violation and ask them to provide additional evidence that the AS number is still in valid use. A clear statement from the LIR that the AS number is still used in compliance with the policy MUST be enough to close the audit ticket. No further action should be taken in that case. If there is no response from the LIR, RIPE NCC should contact the admin-c and tech-c specified in the aut-num object. In a lot of cases an AS number is issued by a LIR that doesn't have anything to do with the customer any more. If no response counting from notification date is received from the end customer: * In the case (1a) - within 3 months, * In the case (1b) - within 6 months, * In the case (2) - within 12 months the AS number may be revoked by RIPE NCC. AS number reusage policy - a revoked AS number may be reused after certain period of time, defined as: * In the case (1a) - 3 months after it is revoked from the end customer. * In the case (1b) - same time period that elapsed between revokation date and initial assignment date of the AS number. That should give enough time to all people to cleanup their configurations, policies etc. * In the case (2) - same as (1b). Regards, Beri
participants (7)
-
Berislav Todorovic -
Hank Nussbacher -
leo vegoda -
Neil J. McRae -
Peter Galbavy -
Vladimir A. Jakovenko -
Wolfgang Tremmel, WT5-RIPE