Subject: Re: [lisp] #16: map versioning resolution

From: [email-masked] (Noel Chiappa)
Date: Wed, 2 Sep 2009 18:31:24 -0400 (EDT)

> From: Sam Hartman <[email-masked]>

    >  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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 03 Sep 2009 08:52:03 -0400

>>>>> "Noel" == Noel Chiappa <[email-masked]> writes:

    >> From: Sam Hartman <[email-masked]> 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

    Noel> I thought we had converged on another choice:

    Noel>  * process the packet normally, ignoring the R-bit
That's fine too.  I'm still not supporting this, but if a consensus
develops that we want such a feature,ignoring the R bit is fine.