FYI

Begin forwarded message:

> From: [email protected]
> Subject: New Version Notification for draft-saucez-lisp-itr-graceful-00.txt
> Date: 1 Jul 2012 13:31:17 GMT+02:00
> To: [email protected]
> Cc: [email protected], [email protected], 
> [email protected]
> 
> 
> A new version of I-D, draft-saucez-lisp-itr-graceful-00.txt
> has been successfully submitted by Damien Saucez and posted to the
> IETF repository.
> 
> Filename:      draft-saucez-lisp-itr-graceful
> Revision:      00
> Title:                 LISP ITR Graceful Restart
> Creation date:         2012-07-01
> WG ID:                 Individual Submission
> Number of pages: 11
> URL:             
> http://www.ietf.org/internet-drafts/draft-saucez-lisp-itr-graceful-00.txt
> Status:          
> http://datatracker.ietf.org/doc/draft-saucez-lisp-itr-graceful
> Htmlized:        http://tools.ietf.org/html/draft-saucez-lisp-itr-graceful-00
> 
> 
> Abstract:
>   The Locator/ID Separation Protocol (LISP) is a map-and-encap
>   mechanism to enable the communication between hosts identified with
>   their Endpoint IDentifier (EID) over the Internet where EIDs are not
>   routable.  To do so, packets toward EIDs are encapsulated in packets
>   with routing locators (RLOCs) to form dynamic tunnels.  An Ingress
>   Tunnel Router (ITR) that encapsulates EID packets determines tunnel
>   endpoints via mappings that associate EIDs to RLOCs.  Before
>   encapsulating a packet, the ITR queries the mapping system to obtain
>   the mapping associated to the EID of the packet it must encapsulate.
>   Such mapping is cached by the ITR in its local EID-to-RLOC cache for
>   any subsequent encapsulation for the same EID.  LISP is scalable
>   because the EID-to-RLOC cache of an ITR, which is initially empty, is
>   populated progressively according to the traffic going through the
>   ITR.  However, after an ITR is restarted, e.g., for maintenance
>   reason, its cache is empty which means that all packets that are re-
>   routed to the freshly restarted ITR will cause cache misses and a
>   potentially high loss rate.  In this draft, we present mechanisms to
>   reduce the negative impact on traffic caused by the restart of an ITR
>   in a LISP network.
> 
> 
> 
> 
> The IETF Secretariat

_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to