Re: [lisp] Review draft-ietf-lisp-te
Luigi Iannone <ggx@gigix.net> Fri, 03 May 2024 11:41 UTC
Return-Path: <ggx@gigix.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 26454C14F6FF for <lisp@ietfa.amsl.com>; Fri, 3 May 2024 04:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.885
X-Spam-Level:
X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esO8QfauxHNf for <lisp@ietfa.amsl.com>; Fri, 3 May 2024 04:41:49 -0700 (PDT)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BB2C14F6E1 for <lisp@ietf.org>; Fri, 3 May 2024 04:41:49 -0700 (PDT)
Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-41bab13ca4eso48676455e9.1 for <lisp@ietf.org>; Fri, 03 May 2024 04:41:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20230601.gappssmtp.com; s=20230601; t=1714736507; x=1715341307; darn=ietf.org; h=message-id:in-reply-to:to:references:date:subject:mime-version:from :from:to:cc:subject:date:message-id:reply-to; bh=+qP7ojG6N2hlfedotBlogpOiu/toVQCsHd93NiaohQI=; b=Rc2TmTenuNtOPTVW0cCqCsyqVMMRDqeIhZVx4+gwxINEG5PSJHg7s232IderRE/cAJ YyeWYLNxjXTR1JTRABEYHlIFUerRNUuwsJ+ZWFZMfxxsoSHhFXQ83mC4NJHmM2PC5E9t i9VasrSu98pVtUt+4rLBL8LPkUYk3e9+4f4PnBwf5BQ7GherO+RdiVvpgS65NEKMXxRg +rAxeSqpu3bnuvemm/ALneEKkN1euyos37AqDicc52FBpYaxNomE+gdvwQCAdIbc7k6L BKTtx+TBwcfWJ3QkQxUF4hjNj+V3bTGzJDb/8DuEEfCuD/2n8SPeNTthnyMXXOrAOPVe payQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714736507; x=1715341307; h=message-id:in-reply-to:to:references:date:subject:mime-version:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+qP7ojG6N2hlfedotBlogpOiu/toVQCsHd93NiaohQI=; b=dFB81rPCn+rfTA3Q4H+jHSNFopgoFXX2dbqUSvKBs/tY3+WBzItJE9krZPRzoL0VED IKxQPJgiGIRuCyRukKdu1/OjBmvnLVBEJRH5UHGb1Z6MRpBNx3HdMMiRrYdUUaDm54/Q SPUVOl2GsQLmeb2w9F9luAZV99INqCtRcLjAvXKwsaQeDlKL58mUylPD54djDdjYYqrf xdtd8ysBklJfkIgUNeKzEkHPhka5UgAl4OGAYrFH2DjyutO73F4e2Cdhefu/2KChJ29h GW3TI4dF7qC8ViwbOLhu4CH9m1mP6iv9lP67MGo31qTRzTW9OH4fhhpuKOKExDy8Nfh9 2Lrw==
X-Forwarded-Encrypted: i=1; AJvYcCXGmnSU15EhFK1Q1tDa/JzLF+0rLC29MSHgkySwURLiKofswym/mHyVMj1khvmvBTdsVwBZX7ViHRKqf/TX
X-Gm-Message-State: AOJu0YwF6R6f/hATHHl6g5rggJdt9mMIrdx6qgw09vsp7TVHZSOerFXh yPXAnxX6NvM3Wv8vd/YQ+3plezzRyNQQnTyDPLxzHuIFg2F5WG9GmbVa9Iheom0=
X-Google-Smtp-Source: AGHT+IHEGzEO2H2AmaaoCbShczcgDYWunp/jN4AlyAcMOHDzsfpbW4aBX2hwG2Egjhfxrvtqs2Al0w==
X-Received: by 2002:a05:600c:1c9d:b0:41b:f28a:a0c6 with SMTP id k29-20020a05600c1c9d00b0041bf28aa0c6mr1880375wms.38.1714736507377; Fri, 03 May 2024 04:41:47 -0700 (PDT)
Received: from smtpclient.apple (91-167-176-17.subs.proxad.net. [91.167.176.17]) by smtp.gmail.com with ESMTPSA id bg4-20020a05600c3c8400b0041bf29ab003sm9151364wmb.30.2024.05.03.04.41.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 May 2024 04:41:46 -0700 (PDT)
From: Luigi Iannone <ggx@gigix.net>
Content-Type: multipart/mixed; boundary="Apple-Mail=_687ACCAC-1AD0-4786-9462-D57838BB64A8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Date: Fri, 03 May 2024 13:41:15 +0200
References: <43AE7DEC-BA11-4BA7-96BE-1CECCFAB5EA3@gigix.net> <483F064A-2769-4271-A0BA-E69E72257D3E@gmail.com> <681DC702-3BCA-404B-B12D-03F2109E2FFD@gigix.net> <B173BA8E-C798-42AE-B8CB-1FF9CD8DAADE@gmail.com>
To: Dino Farinacci <farinacci@gmail.com>, LISP mailing list list <lisp@ietf.org>
In-Reply-To: <B173BA8E-C798-42AE-B8CB-1FF9CD8DAADE@gmail.com>
Message-Id: <30A46653-DCC3-4230-A27D-EDC5D2067BE6@gigix.net>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/6VaDMiP9n7Duv74seiiMOnI4w7w>
Subject: Re: [lisp] Review draft-ietf-lisp-te
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 03 May 2024 11:41:54 -0000
Dino, Let’s go step by step. Let’s postpone the text relocation and focus first on the other concerns I have. > On 2 May 2024, at 22:29, Dino Farinacci <farinacci@gmail.com> wrote: > > Luigi, see the diff file for most of your comments. I still cannot follow your move suggestions. Just moving text around away from where they are, are going to lose points I intended. You need to be crystal clear what text needs to move where and be precise why you think so. I feel the text doesn't need moving. So if you think it does you need to make compelling reasons without destroying the flow and meaning I have intended. > > I made all the changes you requested in this diff file. I have comments for what I didn't change (I didn't comment on the move text since I did above). > >> Dino, you correct text mixes specifications and use cases. By concentrating the specifications in one section (namely section 5) you will improve readability and clarity of the document. > > No it doesn't. You are using the term use-cases in a high level sense. We are discuss functionality and why the ELP is needed. No Dino. You are mixing examples and procedures, hence my suggestion to move around some text. But we will deal with this later. > >> What really request is a mapping, which may or may not be an ELP. >> What happens if it receives a negative map-reply? > > It follows the procedures of RFC9301. And we don't need to state this everywhere. We are assuming the reader knows how LISP works at a high level. So your text is wrong because it states "requests the ELP for RTR ‘y’”. You request a mapping and act upon what you receive, you do not request an ELP for ‘y’. > >> You mean that this second lookup can be done on a mapping system that is different from the one who delivered the initial ELP, right? >> If yes, can you state so? > > It means the ELP entry is an EID, so to get the RLOC for that EID, you do another lookup. It gives another level of indirection within an ELP. The sentence I referring to is: This can be done when using a public or private mapping database. Why are you introducing this distinction between public and private? > >> The document uses a mix of “seid” and “S-EID”, choose one. > > > On purpose. The seid and deid are used in the forwarding examples. The (S-EID) is only in the multicast section. But you do not explain de difference. Either uniform them or explain. As it is now is just confusing. > >> How the S-bit, L-bit, and the P-bit are used is not covered at all and should be described in section 5. > > It is explained in RFC8060. I don't want to repeat. Agreed. > > So this is the way I want your response. Because this commentary and edits are getting too complex. I want you to respond to this email so we can negotiate the repsonses I provided. And I want another email for the moved text that is written with clarity and precision. Okay? > > Dino >
> > > > Comments on the diff: The example in figure 2, with your latest changes makes even less sense, since you are now using an ELP to make the packet go through exatly the same path as in figure 1. Looks useless. The sentence about provisioning system is still obscure. The LISP control plane is defined in RFC 9301. You are suggesting to use something else to register mappings, which is defined nowhere. So unless you want to define such a provisioning system please delete the sentence. Once we converge on these issues we will discuss about moving text around. CIao L. >
- [lisp] Re: Review draft-ietf-lisp-te Padma Pillay-Esnault
- Re: [lisp] Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Review draft-ietf-lisp-te Luigi Iannone
- Re: [lisp] Review draft-ietf-lisp-te Dino Farinacci
- Re: [lisp] Review draft-ietf-lisp-te Luigi Iannone
- Re: [lisp] Review draft-ietf-lisp-te Luigi Iannone
- Re: [lisp] Review draft-ietf-lisp-te Luigi Iannone
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Re: Review draft-ietf-lisp-te Luigi Iannone
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Re: Review draft-ietf-lisp-te Luigi Iannone
- [lisp] Re: Review draft-ietf-lisp-te Padma Pillay-Esnault
- [lisp] Re: Review draft-ietf-lisp-te Luigi Iannone
- [lisp] Re: Review draft-ietf-lisp-te Luigi Iannone
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Re: Review draft-ietf-lisp-te Joel Halpern
- [lisp] Re: Review draft-ietf-lisp-te Padma Pillay-Esnault
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Re: Review draft-ietf-lisp-te Padma Pillay-Esnault
- [lisp] Re: Review draft-ietf-lisp-te Padma Pillay-Esnault
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Re: Review draft-ietf-lisp-te Padma Pillay-Esnault
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci
- [lisp] Re: Review draft-ietf-lisp-te Dino Farinacci