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

[Scott Brim <swb@employees.org>]

I'm starting to catch up ... sorry I'm so far behind ... starting with
this sub-thread.

Excerpts from Tony Li on Wed, Jan 09, 2008 03:15:34PM -0800:
>> Can we clarify that conceptually we are talking about prefixes and
>> not individual interface EIDs, as far as the full map goes?
>> (Except, presumably, for a few special cases such as root servers.)
>
> Well, this should spark some useful discussion...  ;-)
>
> Sorry, no, I don't think that you can make that assumption without a
> lot more justification and/or consensus building.  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?

  Putting mobility aside for the moment (see question 2) ... First,
  they can do something common today, which is to have different
  prefixes reflect different geographic locations.  If some
  governments have their way, this will be required in any case.  If
  they want more fine-grain control, for example due to internal
  movement where they don't want to renumber ... if they are running
  ALT the ETRs themselves reply to Map-Requests and decide what will
  go in Map-Replies (with what ETR priority), so this can be
  controlled by the receiving organization's policy.  If they are not
  running ALT, that can be taken care of piggybacking in the LISP
  header of the data packets.  The good thing about ALT is that this
  fine granularity is not visible above the first 1-2 levels of the
  ALT hierarchy.

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

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


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.

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.


Excerpts from Brian E Carpenter on Fri, Jan 11, 2008 10:50:07AM +1300:
> OK, I was too telegraphic. I don't believe that mobility that
> preserves a global routing prefix is a requirement. [Discussion of
> the value of Mobile IP elided.] I do mean global - there are
> certainly scenarios where mobile prefixes are a requirement, but
> those won't be prefixes that ever need to be in the public Internet,
> so they aren't part of what I thought we were discussing here.

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.

Scott

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