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

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

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

    > I'm not following the reasoning or discussion that lead from where I
    > think we were in Stockholm to a conclusion that map versioning needs
    > research but the other mechanisms do not.

The problem is that we're operating in something of a vacuum,
operational-data-wise. (Apologies in advance to the degree that any of the
following is teaching of egg-sucking... And I also apologize in advance if I
have mis-understood anything I've heard from various collaborators, so if I
get something wrong, 'just shoot me'... :-)

We have what everyone feels has the _potential_ to be a problem - i.e.
outdated mappings. There are also a bunch of ideas on various different
mechanisms to tackle that problem, each of which has plusses and minusses
(complexity, operational overhead, etc).

In the particular case of mapping-versioning, piggybacking it on
user-data-trafffic has some big advantages (e.g. no extra packet traffic),
but from an _implementation_ point of view, in one of our main testbeds
(Dino's), my understanding is that it has a big downside, which is that
getting the data plane to do anything control-oriented is really hard.
(I got the impression that doing echo-noncing for reachabilty detection was
fairly painful, for instance.)

Which of course shouldn't weigh too heavily on a design decision (ask me
sometime about the variable length IP addresses in IPv3, and the number of
pointer registers available in TENEX at interrupt time - you can guess where
that story goes :-( - unless it's a _typical_ kind of problem for high-end
router boxes (i.e. piggybacking control operations on user-data traffic),
which I get the sense it might be.

Still, when you add to that the concept that a versioning-type solution (I
personally prefer checksums to versions, but that's an engineering detail)
can be incrementally added later, I think that's _part_ of why that one is
still 'on the back burner'.

The thing is that without more real-world data on i) how big a problem
outdated mappings are, ii) how expensive various solutions are, iii) how well
those solutions work, etc we're kind of shooting in the dark without a
night-scope. This is also a case where I'm not sure simulation would even
help much, since it depends a lot on other things which we also don't have a
lot of data on, e.g. how often mappings will be changed.

Yeah, people have an 'engineering sense' for a lot of this, but intuition is
not a 100.000% substitute for actual experience. And when you add in the fact
that it's something we can add later without too much pain, I think that's
the thinking behind a position of 'let's add these mechanisms, and study that
other one some more'.

	Noel

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 3 Sep 2009 10:11:08 -0400

Hi Noel,

I understand everything in your message, but I still don't think it is
necessary or advisable to allocate a "research bit" in the LISP header.

Dino has proposed defining _three_ new bits to support experimentation
with alternate LISP header field values: the L-bit (which indicates if
the locator status field contains locator status), the N-bit (which
indicates if the nonce field contains a nonce), and the r-bit which
(as of his latest round of edits) indicates nothing all to
implementations of the -04 specification.

Personally, I find the way the LISP header is defined in Dino's
proposed -04 document to be very awkward and inefficient, as it uses 3
bits to support one additional (not defined in -04) format.  The complex
dependencies between the three bits results in most of the
combinations of those bits being invalid/meaningless, and
implementations will have to know what to do with those combinations
if they are received.

If we anticipate that there could be more than one meaning attributed
to the bits in the LISP header, I think that it would be
preferrable to move to a 3-bit "format" field that indicates the
format of the other 61 bits.

My proposed header (which I believe accomodates the needs you've
described below) would look like this:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Form |          LISP Header Fields...                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                LISP Header Fields (cont.)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Form: The format of the LISP header fields in this header.  This
       document defines three formats:
           0 (000) -- No fields.  Remainder of LISP header should be
                      sent as zero and ignored on receipt.
           1 (001) -- Nonce present format (see below).
           2 (010) -- Locator status bits present format (see below).

The value 7 (111) is reserved allow extension of the format field.

ETRs that receive a LISP packet with an unrecognized format should
treat that packet as though it had a format value of 0 (000). The ETR
should ignore the LISP header fields, and process the packet normally.

[Note:  Do we need a format where both the Nonce bits and
the locator status bits are present at the same time?  If so,
why?]

The remainder of the bits in the LISP header are formatted as
indicated in the format field.

Nonce Present Format:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Form |  rsvd bits                                            |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Nonce (32-bits)                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Form:   LISP header format, as described above.

E:      (As in Dino's -04 proposal)

Nonce:  (As in Dino's -04 proposal)

[Note:  If this nonce is determined to be security sensitive and
needs to be longer than 32-bits, we could expand it to 60 bits by
moving the E bit to the beginning and using the rest of the
LISP header as a nonce.]

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Form |  rsvd bits                                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Locator Status Bits                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Form:                LISP header format, as described above.

Locator Status Bits: (As in Dino's -04 proposal)

[Note:  Similar to above, if we determine that more than 32
Locator Status Bits would be preferred, we could use the rsvd
bits, as well.]

If we adopt my proposal,  Luigi (or someone else) could
write a specification that defines a new format for these bits
without the need to set aside a per-proposal "R-bit" for that
purpose.  Since implementations of this proposal would
ignore unknown formats, it isn't necessary for us to allocate
the new format value in this document, as only the nodes that
understand the new format need to know the format value.

My proposal allows us to define up to 5 additional LISP header formats
using the same number of bits that Dino's current proposal uses
to support one additional format.

Margaret

On Sep 2, 2009, at 6:54 PM, Noel Chiappa wrote:

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Eliot Lear <[email-masked]>
Date: Thu, 03 Sep 2009 21:34:37 +0200

> necessary or advisable to allocate a "research bit" in the LISP header.

I'll go further.  I think adding research bits generally is a bad idea,
and in this case we are ducking an issue about version numbering.  Let's
not duck the issue.

Eliot

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 3 Sep 2009 18:09:43 -0700

> necessary or advisable to allocate a "research bit" in the LISP  

I actually agree.

> implementations of the -04 specification.

Right, we wanted to give some flexibility to the research folks. But I  
agree we shouldn't document something without clear meaning.

So I have an idea inspired by your email Margaret:

(1) Leave the N and L bit settings as defined in -04. They are used as  
"field-enable" bits.
(2) Don't have an R-bit since we cannot define how to use it or how to  
ignore it.
(3) The E-bit is still used for echo-noncing.

Now when the research guys want to use the Nonce and Loc-Status-Bits  
fields for a new use, all they have to do is set N and L to 0.  
Implementations which are spec compliant use the N and L fields when  
the "field-enable" bits are set. Otherwise, they just decap the packet  
and don't use those fields.

How does that sound?

Dino

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 4 Sep 2009 17:33:39 -0400

Hi Dino,

On Sep 3, 2009, at 9:09 PM, Dino Farinacci wrote:
>
> (1) Leave the N and L bit settings as defined in -04. They are used  
> as "field-enable" bits.
> (2) Don't have an R-bit since we cannot define how to use it or how  
> to ignore it.
> the "field-enable" bits are set. Otherwise, they just decap the  
> packet and don't use those fields.
>
> How does that sound?

That would work.

If we ever get to the point where someone wants to overload one, but  
not both, of the N & L fields, we can talk further about how to do  
that at the time (when we know what we're actually trying to  
accomplish).

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 4 Sep 2009 15:29:09 -0700

Right, agree. I have enclosed the latest diffs and proposed draft so  
everyone can start looking at the latest and greatest.

Dino

On Sep 4, 2009, at 2:33 PM, Margaret Wasserman wrote:

>> Now when the research guys want to use the Nonce and Loc-Status- 
>> Bits fields for a new use, all they have to do is set N and L to 0.  
>> Implementations which are spec compliant use the N and L fields  
>> when the "field-enable" bits are set. Otherwise, they just decap  
>> the packet and don't use those fields.
>>
>> How does that sound?
>
> That would work.
>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 Sep 2009 16:09:53 -0400

>>>>> "Margaret" == Margaret Wasserman <[email-masked]> writes:

    Margaret> Hi Dino,

    >> as "field-enable" bits.  (2) Don't have an R-bit since we
    >> cannot define how to use it or how to ignore it.  (3) The E-bit
    >> is still used for echo-noncing.
    >> 
    >> Now when the research guys want to use the Nonce and
    >> Loc-Status-Bits fields for a new use, all they have to do is
    >> set N and L to 0.  Implementations which are spec compliant use
    >> the N and L fields when the "field-enable" bits are
    >> set. Otherwise, they just decap the packet and don't use those
    >> fields.
    >> 
    >> How does that sound?

    Margaret> That would work.

As far as I can tell, no one has objected to this proposal.  Unless I
hear objections by Friday, September 18, I think we have a consensus.