Re: [lisp] 6830bis Review

Dino Farinacci <> Thu, 28 December 2017 05:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49B9D126C22 for <>; Wed, 27 Dec 2017 21:10:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 b6RtlZ2l2TEv for <>; Wed, 27 Dec 2017 21:10:44 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 877C21241FC for <>; Wed, 27 Dec 2017 21:10:44 -0800 (PST)
Received: by with SMTP id w127so37244360iow.11 for <>; Wed, 27 Dec 2017 21:10:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Gz412hGfZbJU7Ty4NPTr9dlMNIl3DPFEDydFGMOM3wI=; b=oBXcJZfITxkdY7TkXbvkWA5cg1HDWiK2oNsyxiNYr+SjOaCMQkZ4RkYu20cSu8GmOq aq0RqCRMZ9/nyr+0Qnt+GaKIei0e6qMh6iDRNwkMjWtCGAF+9lEJ+tK05IC9JZmq3YNx 6z1+B1R5zP+bF0olYrJSb/+qIvCSz9KwzK2xunBgzmD7zYeL1kf8B3TTJ+lhsmNBYkpo iqXGU9DFo16g9h5KIzuij837i7/p0b7I3U1QUN+xEzgszbSpD1KdzhUR0rHTGB2BKXDw OLCNXG3zA2XXKupoprh+TIU7RJf5Xune/xvyQlQyw/M2BjUoiC2tbxxdVtNDFdSdRUKT kdZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Gz412hGfZbJU7Ty4NPTr9dlMNIl3DPFEDydFGMOM3wI=; b=edv4I75XUpb3dFFF/oMgCiIG7dR3lEnbwYQHdZUfztdAuJev8Dp19QEMqjw0Xnj+Zu j84jZbIRxJ8d4ejZpsDS6WOm86ht+BEFQRARNF+h76KIMJttkYRY5MtUcmQWsSDFtmuc kW1qDFu64F7o21jBKLsf+dnEg2hCb6+W5RaA9ldtESqH4FT6NyU0kuiN1yhukCTtLOR8 Sofe6sgwhoXHKMWQ6jIWlU9EeOsgzvY65DB5FAScJzbIW227xtynicqlmRn+aRYGffXH XlJ81TmB8jvzQtuf5LWRxsZ+GBaTHpcuN54UI2ZFRwSa2l+wdszjD6hH5N4MwQ87QHye AfBw==
X-Gm-Message-State: AKGB3mJ21RA5cPooeYjk6ym+fgQxviShfwHbhxrzj1fukWoIJ1ctPmUU IL6CvFomXZFRGL+7OE/OuwI=
X-Google-Smtp-Source: ACJfBovAGtnRMz4SPBHPSVF4iYtCFxlMkF38OcUz/RzD9NTMtU1HNilZAxTWwOkTHNcjUFYAJbfryw==
X-Received: by with SMTP id f63mr23424986ioi.14.1514437843880; Wed, 27 Dec 2017 21:10:43 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id v19sm11517206ite.4.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Dec 2017 21:10:43 -0800 (PST)
From: Dino Farinacci <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_673EEAE6-4043-4B6C-8C36-DDF97C33DC63"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 27 Dec 2017 21:10:41 -0800
In-Reply-To: <>
Cc: Albert Cabellos <>, " list" <>,
To: "Joel M. Halpern" <>
References: <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [lisp] 6830bis Review
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: Thu, 28 Dec 2017 05:10:47 -0000

> I would talk about that purely in terms of RLOCs being dervice from, and assigned according to, the underlay.  It is up to the underlay to set it policies so that it scales well (or chooses not to care, as some underlays do.)

I can change “global Internet” to “core” and “provider underlay networks”. What do you think?


> Yours,
> Joel
> On 12/27/17 11:44 PM, Dino Farinacci wrote:
>>> Actually, I do not see why the LISP spec should talk at all about the scalability of the underlay.  The underlay is what it is.  We are not claiming to change that.
>> But if you assign non PA addresses to RLOCs, the underlay scalability will be worse. It’s definitely worth mentioning how EIDs are independent and can be opaque where RLOCs need to be topologically aggregatable, or otherise you worsen the underlay.
>> Dino
>>> Working Group:  Does anyone else have an opinion either way?  This document belongs to the WG, not to the chairs or the editors.
>>> Yours,
>>> Joel
>>> On 12/27/17 11:18 PM, Dino Farinacci wrote:
>>>>>> Note, we still care about scalability of any underlay, especially the Internet core, so we should leave this in. Note, we ARE still solving the scalability problem.
>>>>>> I don’t know why any of you would think differently.
>>>>> We are solving this issue and many others. But the point of the document is specifying a data-plane, not the benefits of this data-plane.
>>>> When you spec a protocol you must say why you are doing it and ususally a requirements for the solution state that. So benefits is a natural output of satisfying the requirements. And at the same time we also indicate what the costs are.
>>>>>> I have planned to remove the sentence.
>>>>>> What do you think about defining an EID as an identifier of the overlay and an RLOC as an identifier of the underlay? (Probably this needs to be reworded, but you get my point).
>>>>>> In my view this definition is broader and accounts for many of the LCAF uses.
>>>> We spent two years on the definition of an EID and RLOC. There were so many people that contributed and discussed it. Why undo that effort. There is nothing inherently wrong with the definitions.
>>>>> I had planned to take Luigi’s suggestion. I did not want to rewrite this section. It was carefully written by David Black with consolation from the ECN experts. I do not want to lose this technical text.
>>>>> I still think that Luigi's suggestion clarifies the text and that my edit (hopefully) makes it easier for readers to understand. I just moved some sentences .
>>>> I made some changes but it is never a good idea to repeat the same exact text. Check the new wording.
>>>>>>> Actually we should merge this section with 'Routing Locator Hashing’
>>>>>> I disagree with you guys. Who do you think punts packets when there is a map-cache miss? The data-plane. Note there are many users of the control-plane, an SDN controller, many data-planes, and lig/rig. How they each use the control-plane is documented in their own documents.
>>>>>> And please do not suggest that lig/rig usage of the control plane move to 6833bis.
>>>>> As an example, if we keep the 'Routing Locator Hashing' text as it is then it only works with Map-Reply messages:
>>>>> "When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is stored in the map-cache of a requesting ITR”
>>>>>  The point is to allow LISP data-plane to work with any control-plane.
>>>> No that has never been a requirement. We have stated (in the charter) that we can use any data-plane “with the LISP control-plane”. We have never discussed and it was never a requirement to do the converse.
>>>> Dino
>>>> _______________________________________________
>>>> lisp mailing list