Subject: Re: [lisp] #5: protocol version in lisp header

From: "lisp issue tracker" <[email-masked]>
Date: Tue, 22 Sep 2009 10:42:58 -0000

#5: protocol version in lisp header
----------------------------------+-----------------------------------------
Reporter:  [email-masked]  |        Owner:                 
    Type:  technical              |       Status:  new            
Priority:  minor                  |    Component:  draft-ietf-lisp
Severity:  -                      |   Resolution:                 
Keywords:                         |  
----------------------------------+-----------------------------------------

Comment(by [email-masked]):

 Summary of #5 LISP protocol version, as of 21/09/09

 # Participants: 9.

 * 12/08/09 Margaret recommends that a protocol provide for its own
 versioning with its own field. (not use new port numbers for new versions)
 * 12/08/09 Joel is inclined towards port number with the reason that a new
 version is a new protocol. (but notes IANA issues about consumption of
 port numbers)
 * 13/08/09 Lars notes an IANA recommendation to include a version field
 * 13/08/09 Noel floats that are two areas to consider, control traffic and
 user-data traffic. For control-traffic suggests to use op-codes for
 version functionality, but be sure to handle unrecognized op-codes. For
 user-data protocol changes, modify port numbers.
 * 13/08/09 Margaret thinks that op-codes in versioning are a reasonable
 choice with "all ones" to escape to additional types, with appropriate
 response to unrecognized op-codes. In user-data space She sees that
 unknown expansion directions suggest that a version field in a LISP data
 header is needed.
 * 13/08/09 Noel thinks "all ones" is workable, however would prefer to add
 more bits to the field as a wish list. Noel further highlights that xTRs
 will work out which versions of LISP they run via control traffic.
 Suggests expanding Map-Reply to indicate version.
 * 13/08/09 Margaret posits that a map-reply mechanism addresses her
 reasons for a LISP data header version.
 * 17/08/09 Eliot (as a IANA expert reviewer) suggests in general the
 review would be harsh on a application for a port, without a version #.
 Further suggests that LISP is unique, and he (if he were the reviewer)
 would approve without a version #.
 * 10/09/09 Damien writes that control-traffic is a good idea to negotiate
 a version in use, however a version field still helpful. (ie for gleaning
 and simplification of version negotiation.)
 * 11/09/09 Dino posts an example of mapping and map-cache and states that
 version numbers are not needed.
 * 11/09/09 Damien clarifies that this is not map-version, but LISP version
 * 11/09/09 Dino suggests that you can't trust the encapsulator in data
 gleaning (wrt version number). Further highlights that you don't want to
 negotiate due to packet exchanges (and potential packet drops)
 * 11/09/09 Damien suggests versions (in data gleaning) is a hint, akin to
 reach-bit.
 * 17/09/09 Sam (Chair) posts a request for progress.
 * 18/09/09 Damien agrees that negotiation isn't really needed with an
 example.
 * 18/09/09 Dino responds that he believes a protocol version field isn't
 needed in the data header as it can be implemented with a new UDP port
 number.
 * 18/09/09 Damien replies that he doesn't like the multiple port number
 consumption for multiple versions (citing number exhaustion), suggesting
 reserving 8 bits for a version field.
 * 18/09/09 Dino thinks that a version number is no different than a new
 type value for a control packet (map-request). Further suggests that it
 may lead to the belief that protocol versions are different per EID (in
 mapping transactions)
 * 18/09/09 Joel Suggests that what is needed is a data-plane version
 number carried in the control plane (using map-request/map-reply). That
 multiple versions of the control plane protocol acquire round trips and a
 single version only exist ( else == nightmare).
 * 18/09/09 Damien suggests you need an extra RTT for the version in the
 control protocol and then highlights that the WG is focused on
 experimentation we can use version numbers for different solutions. Also
 he suggests that the current trend adds more state and requires a complex
 control protocol. Iterates the dislike of a port number per version.
 * 18/09/09 Dino agrees with Joel (18/09/09).
 * 18/09/09 Noel clarifies that no extra RTT is needed as the ITR can send
 packets in the right version immediately based on the map-reply. He
 highlights that the bigger issue with versions is compatibility. Either
 all-nodes support old versions for ever, or non-communication occurs. In
 experimentation you can use other items (such as bits/ports/etc). He
 suggests state is required. He suggests that header processing is a bigger
 consumption cost.
 * 21/09/09 Sam posts to clarify Damien's concern regarding the need for
 version information in the data packet header.
 * 21/09/09 Damien responds that in a communication with a LISP site a map
 reply for the site specifies what version it can receive, and if data
 gleaning is not used an map-request is used to learn the version of the
 LISP site for the return data. However thinks that it doesn't address his
 problem.
 * 21/09/09 Noel follows up to Sam to agree that where a site is using
 gleaned map cache info, it may not have any state, other than the first
 packet to know what version to respond with. He concurs with the
 observation regarding square routing the map request and data packet are
 destined for different locations. Noel moots that answers are painful.
 * 21/09/09 Darrel moots that TTL (clock sweep) based versioning looks
 attractive
 * 21/09/09 Sam asks for clarification on clock sweep.
 * 21/09/09 Darrel responds that clock sweep is a mechanism to allow a site
 to set TTL which means the ITR will request a new mapping at TTL expire.
 * 21/09/09 Sam is no wiser for the clarification in light of communication
 between two XTRs.
 * 21/09/09 Darrel suggests that if the data-plane version changes it is
 reflected in the map-request/map-reply which updates the ITR side.
 * 21/09/09 Noel is confused how cache freshness helps with the square
 routing problem. He also asks for better terminology. He puts forward an
 question with example of how a ITR is to get mapping information.
 * 21/09/09 Darrel says it goes through a mapping resolution cycle. "this
 is a feature". The ETR could then use TTL (clock sweep) if the header
 version changes to trigger freshness in the ITRs
 * 21/09/09 Noel suggests that extra mapping resolution (RTT) is what
 people don't like. It also questions what happens to the return packet
 during RTT. One option (probably unacceptable) is to force traffic through
 an xTR so square routing doesn't occur.

-- 
Ticket URL: <http://tools.ietf.org/wg/lisp/trac/ticket/5#comment:1>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues