Subject: Re: [lisp] #5: LISP protocol version is alive and kicking

From: [email-masked] (Noel Chiappa)
Date: Fri, 18 Sep 2009 13:37:04 -0400 (EDT)

> From: Damien Saucez <[email-masked]>

    >> I believe what is needed is a data plane version number in the
    >> control protocol.

    > but then you need an extra rtt for the negotiation. 

No; if the map entry has a bit that says 'this ETR supports version 2',
and the ITR understands that bit and has support for version 2, it can
send version 2 packets right away. There's no delay - at least, any more
than you need to get the mapping itself (and clearly you can't send
anything anywhere without the mapping).

A bigger issue with versions, _no matter how you support them_ (field in
the header, port, mapping, whatever), is compatability. Either all nodes
have keep support for old versions essentially forever, or you might get
pairwise non-communication. I do not have time to analyze this fully at
the moment, though.

    > With a protocol version number, we can thus tests different
    > solutions to see which are the best.

If it's really just a limited experiment, you can use a different port number,
or set a header bit (we have several spares), or use a currently-illegal
combination of header flag bits (if you need a whole different header format,
on the same port), or something. The protocol police aren't going to come
arrest you for sending packets with unauthorized bits set.

    > Do we really need to care about legacy in this WG?

For right now, no. But for the future, yes, and some decisions we are
making now will have an impact for a long time. (Been there, done that...)

    > I believe that we are going in a wrong direction with the trend of
    > adding more and more state.

See http://mercury.lcs.mit.edu/~jnc/tech/end_end.html, in particular the
section at the end headed "Network State".

I am reminded of Abraham Lincoln's astute answer to the question 'How long
should a person's legs be?' His answer: 'Long enough to reach the ground.'
Yes, state _is_ 'bad' architecturally, in that if you don't have it, things
stop working. So then you have to deal with that. But if we have to have state
to reach some goal, we have to have it - and pay the cost of getting it,
maintaining it, etc, etc.

    > I do prefer having redundant information ... than having to keep
    > state and then build a complex control protocol to maintain all this
    > state coherent.

I think we have to look at each case on its merits, and look at the
details. In this particular case, we already _have_ to have the mappings, and
the whole system to distribute them, etc, etc so adding more data field(s) to
the mapping is a 'so what' to me.

    > Do we really need to make the LISP header as smaller as possible for
    > the sacrosanct MTU?

It's not just the sheer size. A bigger header is a more complicated
header, which means it's slower to construct, and to process, and we pay
that price on _every user data packet_.

    > if every protocol does that, the port space will be exhausted
    > rapidly.

Yes, but I think basic data carriage (like IPvN, LISP, etc) is a whole
different 'kettle of fish', in terms of design philosophy, from
applications, for a number of reasons which I assume are fairly obvious.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Mon, 21 Sep 2009 22:13:10 -0400 (EDT)

> From: "Darrel Lewis (darlewis)" <[email-masked]>

    >> If b2 never got a mapping for A (because it got neither user-traffic
    >> which it could glean a mapping for A from, nor a Map-Request with
    >> piggybacked information for A), how is it going to get a mapping for A
    >> unless either i) it talks to its fellow ETR b1, or ii) it goes through
    >> a mapping-resolution cycle on A?

    > Right it goes through a mapping resolution cycle. 

Well, that's what people don't like - the RTT (at least) to get a mapping back.

And you've also got the issue of 'what do you do with the return packet in
the interim', which we have touched on before - do you queue it, discard it,
what? If you discard it, as discussed before, you've got to wait for someone
to timeout, and re-transmit.

Add to this the notion that most interactions on the network these days are
client-server, and in the example above, the server is going to be B. So the
server's not going to be able to get the reply back to the user without an
RTT. I suspect most content providers will find that unacceptable. And if you
_drop_ the return packet, because you don't have a mapping - they will not be
happy.

There are other ways to solve this particular problem, e.g. make sure that
traffic both to and from EIDs E0-EN is sent through xTR bj, so you don't get
square/triangle routing. But I'm not sure people will find that acceptable.

(And BTW I think we also get this with triangle routing, i.e. with traffic
flowing a->b1->server->b2->a.)

	Noel

---

From: Terry Manderson <[email-masked]>
Date: Tue, 22 Sep 2009 04:10:33 -0700

So you have probably just seen that I have summarized this issue to into the
tracker.

Please review and let me know if you think I have misread or
mischaracterized anything that was discussed.

Speaking now as an individual, it looks like we are now taking a circular
motion with #5, my personal observations of the discussion stands as:

a) only one control plane version should exist.
b) data plane versions are handled by the control plane.
(map-request/map-reply structures)
c) No extra RTT is desired.
d) Experimentation (versions) can occur outside of RFC compliance.
e) Some state is required, but no more than necessary (as required in
mapping.)
f) keeping the data header simpler is a bigger win.
g) TTL (clock sweep) can be used to maintain ITR mapping freshness.
h) having the versions in the map-reply encounters square routing issues,
and requires the ITR to do an RTT to get map-info. see "c".

Thus far I don't see any convergence on what the version looks like in the
map-request/map-reply (type value or otherwise)

And it appears that an answer to deal with the 'unwanted' RTT in "h" is
needed in light of no data gleaning.

Is this a fair approximation of the current position?

Cheers
Terry