Opened 10 years ago

Closed 9 years ago

#5 closed technical (fixed)

protocol version in lisp header

Reported by: hartmans-ietf@… Owned by:
Priority: minor Component: draft-ietf-lisp
Severity: - Keywords:
Cc:

Description

Discussion earlier on the list focused on whether there was 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.
This issue tracks that discussion.

Unless someone objects by August 20, I'll conclude that the consensus
of the WG is that no version is needed.

Change History (4)

comment:1 Changed 10 years ago by terry.manderson@…

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.

comment:2 Changed 10 years ago by hartmans-ietf@…

Terry summarized the discussion. There were a few messages past that
point. No consensus call was made by the chairs at the time, however
it is likely that this issue is ready for someone to try for the
second time to close this issue out as no consensus to do anything
concrete. call again

comment:3 Changed 9 years ago by terry.manderson@…

  • Resolution set to fixed
  • Status changed from new to resolved

As this issue evolved into map versioning it has been subsumed by the document lisp-map-versioning. Closing this issue here. Further concerns should be raised against lisp-map-versioning.

comment:4 Changed 9 years ago by terry.manderson@…

  • Status changed from resolved to closed
Note: See TracTickets for help on using tickets.