[sig-policy]RE: [sig-ipv6]Let's restart discussion about RIPE-261 [long]
>> Michel Py wrote:
>> However, the choice of the block to be used is critical. In
>> the discussion about the issues Gert Doering raised (I will
>> send another email to the list) I did rate the CAP system
>> proposed in RIPE-261 as my last choice because the CAP prefix
>> (2000::/3) was too big and did not leave any room to special
>> or unforeseen purposes.
> Geoff Huston wrote:
> At this stage the global unicast space is 1/8 of the total IPv6
> space, and some 5/8 (actually more) is unassigned (RFC 3513)
> One possible response to this perspective is that the currently
> unassigned pool is large enough to leave room for special or
> unforseen purposes while still allowing 2000:/3 to be used to
> maximal effect in a sparse allocation framework.
My bad, I should have written "not leave any room to MINOR special or
unforeseen purposes WITHOUT AMENDING RFC3513". I clearly understand that
more than 5/8 of the address space does not have a purpose yet, which
means indeed that if we need addresses for a new purpose we do have the
space. So if we invent "gizmocast" we allocate 4000::/4 to it and we're
done.
The point I was trying to make though is that there is little advantage
in using the full 2000::/3 space for the CAP over using 2000::/4 or
2000::/5.
Let's say that if we allocate 2000::/5 to the CAP and _if_ in a few
years we find out that projections show it's not going to be big enough
in the long run, it would be easy to then extend the CAP to 2000::/4 or
2000::/3.
OTOH, if we allocate 2000::/3 to the CAP now and in a few years find out
that we could use a /8 for unicast purpose xyz, we will then have to go
to many more political hurdles to get part of 4000:: allocated to the
new purpose. Keep in mind that when using a sparse allocation method
such as RFC3531 there will very quickly be space assigned all over the
chosen block, making impossible to find a large block in one piece after
a short while.
In other words: a /5 or /4 is already a HUGE space. Do the advantages of
making the CAP a /3 vs. a /4 or /5 (with the possibility of extension)
balance the inconveniences of breaking the shrinkwrap of 4000::? I say
no.
There is an unfulfilled need for PI identifiers and nothing that says
that 2000::/3 is PA space.
> However, there are a raft of further considerations that any
> address allocation framework should take into account, and at
> some stage there is probably some benefit in revisiting the
> underlying framework of attempting to impose strict
> provider-based aggregation hierarchies.
And a good opportunity to do so might present itself soon, which was the
main reason behind my proposal.
>> Gert Doering wrote:
>> - As a technical reason: people want to be able to filter IPv6
>> prefixes by region, like "I only have one uplink that provides me
>> with US connectivity, so there's no need to carry any US prefixes
>> in my routing table, I just point a summary down that line".
> Geoff Huston wrote:
> These days communities in BGP fill that role.
You lost me. I was not aware that there were BGP communities per
country, at least not in the BGP feeds I am getting. Would you care to
develop this a bit? Specifically for multihomed organizations I never
heard about some cross-ISP standardization of something like this.
> and while I read with interest the notional carve up of address
> space in Michel's posting, I fit it uncomfortable to see how
> this could fit within the policy-rich world of network paths
> and provider interactions.
It does not have to fit anywhere. For the purpose of making the point, I
have equalized the address space for the three proposals (except doing
nothing) that we currently have on the table at a /4, kind of the middle
of the road.
So, space being equal, what we can do is:
1. The CAP over 2000::/4 similar to RIPE-261.
2. A /6 per RIR as per Gert's proposal.
3. Michel's stuff over 2000::/4.
What are the differences between the three?
- The way address space is delegated to RIRs. Other things such as the
way RIRs assign space to LIRs or NIRs, the LIR creation process, etc
would not change.
- Possibilities of aggregation. The key word here is "possibilities"; I
will get back to this in a minute.
- With 1, there is no possible aggregation.
- With 2, there could be aggregation per RIR.
- With 3, there could be aggregation per country and (sub)continent.
Does geographical PA aggregation work? We don't know yet.
Will people use it? We don't know yet.
Is it that interesting? We don't know yet.
The question is not what does it do, but what does it cost. Not much. If
you look at the three options, what does my stuff cost? Two things:
a) The address space of large LIRs would be fragmented. Honestly I don't
see this as much of a problem because in reality it would not change the
number if routes inside a large LIR compared to the IS-IS (or OSPF)
routes and aggregates they would have anyway. The bad point is in
route-maps when checking "is this my space or not" that would be
complex. Some might actually consider this an advantage, as it makes a
lot easier troubleshooting summarization (traps like no auto-summary)
and subnet mask SNAFUs.
b) There would be a few hundreds or long-term a few thousands extra
routes in the GRT which is not enough to care.
In short: What does my proposal take away compared to the other two? A
little simplicity. I think it's worth it compared to the potential
advantages of per-country and per-continent aggregation.
Michel.