Subject: Re: [lisp] [#5] LISP protocol version

From: [email-masked] (Noel Chiappa)
Date: Thu, 13 Aug 2009 08:44:12 -0400 (EDT)

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

    > a need for an explicit lisp protocol version in the header. Several
    > participants argued that LISP could change its port if a new version
    > was needed.

I think it's important to recognize that there are two different cases to
consider: control traffic, and user-data traffic.

For control-traffic, I pointed out in the prior discussion that we have the
op-code (or whatever it's called, too lazy to go look), and we can use new
op-codes to extend/modify the control-plane part of the protocol. As far as I
can see, that offers equivalent flexibiilty/capabilities of a 'version'
field. So we'd only have to use the new port thingy if we wanted to modify
the user-data carriage protocol.

Another possibility for changing the user-data protocol, _if LISP comes into
wide-spread service_, is a custom protocol (i.e. directly on top of IP).
Other evolution directions I have thought about for new user-data
encapsulations include custom non-IPvN inter-xTR encapsulations (e.g. inside
MPLS headers).

(And, if it's widely used, I don't think another UDP port would be that
difficult - we've been allocating UDP ports to some pretty rarely-used
protocols...)

My contention in the prior debate is that at this point it's not possible to
pick a particular expansion direction at this time, that in making that
choice we'll probably need data we don't have now, and that simply
demonstrating that there are viable/plausible extension/change mechanisms
available is about all we can do now.

One exception to that general line of reasoning (leave the future to the
future) is that I think we ought to define, at this point, a specific
behaviour to respond to unrecognized op-codes, so that we can later define
some sort of mechanism to negotiate control-plane upgrades.

I.e. if an xTR gets a control code it doesn't recognize, it should return the
entire thing, in an 'unrecognized control-type' error message, to the sending
xTR. That way, if an upgraded xTR tries to talk to an un-upgraded xTR, it'll
be able to tell that the other one doesn't grok the new stuff, and there can
be some sort of interaction to work out what they have in common.

(This is an example of my general strategy of trying to leave the right
'hooks' for the future, _iff_ LISP is successful.)

	Noel

---

From: Sam Hartman <[email-masked]>
Date: Thu, 13 Aug 2009 09:43:37 -0400

It sounds like you would be OK doing the following:

1) Documenting behavior for unknown control message types

2) Indicating in the document that there are multiple directions we
could go for data protocol extension including a new UDP port as one
option.

Do I have it right?

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 13 Aug 2009 10:08:52 -0400

Hi Noel,

On Aug 13, 2009, at 8:44 AM, Noel Chiappa wrote:
> op-codes to extend/modify the control-plane part of the protocol.

I think you are referring to the 4-bit "type" field at the beginning  
of all of the control packet headers.

> As far as I

It is true that different LISP packet types have different formats, so  
the format does vary based on the value of the type field. The field  
is 4-bits long (16 values), and 8 of the 16 values have already been  
allocated, but we could easily make more space by using type 15 (all  
ones) as an escape to additional types.  So, I think this is a  
reasonable choice.
> some sort of mechanism to negotiate control-plane upgrades.

Yes, this would be a good idea.  We might also want to explicitly  
reserve 15 as an extension mechanism, so that when we send the  
registry for these types off to IANA (with whatever IANA  
considerations we devise) there is no chance that the last value will  
be allocated without providing for an extension.
> 'hooks' for the future, _iff_ LISP is successful.)

This mechanism makes sense to me.

Perhaps one of the authors should open an issue for this, so that we  
make sure that the text gets into the -04 version?

> available is about all we can do now.

While its true that we could extend and modify LISP in a number of  
ways including defining additional encapsulations, I actually consider  
this to be an argument _for_ LISP data headers having a version field,  
rather than relying on UDP port numbers.  Because we might not always  
have UDP available to tell us what version of the LISP header this  
is...  Or would you expect to obtain multiple IP protocol or next- 
header values to denote different LISP versions directly over IP?  And  
different MPLS protocol types to denote different versions of LISP  
over MPLS?  etc?

If a LISP data packet of the current version is transmitted using MPLS  
over carrier pigeon, it should still be recognizable as the same  
version of the LISP protocol.  However, if we need to change the LISP  
data header in the future, it would be good if receiving nodes could  
unambiguously recognize that they are dealing with a new LISP data  
header version, without relying on the lower layer to demultiplex.

Relying on the lower layer to demultiplex between different LISP  
versions makes it impossible for an ITR to distinguish between a  
destination node that doesn't implement LISP and an ETR that  
implements a different version of LISP.  If we include a version field  
in the LISP data header, we could also define an error message (the  
same in all versions) that is sent by an ETR when it receives a LISP  
data packet that isn't the right version.  If we just use UDP ports to  
demultiplex, though, the packet will be dropped with a much less  
specific ICMP "port unreachable" error -- the same error you would get  
if the destination did not implement LISP at all.

Margaret