[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures



On 10 jan 2008, at 22:02, Brian E Carpenter wrote:

There are large organizations (you used to work for one of them, I believe ;-) where there are multiple Internet connections that have geographically widely dispersed contact points.

Correct. And that is a significantly harder problem than multihoming
for an enterprise network that only has one point of interconnection
to the outside.

People blame the routing table growth on multihoming (although it's obvious from the number of active ASes that one prefix/one AS multihoming can be blamed for only about 10% of the current DFZ) but now that PI is possible for IPv6 it's only a matter of time before the cat comes out of the bag that large organizations actually want multiple PI prefixes rather than just one.

Certainly I'd expect EID space for large enterprises to be sliced
and diced down to the geographical-site or even server-farm level.
I don't think it's necessary down to host level.

Today, if I announce a /16 the whole world sees a /16. If I announce 256 /24s, the whole world sees 256 /24s, and I can't announce 65536 / 32s.

We could make a new system such that the length of cached prefixes isn't fixed, but can be adjusted based on the needs of the originating network, the amount of traffic and the availability of cache resources.

I.e., if an organization has a /16 EID prefix that is split up in a bunch of /24 used in different geographical/topological locations, and some of the individual addresses within those /24s are used by mobile hosts, it would be possible to push out a set of RLOCs for that /16. Those RLOCs map to the biggest links of the biggest locations used by the organization. Basically, these are home agents for all the addresses in the /16 that can tunnel any traffic that arrives for any address in that /16 to the host holding that address, whereever it happens to be at any given time. However, if the ITR has the caching resources and/or the amount of traffic is significant enough, the ETR can signal a more specific mapping back to the ITR.

In the case of a single organization with a short prefix that covers multiple more specifics, this is easy. More generally, the same thing could be done by aggregating a bunch of neighboring prefixes belonging to different organizations. This is harder because the aggregation point must be managed and it can't become a choke point.

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg