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 [EMAIL PROTECTED] 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
