[lisp] Fwd: New Version Notification for draft-iannone-lisp-mapping-versioning-01

[Luigi Iannone <[e-mail]>]

Hi All,

We recently updated the draft concerning lisp mapping versioning.

Most important changes are the following:

- Version numbers are now 16 bits
- Detailed description of packet encodings. No new packets are necessary anymore, mapping versioning uses part of the reserved bits in both the LISP specific header and mapping records.
- The proposed mechanism is totally transparent for nodes that do not support versioning, thus incremental deployment is feasible and discussion on the topic has been added to the draft.  
- We describe in more details the benefits introduced by mapping versioning including:
	- Versioning and interworking
	- Versioning and mapping synchronization
	- Versioning and unidirectional traffic
	- Versioning vs. checksum
	- Versioning and mobility
	- Security aspects

All comments are welcome

Luigi

Begin forwarded message:

> From: IETF I-D Submission Tool <[e-mail]>
> Date: March 8, 2010 7:48:20 PM GMT+01:00
> To: [e-mail]
> Cc: [e-mail],[e-mail]
> Subject: New Version Notification for draft-iannone-lisp-mapping-versioning-01 
> 
> 
> A new version of I-D, draft-iannone-lisp-mapping-versioning-01.txt has been successfuly submitted by Luigi Iannone and posted to the IETF repository.
> 
> Filename:	 draft-iannone-lisp-mapping-versioning
> Revision:	 01
> Title:		 LISP Mapping Versioning
> Creation_date:	 2010-03-08
> WG ID:		 Independent Submission
> Number_of_pages: 25
> 
> Abstract:
> The present document sketches an optional approach to provide in-
> packet information about EID-to-RLOC mappings used to encapsulate
> LISP data packets.  The proposed approach is based on associating a
> version number to EID-to-RLOC mappings and transport such a version
> number in the LISP specific header of LISP-encapsulated packets.
> This versioning approach is particularly useful to inform
> communicating xTRs about modification of the mappings used to
> encapsulate packets.  Modification of mappings could mean adding/
> removing an RLOC, or just a modification in the reachability,
> priority, or weight of one or more RLOCs.  Each time a mapping is
> modified, a new version number is generated and propagated in the
> LISP data packet.  The use of version numbers allows to avoid
> repeated Map-Request upon mappings change, limits the interaction
> between Control and Data planes, improves security, offer support for
> caching on Map-Servers, and could be used also in mobile scenarios.
> 
> The proposed mechanism is optional and does not need any modification
> on the base LISP encapsulation.  Rather, it uses one of the reserved
> bits of the LISP specific header and overloads the Locator Status
> Bits.  Similarly, no modification are necessary in the base LISP Map-
> Reply records.  LISP versioning uses part of the reserved bits.  In
> both cases, LISP encapsulation and Map-Reply records, bits used for
> LISP versioning can be safely ignored by xTRs that do not support the
> mechanism.  Further, mappings can be distributed as usual through
> both existing and future mapping distribution system (e.g., ALT).
> The infrastructure build by each specific mapping distribution system
> does not change anyhow.  Even more, existing mapping distribution
> protocol are able to rely LISP control plane packets containing
> version numbers and do not need modifications.  All of these features
> make LISP versioning a completely transparent optional mechanism with
> respect to the LISP base specification.
> 
> 
> 
> The IETF Secretariat.
> 
>