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.