Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-rfc6833bis-13: (with DISCUSS and COMMENT)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Thu, 13 September 2018 15:35 UTC

Return-Path: <ietf@kuehlewind.net>
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 188C8128CB7 for <lisp@ietfa.amsl.com>; Thu, 13 Sep 2018 08:35:37 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 i24fYkRB_N8W for <lisp@ietfa.amsl.com>; Thu, 13 Sep 2018 08:35:36 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E2D130DDA for <lisp@ietf.org>; Thu, 13 Sep 2018 08:35:35 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=UzPBWhl5ppV16ScvGhNeMVBYmurXqLcInHdUjHtV74i96GfG1S2h9Cwt+gEuFhv2KNLCJZXbYRG2blZ6tjCfeU7K3aw+HUe+uf0wLNcyjSDqE4S07nTz/EVIrbe99Q8KdxKCuxHCLzzMHCoc/lgu7mm9HEfB87d0CJueYjJ47d4=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 22889 invoked from network); 13 Sep 2018 17:28:52 +0200
Received: from i577bceed.versanet.de (HELO ?192.168.178.24?) (87.123.206.237) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Sep 2018 17:28:51 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <C0C3BCBC-BAAB-46BD-980A-284C9FD394C6@gmail.com>
Date: Thu, 13 Sep 2018 17:28:50 +0200
Cc: Luigi Iannone <ggx@gigix.net>, The IESG <iesg@ietf.org>, draft-ietf-lisp-rfc6833bis@ietf.org, lisp-chairs@ietf.org, "lisp@ietf.org list" <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <81DEE14D-5CDE-4B9E-BE67-1774E3268AEB@kuehlewind.net>
References: <153667812809.16741.10796738054406466412.idtracker@ietfa.amsl.com> <9D08CA59-8AC4-4866-944E-98553C37E547@gmail.com> <00DCC7FC-096E-4822-A702-2EE4C70327EB@gigix.net> <0F740BE5-63AF-4D18-BD79-D7D6A352B40A@kuehlewind.net> <2A356E01-FD24-4F6E-9800-4718BCA907F8@gmail.com> <18BB371C-58BB-48ED-B7D2-568412A7890F@gigix.net> <C0C3BCBC-BAAB-46BD-980A-284C9FD394C6@gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-PPP-Message-ID: <20180913152852.22880.46507@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/aQkVbbzGzo3XztG4w94zmIbgegM>
Subject: Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-rfc6833bis-13: (with DISCUSS and COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 13 Sep 2018 15:35:37 -0000

This sounds all fine to me. Please just make sure that the text reflects that accordingly everywhere where ALT is mentioned at the moment and respectively make it more generic if needed. I trust you, you will edit this correctly!

> Am 13.09.2018 um 17:17 schrieb Dino Farinacci <farinacci@gmail.com>:
> 
> 
> 
>> On Sep 13, 2018, at 12:58 AM, Luigi Iannone <ggx@gigix.net> wrote:
>> 
>> Hi Dino,
>> 
>>> On 13 Sep 2018, at 00:03, Dino Farinacci <farinacci@gmail.com> wrote:
>>> 
>>>> 
>>>> Actually I brought this up because there were more cases where I found that ALT knowledge is needed. If you don’t want this to be a normative reference and remove the sentence above (which I’m not sure is helpful), please also double-check all other occurrences of ALT and make sure the discussed case is also understandable without ALT knowledge.
>>> 
>> 
>> I disagree on the approach. IMO it makes more sense to me that this document describes just the Map-Server/Map-Resolver front end. 
>> How the front-end works with the actual mapping system is a matter of the specific mapping system.
>> In other words, how Map-Server/Map-Resolver works with LISP-DDT should be in the LISP-DDT document. Ditto for LISP+ALT.
> 
> I can go along with this. I have wordsmithed that paragraph to not mention LISP-ALT.
> 
>> 
>>> I think it should left in and we should add LISP-DDT to the paragraph. Since the two mapping transport systems that have moved forward to RFC are ALT and DDT. And I believe they should both be Normative References.
>>> 
>> 
>> This  means two downrefs. We will need to move them to PS.
>> I really do not see the need for this but YMMV.
> 
> I will keep then as Informative references. And to address Mirja’s comment about believing that a reader would need to know more about ALT and DDT, I would respond to say, that the documentation is saying that a map-server and map-resolver are last-hops/first-hops to ANY mapping database transport system. So you can treat it as a black box. The operation of these nodes are discussed in the approprorate mapping database transport systems (such as LISP-ALT and LISP-DDT).
> 
> There are also refernces to LISP-ALT (and LISP-DDT) when we have the option for xTRs to be directlry part of the mapping system. This may be a choice for LISP deployers when they want a less centralized mapping system. Again, there are just references that in this case, the xTRs are “first-hop/last-hop” nodes of these mapping database systems.
> 
> How does that sound Mirja?
> 
> Dino
> 
>> 
>> Ciao
>> 
>> L.
>> 
>