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

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



Hi Scott,

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.  Optimal  routing
implies that there will be different locator preferences for
different hosts.  Mobility within the organization itself implies
that creating and maintaining meaningful identifier prefixes is
going to prove challenging.

There are two questions in here.

- What do multiply-connected large organizations do?

 ....  The good thing about ALT is that this
 fine granularity is not visible above the first 1-2 levels of the
 ALT hierarchy.


I thought that ALT carried aggregated EID information. How does the correspondent host get EID-specific information? Did I misunderstand ALT?

Site-based EID-prefixes are injected into the ALT topology. ALT routers can further aggregate into the core. A source site sends a data packet or Map-Request to an specific EID that follows the route on the ALT topology to get to the ETR at the destination site which returns a Map-Reply with the a locator-set for the site-based EID- prefix.

- What is the effect of mobility within the organization?

 Let's be clear that in LISP an EID is not a persistent identifier of
 a *device*.  It names a network attachment point or (from the other
 side) an interface.  So "slow mobility" -- without a need for
 session continuity -- will involve assignment of a new EID.  If
 there is a need for session continuity, then the problem is better
 solved at a higher layer.  If it cannot be solved up there, then
 fast mobility mechanisms -- MIPv6 or whatever we settle on -- are
 appropriate.  Solve it in per-connection signaling, not in the
 fundamental routing exchanges.


If you go down this path, I'm having a hard time really reconciling the difference between an RLOC and an EID. It seems like if I move, I might change both, so that some location semantics has leaked into the EID definition.

If you move and you don't need session survivability you *can* change both. And to make that movement compatible with existing trends and deployed sites, you get a DHCP address (you as a host) that will be used as an EID. You (as a host) don't have locators per say, but the site you are at does (the IP addresses of the ETRs).

If you move and want session survivability, the EID must move with the host (and the host stack has to retain the address when the interface goes down, this is not common). This is the case where the RLOCs change for a single EID (versus the EID-prefix because the home site doesn't move, NEMO aside for a moment).

In other words, I think that we need host level granularity in the
mapping function.

It can be provided if needed, although I don't think it should be. In
ALT, single EID prefixes can be advertised to ALT routers which will
then aggregate them, so the effect of long prefixes will damp out
quickly.


Which implies that EID-specific information will be lost, which in turn costs us functionality.

The more specific bits of an EID will be lost, but the mapping data is not lost because it is returned in the Map-Reply.

Excerpts from Tony Li on Thu, Jan 10, 2008 02:59:05AM -0800:
?  You missed my point: you pick all, simultaneously.  You let
your particular working set characteristics in your particular
location select which particular approach you use at that
particular location.  All of the choices need to be integrated so
that they result in one clean mechanism.

We have already made that conclusion. You should have seen that at
RRG.

No, what I saw was a total mess of mechanisms, with no coherency.


Man, that came out snarky.  Apologies, it wasn't meant to be.

Thanks for the apology.   ;-)

I like your idea, but there are complexity tradeoffs.  You can get
some of that dynamic adaptation with hybrid push/pull models, where
the boundary between "push" and "pull" can move depending on load ...
but we had better be sure we can debug problems with it before we
allow that kind of dynamicity.  Map&Encap and 8+8 are very different,
but if we use Dino's idea of how to use IPv6 and map&encap maybe we
could get dynamic boundaries between all of them.  Should be studied
further.

Just in case I've confused anyone, I side with Einstein when it comes to complexity. ;-)

So using one mapping system would be better then.

A node *can* roam and preserve its original IP address, but we should
not put that in the underlying routing.  It can be done in connection
signaling a la MIPv6.


Fair, but unless we're willing to open the transports to actually add that to connection signaling, that's going to prove challenging. So far, all of the feedback on host changes (transport layer or otherwise) is all negative.

If the original IP address *stays* with the host, it continues to use it. So there are no hot changes.

Dino

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