Re: [lisp] 6833bis - NMR with locator count !=0

Dino Farinacci <farinacci@gmail.com> Tue, 22 August 2017 17:22 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07171320D9 for <lisp@ietfa.amsl.com>; Tue, 22 Aug 2017 10:22:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 biqWqzNTgMEt for <lisp@ietfa.amsl.com>; Tue, 22 Aug 2017 10:22:04 -0700 (PDT)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D172E132026 for <lisp@ietf.org>; Tue, 22 Aug 2017 10:22:04 -0700 (PDT)
Received: by mail-pf0-x236.google.com with SMTP id c28so26233639pfe.3 for <lisp@ietf.org>; Tue, 22 Aug 2017 10:22:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dlWVnByAFg08q+NWgtacUot7crrL1JBcKEGZOAVjCT8=; b=ntZ6Er1PRczJuvfV0wppMDN2pGIcw+x3nh8kt8meZPoUBxX0WvpQghVGyZkfd1d+Yq gg3tfPDG8yqfWbM3JLUUiRVZJD1ntzh1V06dNtdqgw46iVmMRTKAC5MLvrNOzRdXSOtk hA5wINM5DKHTFDt3DPTM8PNV0XAyEmZMeJfxFad6lSa6XhQNZICeGEwiJ0859d+XoJyx 8ys1Z60r/DQ+tJyHepHXit86C/igvwYK9aHtnRCLwnOz5WPVAQ+L7Lvcz7pgQlAlr8/j Zw3CjyRNwX8MlWxyK8IpKW17exLvmZuUeyCbLgLbxASPSkMgD4wW4bh74W8H1mn6OG3C Y09w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dlWVnByAFg08q+NWgtacUot7crrL1JBcKEGZOAVjCT8=; b=jVdoo4hGff7EKwR/EmhD7troo8IFekbYEd270H/mhMapov1TWmbEbOZrmkl6LtnMeF 1/1PwhayA7CZ58BnqOks/0W0ilXy9ZPopr625ZOzL8vfXe8VMNK/JVJPaCS3rfHIHR+E 8Lr0HaAYpu+9qZQdPQejr9zF7zmsqWfSuWy05AOvN+NP1gF8Ij7XW/umV0ioTLeBxGW5 odfKeeAQTNM1AVhULcuMDsksfxHQxH74DtO8XBGT2KBpefP1ZqPCb16Fc/xVzFt3Uib2 OLQOYRaN/eV1LADU1gQv9XTcgw5FQrRR5Dut93O5ZAPsSbGYSnur/cYoMZ+KyugMxHkk K5dQ==
X-Gm-Message-State: AHYfb5jY4oURyC4PwbQrNYs61rM7OiTfBPha9/m9HceDFQBJrfMeqL0M HMLmLo+VmXUhLk3PEEk=
X-Received: by 10.98.217.23 with SMTP id s23mr1496828pfg.130.1503422524293; Tue, 22 Aug 2017 10:22:04 -0700 (PDT)
Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id o75sm4576494pfa.50.2017.08.22.10.22.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Aug 2017 10:22:03 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <CE2B6A47-99E2-4CA9-B28F-A55A24ADBF24@cisco.com>
Date: Tue, 22 Aug 2017 10:22:02 -0700
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, LISP mailing list list <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0CC75AA9-1008-465D-8EAC-7BE9AFD2030F@gmail.com>
References: <6467BB43-AB19-48C4-A3FD-34D5C2E092E8@cisco.com> <d6318116-0157-302d-abe3-4181c7859e19@joelhalpern.com> <CE2B6A47-99E2-4CA9-B28F-A55A24ADBF24@cisco.com>
To: Victor Moreno <vimoreno@cisco.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/fCGiID57fe6tKV4fjW65XhaagCs>
Subject: Re: [lisp] 6833bis - NMR with locator count !=0
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 22 Aug 2017 17:22:07 -0000

Here are some of my comments Victor.

> Would be mainly conveying the RLOCs of the feasible PETRs dynamically.

Anything or anyone can register mapping entries to the mapping database as long as they are authenticated with the map-server. So I believe you can achieve what you want with NO spec changes or additions to the protocol.

> As PETRs are brought on-line in the network, they can be configured/added in the Mapping System, rather than touching a multitude of ITRs.

Meaning you do not want ITRs to have to configure PETRs. That makes a ton of sense for scale and management reasons.

> This would also allow a more elegant definition for the support of a default exit to the Internet in the Extranet case defined in the lisp-vpn draft. In this scenario, the RLOC record would convey the RLOC of the PETR plus the IID to which the Internet connects at the PETR.

An ITR has no idea where a packet really ends up. So if its encapsulating to an ETR at the destination site or a PETR that decaps and sends the packet many “native” hops to a non-EID destination, then so be it.

I would not call these negative map-replies though. By definition, from the spec, a negative map-reply is a map-reply with an RLOC-count of 0. 

What many implemenationsn do is when they get a map-reply with an RLOC set of 0, they then decide, via configuration to encapsulate to a list of xTRs. Those xTRs are PETRs (by definition of the implementation).

It could be useful to write up a very short draft indicating a “dynamic use-case for PETRs”. But check the Interworking RFC to make sure we didn’t cover this, in some form (even brief) in that spec.

Cheers,
Dino

> 
> -v
> 
>> On Aug 21, 2017, at 11:12 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>> 
>> Can you explain what information you are conveying with the RLOCs?  I think we would need a clear use case before changing the spec.
>> 
>> Yours,
>> Joel
>> 
>> On 8/22/17 2:07 AM, Victor Moreno (vimoreno) wrote:
>>> Dear WG,
>>> As we put some of our specifications to the test in deployments, we have found the ability to return RLOCs dynamically in an NMR to be compelling in a variety of deployment scenarios. Particularly in Networks with multiple Internet exit points.
>>> What are the thoughts of the group on allowing NMRs with a locator count !=0?
>>> One option to indicate that a map-reply is an NMR could be to assign one of the reserved bits as an NMR flag.
>>> Would like to gauge the inclination of the WG before proposing text/edits.
>>> -v
>>> _______________________________________________
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp