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

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Iljitsch,

On 2008-01-11 23:24, Iljitsch van Beijnum wrote:
> 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.

For non-mobile hosts, I don't see why there'd be a tunnel; the
packet can simply be forwarded to the organization's IGP. For
mobile hosts, you seem to be describing a MIP proxy.


> 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.

Iff the organization's ETRs communicate with each other.

> 
> 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.

That sounds pretty messy from an admin point of view.

   Brian

--
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