Re: [lisp] Review 6830bis -08/-09

Luigi Iannone <> Mon, 29 January 2018 12:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62A1112EAE4 for <>; Mon, 29 Jan 2018 04:28:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iE1X1KdsUXOZ for <>; Mon, 29 Jan 2018 04:28:39 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5EB1B12EAAB for <>; Mon, 29 Jan 2018 04:28:39 -0800 (PST)
Received: by with SMTP id i56so6983047wra.7 for <>; Mon, 29 Jan 2018 04:28:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ciiHn3zpWh7RyTcxnV4BMPgDF/8kR6vM4tYJPy6UGIc=; b=W0KH9asWDoV0o711ZyQ1bvLB0DLJ+D9v8utaNqUaULYVIoYOkXQGHQt6+C+x3iIcIe g+ikJDmmv6KCjHQp96VSZ/6oPL7u3cyi9DBtCXWOJiWk1X855tfKTvLvLLX/9vCheoAt 92ENrnR3t/CpNjCqur+ueQ5T9rAF4MaoIRAs9xuBkGMmMzxsBhH3C1o5EkkfKW+v/2hS YjSFOnsei6W+A+Uof1ehut9DPlxW+1cu2T2H2XeWx2jpP1bh42v6LRVLBR/QhYvS0uv4 heDh9AdaxMEIL8DpuNLTWvcbZ9m9UV3fSo61KZBcDNRlD21Bp2QZDlD8uKsU9eTKq8E5 N0Fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ciiHn3zpWh7RyTcxnV4BMPgDF/8kR6vM4tYJPy6UGIc=; b=meCs0bG7TUKxY8IjW2vAFtUKr9ug8JGPJqMoxZ0tqLYhf5NvDQsBLFm3FQrcWJjLJc 4aCCgwpkEVE56wfljXD/wEncZWLfwHbM98kjw+1q8TRVX1Dduvy+1IUxm/OLwZSJwkHc UyZsyg6f1XJTwqD+5tf4WxztXnATCJ9pOid33SIxCUmdceQ/9Cu0yEbPalVB37dwJdm9 Fk7j4cqX9HlNKFgyECd7NoELDyB3Wthio2LIrlJlIyzPex8XFe4zrxTjQWHr+Xxk2fNi 41r4Z+Ki5P6gjkvW3XiRkCFLht1HfZE5uLQfMw9wfbQNLeT7Bz3o9yU6WOhZuwClHfuL P3wg==
X-Gm-Message-State: AKwxytc6KrXb+8b3315W4Tg6Wktu9UTNqHutQY3MjoJeVEsTq/GXPS7d 80YBVSNOgvFHdncesRJHsOexOw==
X-Google-Smtp-Source: AH8x224SvKBBezBwX1JamXROEX8Mp5uvkNd8l/wuFgOECHbSD/WhsOweqlxuPiV86AjsGMMVrq+hAA==
X-Received: by with SMTP id p11mr18765972wrd.26.1517228917776; Mon, 29 Jan 2018 04:28:37 -0800 (PST)
Received: from ?IPv6:2001:660:330f:a4:f979:e58f:32c7:361c? ([2001:660:330f:a4:f979:e58f:32c7:361c]) by with ESMTPSA id l92sm19723845wrc.31.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jan 2018 04:28:36 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Luigi Iannone <>
In-Reply-To: <>
Date: Mon, 29 Jan 2018 13:29:03 +0100
Cc: " list" <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Dino Farinacci <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [lisp] Review 6830bis -08/-09
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Jan 2018 12:28:41 -0000

Hi Dino,

> On 26 Jan 2018, at 19:31, Dino Farinacci <> wrote:
>> The fact that (P)ITRs use this mechanism does make it a data-plane mechanism. is the LISP control plane running on (P)ITRs that does it, using control plane messages.
>>>   RLOC-Probing is a method that an ITR or PITR can use to determine the
>>>   reachability status of one or more Locators that it has cached in a
>>>   Map-Cache entry.  The probe-bit of the Map-Request and Map-Reply
>>>   messages is used for RLOC-Probing.
> No one said PITRs are special or different than ITRs in this regard. For both, they use the control plane messages to determine reachabiltity for RLOCs that THE DATA-PLANE encapsulates to.

May be I did not express clearly. I did not suggest that PITR and ITR are different in RLOC probing.

> The data-plane operation decides based on packet counter, RTT, TTL and other mechanisms if the RLOC is of quality for use.
> Any other entity that doesn’t do packet forwarding that does mapping system lookups doesn’t consider these things. Hence, why this issue of the control-plane needs to be described in the document related to packet forwarding.

Two quick comments:

1. The first sentence of the second paragraph of the RLOC Probing section clearly states that RLOC probing is a control plane mechanism based on a time.

2. RLOC Probing can be done by anybody, not only ITRs and PITRs. Any other entity can check RLOCs to make sure they are alive. As such better put the text in 6833bis.