Is there some central repository for information on this? We usually seem to find out about such changes out of the ARIN region a bit after the fact.
Have we not learnt from v4? If there are to be filters then they should be defined once and never changed as people will fail to update If a different allocation requirement arises then start a new prefix (v6 is big enough to handle this) and define its filter once. Do not allocate it from an existing range and expect people to adjust their filters. brandon
On Sat, Oct 3, 2009 at 6:28 PM, Brandon Butterworth <brandon@rd.bbc.co.uk>wrote:
Is there some central repository for information on this? We usually seem to find out about such changes out of the ARIN region a bit after the fact.
Have we not learnt from v4?
If there are to be filters then they should be defined once and never changed as people will fail to update
Yay! We can return to classful routing again. That sure worked out well for us the first time around. ^_^;
If a different allocation requirement arises then start a new prefix (v6 is big enough to handle this) and define its filter once. Do not allocate it from an existing range and expect people to adjust their filters.
So, if I need to break up my /32 into 4 /34s to cover different geographical regions, I should instead renumber into a new range set aside for /34s and give back the /32? Sure seems like a lot of extra overhead. Perhaps we should give everyone an allocation out of each filter range, so that they can simply number from the appropriately-classed range; when you apply for space, you'd get a /32, a /33, a /34, a /35, a /36, etc. all from the appropriate, statically defined ranges. *removes tongue from cheek*
brandon
Matt
On 03/10/2009 8:19, "Matthew Petach" <mpetach@netflight.com> wrote: [...]
So, if I need to break up my /32 into 4 /34s to cover different geographical regions, I should instead renumber into a new range set aside for /34s and give back the /32? Sure seems like a lot of extra overhead. Perhaps we should give everyone an allocation out of each filter range, so that they can simply number from the appropriately-classed range; when you apply for space, you'd get a /32, a /33, a /34, a /35, a /36, etc. all from the appropriate, statically defined ranges.
I think ARIN proposal 2009-5 (https://www.arin.net/policy/proposals/2009_5.html) is designed to cope with the situation you describe. I understand that it's on the agenda for the meeting in Dearborn. Regards, Leo
From: Leo Vegoda <leo.vegoda@icann.org> Date: Sun, 4 Oct 2009 04:32:44 -0700
On 03/10/2009 8:19, "Matthew Petach" <mpetach@netflight.com> wrote:
[...]
So, if I need to break up my /32 into 4 /34s to cover different geographical regions, I should instead renumber into a new range set aside for /34s and give back the /32? Sure seems like a lot of extra overhead. Perhaps we should give everyone an allocation out of each filter range, so that they can simply number from the appropriately-classed range; when you apply for space, you'd get a /32, a /33, a /34, a /35, a /36, etc. all from the appropriate, statically defined ranges.
I think ARIN proposal 2009-5 (https://www.arin.net/policy/proposals/2009_5.html) is designed to cope with the situation you describe. I understand that it's on the agenda for the meeting in Dearborn.
I don't think so. I believe the statement is not in regard to separate, discrete networks bu to a network with a national footprint which must deaggregate to do traffic engineering by region. Item 2 clearly makes 2009-5 non-applicable to this case. This issue will be discussed in a Mark Kosters moderated panel at NANOG in Dearborn. Hey, why not attend both meetings? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On 04/10/2009 4:49, "Kevin Oberman" <oberman@es.net> wrote: [...]
So, if I need to break up my /32 into 4 /34s to cover different geographical regions, I should instead renumber into a new range set aside for /34s and give back the /32? Sure seems like a lot of extra overhead. Perhaps we should give everyone an allocation out of each filter range, so that they can simply number from the appropriately-classed range; when you apply for space, you'd get a /32, a /33, a /34, a /35, a /36, etc. all from the appropriate, statically defined ranges.
I think ARIN proposal 2009-5 (https://www.arin.net/policy/proposals/2009_5.html) is designed to cope with the situation you describe. I understand that it's on the agenda for the meeting in Dearborn.
I don't think so. I believe the statement is not in regard to separate, discrete networks bu to a network with a national footprint which must deaggregate to do traffic engineering by region. Item 2 clearly makes 2009-5 non-applicable to this case.
I thought that "Geographic distance and diversity between networks" covered the case above but I could well be wrong.
This issue will be discussed in a Mark Kosters moderated panel at NANOG in Dearborn. Hey, why not attend both meetings?
I won't be there in person but look forward to watching the video feed. Regards, Leo
participants (4)
-
Brandon Butterworth -
Kevin Oberman -
Leo Vegoda -
Matthew Petach