Re: [v6ops] [GROW] Deaggregation by large organizations

[Christopher Morrow <[e-mail]>]

(man mac-mail and gmail don't play well... I'm not re-formatting this, sorry)

On Wed, Oct 15, 2014 at 8:29 AM, Iljitsch van Beijnum
<[e-mail]> wrote:
> We are all familiar with PA (provider aggregatable) and PI (provider independent) address space. But it turns out a new type of IPv6 address space is starting to show up, which I'll call organization deaggregatable (OD) address space (until someone suggests a better name).
>

your OD sounds like (from reading below) like what PI is for, or ...
OD == PI, from what i can tell.

> How it works is like this: a large organization obtains a large block of IPv6 address space, either as a very large PI block or by becoming a local internet registry (LIR) and getting a regular LIR assignment directly from one of the five regional registries. However, rather than advertising that block in BGP as a single prefix, or perhaps a handful of prefixes, like an ISP would, they subdivide this block within the organization and then many subunits advertise subprefixes though different ISPs. The aggregate may or may not be advertised.
>

sure, this is what enterprises are sort of forced into in the v6
world. They MAY have a contiguous backbone behind their ISP links, or
may not. They MAY have ASN for some/all of their sites, they may not.

They have v6 address space for each office (say a /48 for instance
from a larger /<something>) and they've gotten agreement from their
various ISPs to announce the 48's to the world.

> The advantage to the organization is that they have provider independent address space that they'll never have to renumber out of, as well as having a single prefix that identifies all of the organization, which makes filtering easy.
>

yup

> There seem to be two types of organizations that do this: geographically dispersed ones that advertise subprefixes in different locations, such as multinationals, and organizations with very independent subunits but with more limited geographical scope, such as national governments.
>

ok, not clear how the type-o-org matters here. "People do this, see
the routing table."

> This practice, especially if/when it becomes more common, presents two challenges:
>
> 1. Large numbers of prefixes may show up in the global routing table. For instance, there is a number plan for all of the German government, which could potentially inject more than 5000 municipality prefixes into the global IPv6 routing table.
>

ok <1% growth.

> 2. Filtering. If people want to avoid large numbers of deaggregates in their routing tables, they may employ some kind of filtering, especially if the deaggregates are very long prefixes. This means that packets are no longer reliably delivered to the place announcing a more specific prefix.
>

ok, maybe.. but this depends a bunch on what upstream setup is used as
well. It seems that if there is arbitrary filtering other solutions
will work themselves out (announce aggregate, keep all sites connected
to a single/small-set of isps, etc).

it's messy, but...

> Ideally, a set of best practices would be developed that strike a good balance between the needs of large organizations and the needs of the global routing system, and allow everyone to predict the consequences of different kinds of behavior and thus avoid unpleasant surprises.
>

i feel like we sort of have that already, or we know how the global
table works and people live within those constraints.

> These are some of the things that could go into such best practices:
>
> - A well-understood maximum prefix length for IPv6, similar to /24 for IPv4.
>

do we want to draw that line in the sand though? I think so far 'let
operations folks work that out' has worked out pretty well. There's no
official standard in v4, why would we want one in v6?

> - An understanding of how the service providers that provide connectivity to multiple subunits of a large organization can work together in order to maximize availability and minimize costs for the organization, the service providers and other network operators.
>

"cannibalize customers from your neighbors" isn't what you're looking
for here, eh?
I think TODAY there isn't a problem (nothing is broken, yet) so it's a
bit hard to talk about the 'right' answer here. (sure we could take a
guess, but...)

> - A way to provide a point of last resort where traffic for the aggregate can be sent to if more specifics are filtered.
>

this, to me, is the 'headquarters' facility announces the aggregate
and maintains a tunneled path to their subunits out over the world.

you could slice/dice this in a number of other ways, clearly. I'm not
sure more complexity is good though.

> - A set of communities that indicate whether a prefix is a more specific that is covered by an aggregate and/or is safe to filter without loss of connectivity.
>

so, add communities to global routes, because people don't strip these
in ingress as a matter of best practice? (if you don't you REALLY
should consider it, i think)

> - A set of communities that indicate geographical origin of prefixes so remote more specific prefixes can be filtered while local prefixes are kept.
>

we ran over the geo-prefix rat in SIDR, I don't know that running over
it again is especially great for time management. (see terry
manderson's geo-data-rpki presentations/drafts, in stockholm and 1/2
meetings after/around then)

> - Guidelines for reserving address space in address plans. Is it better to have free space reserved so existing prefixes can grow, or keep reserved space together so tight prefix length filters are possible and reserved space isn't broken up into small pieces?
>

uhm... this is a bit of a religious debate isn't it? You'd also be
imposing the 'one true way' on people who generally have issues with
that sort of thing. Not to mention how does excel manage ipv6 prefix
splitting? :)

> Please note that I'm crosspositing this to v6ops and grow initially. If the chairs have any guidance on which working group is more appropriate for this discussion, please let us know and we can drop the other one.
>
> Also note that I haven't been following discussions in both wgs recently, so if this has been discussed previously, my apologies.
>
> Last but not least, this treads on RIR policy. But in my opinion, this is foremost a technical matter with global implications and as such is best discussed within the IETF rather than in the five respective policy development forums.

i don't see it hitting RIR policy so much, sinc ethe RIR's absolved
themselves of 'routability' of prefixes long ago. 'if you can't reach
your shiney new allocation it ain't ARIN's problem'.

-chris

> _______________________________________________
> GROW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/grow