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

From: [email-masked] (Noel Chiappa)
Date: Thu, 13 Aug 2009 10:40:10 -0400 (EDT)

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

    > 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.

Ecchh. A little tacky, but I guess that would work.

If we have to change the header format at any point (as we are thinking of
doing for the user-data encapsulation, to add nonce echoing), I'd prefer to
add a few more bits to that field, but that's a wish-list item. Your
suggestion is certainly a perfectly functional alternative, if the space runs
out.

    > 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 .. there
    > is no chance that the last value will be allocated without providing
    > for an extension.

Good idea.

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

Do we need a separate issue? To me, it's all part of 'protocol extensibility'
(although I guess, now that I write that phrase, that it covers a lot of
ground... :-). (It's not like I wildly object, just trying to minimize the
amount of scribal work.. :-)

    > 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?

If we had LISP running directly on IP or MPLS, I would definitely want to see
a version number field in that header. (I would not think we could use the
existing LISP user-data headers, unmodified, in either case anyway, so not
having one now in the UDP user-data header is not an issue to me.)

    > 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. 

Well, remember, this is only user-data traffic we're considering. There will
be control traffic between the two xTRs, which will allow them to figure out
which version of LISP they are running, etc.

Although maybe we should make sure the Map-Reply message can indicate
something about the version status of the xTR in question? I had sort of
assumed that the ability to reply with multiple RLOCs, with a different AFI
for each, would be enough, but maybe not? We could use different AFI's as a
proxy (e.g. have 4 AFI's assigned for IPv4, to indicate different IPv4
encapsulations...) Not sure if that's feasible - we should be able to have
LISP-specific AFI space values, I would think?

    > If we include a version field in the LISP data header, we could also
    > define an error message .. 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.

Again, we have a separate control-plane channel. So an xTR can easily check
to see if another node is running LISP by sending a LISP control-plane
message to it. If a particular user-data UDP encapsulation _then_ produces an
ICMP error, that pretty much says 'this encapsulation not supported'.

Or we could define a control-plane interaction to ask/reply what user-data
encapsulations are supported. And there's always the Map-Reply thing (above),
too.

	Noel

---

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

> amount of scribal work.. :-)

Sorry, I didn't realize (or forgot) that there was already an issue  
open for this.

> encapsulations are supported. And there's always the Map-Reply thing  

These are good points.  A control-plane mechanism to determine what  
version(s) of LISP an xTR supports (whether it is part of the mapping  
reply or a separate control message) would address most of my reasons  
for wanting a LISP data header version.  If necessary, the control  
plane could even be used to negotiate what version to use.  This  
negotiation could be very simple, like we use the highest version we  
both support, but it would make it clear what version of LISP data  
packets the ETR should expect to receive from a specific ITR.

Margaret