Subject: [lisp] Packet format change mechanism [Was: #8: Limits on "Gleaned" Map Entries Not Clear]

From: [email-masked] (Noel Chiappa)
Date: Wed, 9 Sep 2009 11:38:44 -0400 (EDT)

> From: Margaret Wasserman <[email-masked]>

    > I think it would be wiser to move to a 64-bit nonce. These are in
    > control packets only, so moving to a longer nonce shouldn't effect
    > forwarding performance or anything.

This message isn't really about this particular issue (hence the mod to the
subject line), but this gave me a good 'hook' to start from.

Let me seque into my main point by saying that I personally don't have a
strong feeling one way on another on this particular point. I think both are
right - Dino that the hole is very small (see my message from last night:

  http://www.ietf.org/mail-archive/web/lisp/current/msg01304.html

which still seems accurate to me, although I haven't thought deeply about it
today), and Margaret that the fix is simple and cheap. (Heck, a cheapo ITR
which thinks the risk is negligible can use only 32 bits of randomness, and
zero-fill the other half of the field.)

What is _not_ cheap is the change to the packet format - but I am _not_
suggesting we don't make packet format changes (far from it), merely
suggesting a change in _how_ we make changes to the format.

To start with, everyone needs to understand that there is a substantial
deployed testbed. Every time we make an incompatiable change to the packet
format, the testbed has to bifurcate and/or have a flag day. This is a
hassle, and slows down progress.

So my suggestion is simple: we divide packet format changes into 'critical'
and 'non-critical'. Non-critical changes are changes that we want to add, but
aren't necessary 'right away'. (This 32->64 fix, if agreed on, would be an
example.)

We should accumulate non-critical changes in a list somewhere (do we have a
IETF Wiki page, or something, where we could keep it?), and only add them in
batches when either i) we make a critical change (i.e. the format is going to
change _anyway_), or ii) we're about to do some significant milestone and
it's OK to add them (e.g. go to RFC).

I think that this mechanism nicely satisfies both i) the need to be able to
make changes, and ii) the need not to disrupt the testbed with 'flag days'
unless absolutely unavoidable.

	Noel

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Sep 2009 11:54:57 -0400

We do have wiki pages off http://tools.ietf.org/wg/lisp, and in my
individual opinion this would be an excellent use of wiki pages.

I'd prefer to see format changes made at least every six months.