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

From: [email-masked] (Noel Chiappa)
Date: Thu, 3 Sep 2009 15:08:41 -0400 (EDT)

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

    >> I think it's very important to do so to maximize future flexibility of
    >> new piggybacked control functions, should be find we need them.

    > I am not talking about why we want to piggyback in general... 

Right, but I wasn't talking about that either.

    > pre-define the LISP header to have a flags section, and two separate
    > fields (one 24-bit field and one 32-bit field) that are controlled
    > separately.
    > I don't know why we wouldn't want to view the LISP header as one big
    > field

Well, if we really need a 56-bit field, we can do that; in fact, that's what
sort of what the original definition of the R-bit tried to do. I personally
feel that the need for such a field is unlikely, but that's not very
probative, of course.

    > If we come up with 6 different ways to use that 32-bit field, are you
    > assuming we will have 6 mutually exclusive bits to control the contents
    > of that one field

Possibly, but it's hard to say, in such a vacuum. There might be a couple of
different functions grouped together, with one 'master' bit to select them,
e.g. the way nonces are done.

    > would it be better to set aside a small number of bits and use all of
    > their values to indicate what is in the field

I suggested something very vaguely similar to this, in the sense that it
tried to predefine some limited semantics for some 'unused' bits. (The actual
idea was: have a group of bits which, if set, and you don't understand that
bit, you don't process the packet; and another group which, if set, and you
don't understand the bit, you just ignore the bit.) However, it seemed that
leaving them completely undefined was the most flexible thing to do.

    > I wasn't really suggesting a bit in the locator-status field. I was
    > suggesting something like: If it is zero, it isn't in use. If it is
    > non-zero it is significant. Because if all of the RLOCs for an EID are
    > down, there isn't anyone left to send that message.

Ah, OK, got it. Still, that doesn't help me do something else with the field
(which would almost certainly involve its being non-zero).

    > What is he date in the version you are referring to?

Umm, it was a message to the list, let me see... here it is:

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

with an editing error in the first one fixed in the latter one.

    >> we would need an exponentially-increasing number of values to signal
    >> different combinations.

    > Ummm... more bits is the _same_ as exponentially increasing numbers of
    > values. The values path will always have the same number of bits
    > (except when it has less bits, because some combinations are invalid).

Good point. So it would be more the issue of the decoding logic (to control
what happens) being more complicated - which might be an issue for high-end
(hardware) routers. (In addition to the previous point about deploying new
functions in parallel with existing ones).

    > My model doesn't mandate that an ITR do that either... How does
    > representing the same information in a different set of bits require
    > you to do any logic you aren't already doing?

That was all in response to your original proposal, in which packets could
contain either a nonce, or Locator-Status bits, but not both (you didn't
originally define a format for a packet that could contain both).

    > why do you want to ping your neighbors all of the time?

To make sure that they are up and reachable (i.e. that there's not some
problem in the network between source A and destination B which is preventing
packets from getting from A to B, even though A and B are both up, e.g. a
routing problem in some intermediate ISP).

I gather that this is really a fairly hot issue for many potential users -
they really want reliability, no mysterious traffic black holes (can't say I
blame them :-).

Also, I wish we had a better term than 'neighbours' for 'partner xTR',
because those 'neighbours' may in fact be on the other side of the Internet;
I think the term 'neighbour' can give an incorrect subliminal sense of how
many, how far, etc.

    > You have not offered any argument that I understand for why this is not
    > good for hardware implementations.

It's just much easier to look at a single bit and say 'oh, this bit is on,
therefore I need to do [this function]', rather than have to do some complex
table thing and say 'oh, the value of this field is one of {2,5,6}, therefore
I need to do [this function]'.

	Noel