[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