[lisp] Re: Review draft-ietf-lisp-te

Luigi Iannone <ggx@gigix.net> Tue, 07 May 2024 11:13 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 530DFC14F75F for <lisp@ietfa.amsl.com>; Tue, 7 May 2024 04:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 W0HUzE8YiVzE for <lisp@ietfa.amsl.com>; Tue, 7 May 2024 04:13:42 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 EB72EC14F61F for <lisp@ietf.org>; Tue, 7 May 2024 04:13:42 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-51f99f9e0faso3398644e87.2 for <lisp@ietf.org>; Tue, 07 May 2024 04:13:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20230601.gappssmtp.com; s=20230601; t=1715080421; x=1715685221; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=4bOLU1MjgNsKvnMxHjRJfK78UGx8vo7lgckkwJCkjnU=; b=tIGnhAMhfqHMqmP49dpureEqudPkaYnIQ2bsys1wSLfvJ/3IZ0xg2HLYIDvfrGiaCT dFenCIKolj8AV7rUR4XoOk+ckpAd5G+xgGOFoQhSjeBB3bg6NlsBBJj8YuoK7AI4oQqL o8FQMifgnIwvwl8aNgS9WGxt/cmEejJpa1sDxI5Wo0AhoO+GeAsagxCeBooTzxcrQIEn eWJZ5EywMzkbSicdXd5XKprk2drRGpHoG+W2B3eYHGtU8Nb6xxCDmUwcrHl1D7Fv0odP oD6y9RhghybVRofRZXAd/WKS4X8rQQwnoXEsoJtIGJTIvxjMpIcyJZvPKWdtsSrvGOEl lulQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715080421; x=1715685221; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4bOLU1MjgNsKvnMxHjRJfK78UGx8vo7lgckkwJCkjnU=; b=ctyAzRRoYi6erszgpjZvk6No3eL/72EPpxV0p1S/D+jNMbfcbmBSsQqmEp9oGQb5gj zRKUefZe3zAC8gwsKJJ15CSBSdkihF0kEkrleoj1XomG0uBXjrryzQYop8Cmt31h1DOZ onx2FRm4hqourdakZcbLhEtcDA2F8w3JETaDcrhRM+vYrx6nl+SQ/SLFoJ7WzZINe/mo 6T7AxuwvHa3hG4u2IsSl15RQK9M+J2N/wFY/2f3tfNl8OwwGJIrJEGsmMXlBJX5Rap7c HGb+VZGe9AbbDAxnUObrkpwcMpFvcfZSk6HvEiLKkH6UpEP5XhBoLEfTGOQI7SSPAwCl b22A==
X-Gm-Message-State: AOJu0Yxn/2L/QW8dJ/V+9LCWNsQOA1HEgbk6WytpLNiQ8UjdSEkmClRc vruSclTyC+EVMULBv6t8rZyqwGNimiJXKh06f9cAc5BQFczErBz/YYZukjs+DBNtOnlZnsp9qPN pQHQ=
X-Google-Smtp-Source: AGHT+IEwuSL9XYcH3VWoILihRigxztktC6yRAL+Xx6XRNkrjIaGHMgsgHrfMr0FP2ffL6cNq6t0sdQ==
X-Received: by 2002:ac2:5f68:0:b0:51c:5171:bbed with SMTP id c8-20020ac25f68000000b0051c5171bbedmr8781331lfc.15.1715080420563; Tue, 07 May 2024 04:13:40 -0700 (PDT)
Received: from smtpclient.apple (91-167-176-17.subs.proxad.net. [91.167.176.17]) by smtp.gmail.com with ESMTPSA id g10-20020a19ac0a000000b0051eeca3fd26sm2071653lfc.223.2024.05.07.04.13.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 May 2024 04:13:40 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
From: Luigi Iannone <ggx@gigix.net>
In-Reply-To: <2356420E-B1E6-4F68-ADD3-83CD44F6C8C9@gmail.com>
Date: Tue, 07 May 2024 13:13:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <261E2219-4B13-43EE-AF78-C470826C28DF@gigix.net>
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> <30A46653-DCC3-4230-A27D-EDC5D2067BE6@gigix.net> <DADD07E7-E1C5-428C-B2D2-33B07C985643@gmail.com> <F9A3EC80-FB24-4FC6-A924-D7A9D8558DD8@gigix.net> <2356420E-B1E6-4F68-ADD3-83CD44F6C8C9@gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Message-ID-Hash: FWY7II57OZD52VTO67L2OJNLG4DKRMW4
X-Message-ID-Hash: FWY7II57OZD52VTO67L2OJNLG4DKRMW4
X-MailFrom: ggx@gigix.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-lisp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: LISP mailing list list <lisp@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [lisp] Re: Review draft-ietf-lisp-te
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/FkX0LuHvgUfiksBeKNQ21VlZHws>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Owner: <mailto:lisp-owner@ietf.org>
List-Post: <mailto:lisp@ietf.org>
List-Subscribe: <mailto:lisp-join@ietf.org>
List-Unsubscribe: <mailto:lisp-leave@ietf.org>

Hi Dino,

Thanks for the update.
My comments inline.

> On 6 May 2024, at 19:54, Dino Farinacci <farinacci@gmail.com> wrote:
> 
> Copying the WG. I have submitted -16 to make things more clear to reflect your comments. Here is the diff.
> 
> Dino
>> On May 6, 2024, at 5:26 AM, Luigi Iannone <ggx@gigix.net> wrote:
>> 
>> Dino,
>> 
>> The document is WG document and the WG has a say. 
>> Please post your reply to the mailing list. I will reply there.
>> 
>> At least we make the WG aware of how we work to move the document forward. ;-)
>> 
>> Ciao
>> 
>> L.
>> 
>>> On 4 May 2024, at 01:32, Dino Farinacci <farinacci@gmail.com> wrote:
>>> 
>>> Going private.
>>> 
>>>> On May 3, 2024, at 4:41 AM, Luigi Iannone <ggx@gigix.net> wrote:
>>>> 
>>>> Dino,
>>>> 
>>>> Let’s go step by step.
>>>> 
>>>> Let’s postpone the text relocation and focus first on the other concerns I have.
>>> 
>>> Good.
>>> 
>>>> 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.  
>>> 
>>> I am presenting the material as I see fit to make it understandable.

Let’s 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’.
>>> 
>>> I will fix this to be more clear.

The text still assumes that an ELP must be returned.

Just replace the words: 

	“which returns a ELP-based locator record for a path to RTR 'y', and encapsulates packets…"

With

	“assuming it returns an ELP-based locator record for a path to RTR 'y', it encapsulates packets…"


>>> 
>>>> 
>>>>>> 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?
>>> 
>>> Because the recursion can be done with a private database. Its a useful feature.

The new text clarifies the use case. Thanks. 

>>> 
>>>> 
>>>>> 
>>>>>> 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.
>>> 
>>> Luigi, the terms are used in self contained sections. They are fine. S-EID is ONLY used in the multicast section because the is the convention we use to look up a multicast mapping (S-EID, G-EID).

I think a unique term makes more sense, but this is not a blocking point.


>>> 
>>>> 
>>>> 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.
>>> 
>>> No it clarifies that the B—->C link could be down or congested and the only underlay path in the diagram is what you see.

This is exactly the point. I do not see an alternate path. I see only an alternate tunnel. 
The current text is still confusing. You want "to route around the path from B to C” and to do it you route "through link B—>C”. This looks like a contradiction to me.


>>> That is intended. If you don't use B and C, you can't get encap'ed packes from ITR to X.
>>> 
>>>> 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.
>>> 
>>> I am not removing it. So tell me what you want to write. OpenDaylight has a provisioning system and it was used to program the mapping system with ELPs.

The sentence remains superfluous. Of course you can do it with ODL, but this is out of the scope of the IETF and I do not see why it should be there.
The other LISP documents never mention a provision system, so why this one has to mention it? Is there a compelling reason?

Ciao

L. 


>>> 
>>>> Once we converge on these issues we will discuss about moving text around.
>>> 
>>> So from exchange I only have one change to make.
>>> 
>>> Dino
>>> 
>>>> 
>>>> CIao
>>>> 
>>>> L.
>> 
>> 
>