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

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

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

    > If no version information is included in the packet, then the site
    > may not know what version to use in its responses. ...
    > in the case where the site is going to use gleaned map cache
    > information, it may not have anything other than that first packet
    > to find out what version to use.

Light dawns over famous Massachussetts fishing harbour... :-) Sorry I was
a bit slow to catch on.

Yeah, that's a problem. (Puts on thinking cap, goes away to ponder for a
few days...)

    > You might argue that the map request could have carried your version
    > information. However, because of square routing and other concerns,
    > the map request and data packet may go to different places.

That's a general problem with square routing (i.e. packets from site A to
B flow from ITR a1 to ETR b1, packets back from B to A flow via ITR b2 and
ETR a2), and not just with the version information - the b2 ITR doesn't
have the mapping, either.

I've had it kicking around the back of my brain for a while now, but no
great hack has appeared. I suspect the only answers are painful (e.g.
better co-ordination between all the xTRs at a site - which we might need
anyway, for other reasons).

	Noel

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 21 Sep 2009 13:45:41 -0700

> anyway, for other reasons).

To me, all of this discussion makes TTL (called clock sweep in the draft
if I remember correctly) based versioning better and better.  It works,
and keeps all of this complexity out of the protocol.

-Darrel

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Sep 2009 17:27:27 -0400

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

    >> 
    >> I've had it kicking around the back of my brain for a while
    >> now, but no great hack has appeared. I suspect the only answers
    >> are painful (e.g.  better co-ordination between all the xTRs at
    >> a site - which we might need anyway, for other reasons).
    >> 
    >> Noel

    Darrel> To me, all of this discussion makes TTL (called clock
    Darrel> sweep in the draft if I remember correctly) based
    Darrel> versioning better and better.  It works, and keeps all of
    Darrel> this complexity out of the protocol.

I'm sorry I don't follow you at all.  I guess mostly I don't follow
how clock sweep is related to the discussion, which probably means I'm
just missing a logical jump.
I'm certainly not disagreeing with setting your ttl correctly

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 21 Sep 2009 15:25:06 -0700

> I'm sorry I don't follow you at all.  

Sorry, I'll try to rephrase and provide an example below.

> I guess mostly I don't follow

TTL versioning (called clock sweep) is a mechanism that uses operational
techniques to update remote site's cache state.

Say a site has this mapping:

EID Foo, RLOC Bar1 - priority 1, weight 100
EID Foo, RLOC Bar2 - priority 2, weight 100

And wants to change it to:

EID Foo, RLOC Bar1 - priority 1, weight 50
EID Foo, RLOC Bar2 - priority 1, weight 50

They can inform other sites via SMR bit map-requests (with the caveats
we've been discussing), or they can set the TTL so that prior to the
change the remote ITRs will have a short TTL and will request a new
mapping (which will reflect the new settings) soon after the change is
made.

So Protocol mechanisms (of the various proposals we've been discussing)
for versioning have the same result as the TTL method. 

Hope that clears things up.

-Darrel

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Sep 2009 18:34:31 -0400

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

    Darrel> So Protocol mechanisms (of the various proposals we've
    Darrel> been discussing) for versioning have the same result as
    Darrel> the TTL method.

    Darrel> Hope that clears things up.

Not really.  I'm still very confused how this has to do with
versioning of what data encapsulation I use between two XTRs, which is
what we were discussing here.

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 21 Sep 2009 15:38:32 -0700

> what we were discussing here.

If the data plane version (the example I used was the mapping version)
changes, and its indicated in the map-request/map-reply, then
instigating that message exchange will update the ITR side of the
conversation.

-Darrel