Re: [lisp] #16: map versioning resolution

[jnc at mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Sam Hartman <hartmans-ietf at mit.edu>

    >  If a ETR receives a packet with this bit set and has not
    >  been explicitly configured to participate in an experiment, then
    >  [pick from group a].
    >  ...
    >  Group A:
    >  * drop the packet
    >  * decapsulate and process the inner packet but ignore the LISP header

I thought we had converged on another choice:

 * process the packet normally, ignoring the R-bit

Part of the rationale for this behaviour is that this allows easy incremental
deployment of a new mechanism (possibly mapping-versioning [which I personally
find to be a more apropos term than 'map versioning', but I digress]), since
'new' packets will be processed appropriately by 'old' devices.

Also, use of the two header fields (24-bit and 32-bit) is controlled by
'positive' flag-bit semantics, i.e. the fields do not hold anything _unless_
the appropriate flag-bit it set. (I.e. unless L is set, the 32-bit field is
free, and similarly for N and the 24-bit field.) So, an experiment with the R
bit can use either of those fields for an 'experimental' use, provided that
appropriate flag-bit for that field is clear.


    > if we're going to have a version field it be at least two bits wide.

It's not a version field, as I think of them: see my previous message
to Margaret:

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

on this topic.

    > Howevver I think it would be reasonable for the WG to decide on a
    > one-bit version field

As in that message, the thinking is that since header bits are such a scarce
resource, we'd rather not devote them a priori to a 'version' field, and
preserve maximum flexibility for the future.

It's also worth pointing out that a packet with 'E' set and 'N' clear is
currently illegal, and that pattern could serve as an escape to a new header
format.

(As an interesting historical aside, there is a _long_ history of this sort
of thing in networking - the first ARPANet header was 32 bits, and it was
replaced by a 96-bit header, use of which was flagged by an 'illegal' value
of xF in a 4-bit field in the original 32-bit header!)

	Noel