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

Re: [lisp] LISP Mobility Architecture



Jari, thanks for making the high level decision on LISP mobility.

My interpretation of your wording as chair follows; please let me know
if I got it wrong.

First, as always, we're designing an extensible protocol.  So,
extensibility features that might be needed if we expand our scope in
the future are in scope--that includes things like making sure we
could allocate a flag in the future,making sure we have ways to evolve
ITR/ETR behavior in the future, etc.  I.E. the sorts of holes Noel is
talking about.

However, at this point, the IETF has not considered the following
questions, and this working group is not chartered to consider them:

1) is LISP going to be part of a mobility solution
2) If so, how course-grain/fine-grain
3) How does LISP fit together with protocols like MIP6, MIP4, NETLMM, NEMO
4) Will any LISP mobility solution be based on the current LISP mobility architecture


As a personal note, I'd recommend anyone interested in LISP and
mobility take a look at draft-ietf-mext-aero-reqs-04; I read it as a
secdir reviewer.  It seems that some of those requirements may not be
such a good fit for our existing mobility toolbox. I have not thought
much about whether LISP would be a good fit for them, but it seems worth thinking about.

In terms of mobility impact on our base specs, we're not currently
considering mobility or mobility related changes in the base specs,
beyond the sort of leaving room for future expansion we discussed
above.  Even if it were in scope, we'd need to come to a conclusion on
whether LISP was a mobility approach that the IETF wanted to pursue
before we'd want to consider mobility issues in the LISP design.

The boundary between mobility, which is out of scope for now, and
things like renumbering of a multi-homed site can be a bit fuzzy.  My
personal belief is that when you start considering issues like
preserving connections when all existing RLOCs change, rapid change of
RLOCs, or optimizing for /32 or /128 EID allocations, you're
definitely into the mobility realm.

Sam Hartman
LISP co-chair

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.