IETF Logo Mail Archive

Re: [lisp] Questions about draft-saucez-lisp-itr-graceful-03

Dino Farinacci <farinacci@gmail.com> Wed, 19 February 2014 16:40 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05AB1A05CF for <lisp@ietfa.amsl.com>; Wed, 19 Feb 2014 08:40:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uk70uxJRQj8i for <lisp@ietfa.amsl.com>; Wed, 19 Feb 2014 08:39:56 -0800 (PST)
Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 263C01A05E0 for <lisp@ietf.org>; Wed, 19 Feb 2014 08:39:54 -0800 (PST)
Received: by mail-pd0-f179.google.com with SMTP id fp1so596030pdb.10 for <lisp@ietf.org>; Wed, 19 Feb 2014 08:39:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=D7xn0ORWWNmNvnT7tqLabX6uCW5o0Pux63/4tSwCFnE=; b=kByHraziebBdJk1lgUJjEvlJ2S1zUuGlkWOFecLjUrCsFUbqkIiYkrwAnexpBNmr9V /aCD1idOc7EONxJn1XLM8Sn60rgX29RyVuladHyKv6+KqOkhhp8aOjXwAcMMN7nnb/l/ OevYckaqJQ81pW6Zu+sgLq+nQ4E0kOfT6zPh3NH7tJXjv/ED/ZJZUOftvUOZbWdcc6Xg IzBc2i6GIDgQ2eFW2vVwefJTI19dFWYzXN1rB0RJUeQFar8VYvP+KXhFg10gaqF+UF2F 8jhycUQzAiGnSFlb6VR5WVZHKjfW/zfzOUTiHcoFsJTLFlvl9dOaO/+UDcmNkF9455qf RHZA==
X-Received: by 10.66.179.7 with SMTP id dc7mr3411646pac.47.1392827991019; Wed, 19 Feb 2014 08:39:51 -0800 (PST)
Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id lh13sm4920027pab.4.2014.02.19.08.39.49 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 08:39:50 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <A5E2D567-7C8D-4024-AE61-CFDA9400123A@inria.fr>
Date: Wed, 19 Feb 2014 08:39:47 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <A948F13B-023B-43FB-92EC-D4DA6A832404@gmail.com>
References: <20140218144825842648.087ffc67@sniff.de> <5689A37C-B58A-4144-AB01-A61DFCE1B999@gmail.com> <A5E2D567-7C8D-4024-AE61-CFDA9400123A@inria.fr>
To: Damien Saucez <damien.saucez@inria.fr>
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/z0s-Me3NIehaBCNEYMzW-QKgBnc
Cc: Clarence Filsfils <cf@cisco.com>, Luigi Iannone <luigi.iannone@telecom-paristech.fr>, LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] Questions about draft-saucez-lisp-itr-graceful-03
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2014 16:40:03 -0000

On 19 Feb 2014, at 00:45, Dino Farinacci <farinacci@gmail.com> wrote:
> 
>> 
>>> Or if you want to solve only the cache-miss storm when ITR1 comes back 
>>> into the traffic stream then the ITR deflection has the advantage to 
>>> not require any cache-synchronization protocol, IMHO. The rate of 
>>> Map-Requests could be throttled to turn the storm into a breeze. The 
>>> method how to transport traffic to ITR2 could be one of many - a direct 
>>> LAN, GRE, Lisp.
>> 
>> Or just make it a local matter and have ITR1 read its checkpoint file that it had written the last time before it crashed. These sort of problems could be solved better with implementation design and not protocol design.
>> 
> 
> As a matter of fact, this is probably the simplest solution.  However
> that implies that routers are down for period of time shorter than the
> lifetime of entries in the cache.  Unfortunately, this solution only
> prevents storms for the startup, not for the shutdown.

I am not following your logic.

Dino

> 
> Damien Saucez
> 
>> Dino
>> 
>

v2.23.0 | Report a Bug | By Email