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

Luigi Iannone <ggx@gigix.net> Mon, 27 May 2024 13:19 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 D64DEC14F69D for <lisp@ietfa.amsl.com>; Mon, 27 May 2024 06:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 udW7ZkNJQ8nJ for <lisp@ietfa.amsl.com>; Mon, 27 May 2024 06:19:30 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 14E53C14F69B for <lisp@ietf.org>; Mon, 27 May 2024 06:19:29 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-354fb2d8f51so3247811f8f.3 for <lisp@ietf.org>; Mon, 27 May 2024 06:19:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20230601.gappssmtp.com; s=20230601; t=1716815968; x=1717420768; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=vK0qwc5ZaV0CmrAJRlNnzIiPCJmjPngn0CtsXlEGxRU=; b=kVVJdfAtiNQsqslBJsoQ4fm1HNfjJVkDTQs71qMlG+G7lWE1ybJD7ncoTHhWgajnoL 7ddbYNFzE8Gl4e3uI2DQ0vH+d0qfz7LT5WrC+TZ/IXx+gWVxTTo98hi5U/cpLLewHBXq MuKM1jBhDisjsX3VzHZB7vcKGCDfnBucGUYQhAvCaNjjj43UsY2wPX4YZcDNydvPyZdV p3JF57pHFYEhfzTla7lDA9YJR8BV6Ihbat61EudjSp3RjskWsC2c+Z/EkAnAc2G4dvzh 8nNIf5rMKQ/DzP6mWBO1BMfdqcvzhElpiMT+OrhWOLIrcyuNXSeAt13GOIrMrMYYCMSm naXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716815968; x=1717420768; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vK0qwc5ZaV0CmrAJRlNnzIiPCJmjPngn0CtsXlEGxRU=; b=Fhk0DASmnr+6UBDB21ek8y9GPzKTJdmqgtJKmP2LIGfUH4UnqZp2oQKmhtU9zHVUpy OeuSmhjWipLjYAIo/M99beBmcYnL4I0lM0v4eRfRBXelxvsoXiqk+TiJMlzbd4bCXMC6 evXESxxvh8ix4udBLkliM4RF6Es5S+mpAtABymM5k4jYLa/uOWlSrp4fWW8qAAvB/STj mW+uhqHCWOb2rs7ox5h2gRJtq6ZLeC4ovaBywFNTxcW+PeT7x5Ctd31VxtgiIYJ5toct woy6YylzGI0xwRw8U7cQLDy3wf+dR6w1MH1FWVqWOwfR07Z1q56OoLMI6mhAIr9/2JxV dsJA==
X-Gm-Message-State: AOJu0YyABxuuDEGiBfMUDYFLygA6H4sqr8kS2X+YT9HsrY00SMuxzYbz FGHDQjxaJC6ih7mTZjlUe2M4e0LHfKs9D3EX22od8dushvXaQ/b2DEO+L5gTCT+N0gf76GSbcCH z3Y0=
X-Google-Smtp-Source: AGHT+IGXdIzAlPLGlxxX8hZYtea1H0Pw5jRFF0q+FDVm/2guklHfFC6/OSKx3QpXXcpbuMJjSoSkPw==
X-Received: by 2002:a5d:4a8e:0:b0:354:f38c:6d0b with SMTP id ffacd0b85a97d-3552fda2a0bmr6184144f8f.37.1716815968014; Mon, 27 May 2024 06:19:28 -0700 (PDT)
Received: from smtpclient.apple (91-167-176-17.subs.proxad.net. [91.167.176.17]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-35579d7da35sm9035726f8f.16.2024.05.27.06.19.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 May 2024 06:19:27 -0700 (PDT)
From: Luigi Iannone <ggx@gigix.net>
Message-Id: <CF62317D-C4D4-4907-92C4-714B6AC89E5F@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_78FC142C-168C-4839-96B2-F1D0EC4AFFD1"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Date: Mon, 27 May 2024 15:18:56 +0200
In-Reply-To: <3CD7999A-2BBC-4C21-9D7F-AE4256466140@gigix.net>
To: Dino Farinacci <farinacci@gmail.com>
References: <261E2219-4B13-43EE-AF78-C470826C28DF@gigix.net> <5069882E-D7F8-48D5-86FC-2BA095A95D55@gmail.com> <3CD7999A-2BBC-4C21-9D7F-AE4256466140@gigix.net>
X-Mailer: Apple Mail (2.3774.600.62)
Message-ID-Hash: CC6YTETCPP7QC4YET3EFPCTRFCHYWZUH
X-Message-ID-Hash: CC6YTETCPP7QC4YET3EFPCTRFCHYWZUH
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/CzJjLCgCZquCPOkhv56-q3DZTRE>
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,

I do not see a reply to my last email.
Can you fix the figure of the example so that we can move forward?

The concerned part is:

>> 
>>> 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.
>> 
>> B and C have other links. Don’t you see the link between B and X. That is “another” path. 
> 
> But the figure has no “other path” in it. I added one in my first review but you did not like it.
> 
> The text:
> 
> if it is desirable to route around the path from B to C through link B-->C, 
> 
> Still look like a contradiction. Furthermore, in figure 1 you were already routing through link B—>C, so it looks like you “route around” through the very same link…..
> 
> 



For clarity, according to the convention you are using the figure 2 show a tunnel between X and Y but not a path. I put back my very first email with the suggested correct figure.

   Source site       (----------------------------)    Destination Site
   +--------+        (                            )         +---------+
   |         \       (                            )        /          |
   | seid     ITR ---(-> A -> B --------> C -> D -)---> ETR      deid |
   |         / ||    (        |           ^       )     ^^ \          |
   |        /  ||    (        |           |       )     ||  \         |
   +-------+   ||    (        v           |       )     ||   +--------+
               ||    (        X --------> Y       )     ||
               ||    (      ^^ ||       ^^ ||     )     || <>
               ||    (------||-||-------||-||-----)     ||
	       ||           || ||       || ||
               ||           || ||=======|| ||           ||
	       ===============    LISP    ===============
                 LISP Tunnel      Tunnel    LISP Tunnel


Ciao

L.


> On 13 May 2024, at 13:58, Luigi Iannone <ggx@gigix.net> wrote:
> 
> 
> 
>> On 7 May 2024, at 16:36, Dino Farinacci <farinacci@gmail.com> wrote:
>> 
>> 
>>> The text still assumes that an ELP must be returned.
>> 
>> That is correct.
>> 
>>> 
>>> Just replace the words:
>>> 
>>>   “which returns a ELP-based locator record for a path to RTR 'y', and encapsulates packets…"
>> 
>> The example is illustrating nesting so I believe it is not needed.
> 
> I understand the example, but the text is a bit misleading because seems to suggest that lookup _must_ return an ELP. 
> Anyway, in the last revision is already better.  
> 
> 
>> 
>>>>>> 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.
>> 
>> It is a unique term. The term S-EID is used in all the multicast drafts to describe an (S,G).
> 
> Fine.
> 
>> 
>>> 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.
>> 
>> B and C have other links. Don’t you see the link between B and X. That is “another” path.
> 
> But the figure has no “other path” in it. I added one in my first review but you did not like it.
> 
> The text:
> 
> if it is desirable to route around the path from B to C through link B-->C, 
> 
> Still look like a contradiction. Furthermore, in figure 1 you were already routing through link B—>C, so it looks like you “route around” through the very same link…..
> 
> 
> 
>> 
>>> 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?
>> 
>> Because in other cases ETRs register their own RLOCs because they know them. With an ELP, a provisioning system knows the topology and can register all the addresses in the ELP.  It has a broader view. 
>> 
>> There are deployments that take an ISIS topology, compute paths offline as an SDN controller, and can build an ELP path based on policy rules (where re-encapsulation points can be placed in the network). 
>> 
> 
> The sentence is still superfluous. The fact that some LISP deployments use some SDN approach has no place in the document. This is a technical document for implementation of a feature, not a LISP advertisement.
> You can leave the sentence there if you really wish, but remains superfluous.
> 
> 
> Fix the example and we tackle the text.
> 
> Ciao
> 
> L.
> 
> 
>> Dino
>