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



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



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. 



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.



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



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.
In fact, if we're willing to open the transports, then we really have to question why we couldn't take an SCTP-like approach. 

Tony


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