#5: protocol version in lisp header
----------------------------------+-----------------------------------------
Reporter: hartmans-ietf at mit.edu | Owner:
Type: technical | Status: new
Priority: minor | Component: draft-ietf-lisp
Severity: - | Resolution:
Keywords: |
----------------------------------+-----------------------------------------
Comment(by terry.manderson at icann.org):
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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.