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

Padma Pillay-Esnault <padma.ietf@gmail.com> Thu, 13 June 2024 22:15 UTC

Return-Path: <padma.ietf@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 98765C1840EE; Thu, 13 Jun 2024 15:15:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fePygqUslmZP; Thu, 13 Jun 2024 15:15:18 -0700 (PDT)
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 2E800C14F6BC; Thu, 13 Jun 2024 15:15:18 -0700 (PDT)
Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-705b9a89e08so1520746b3a.1; Thu, 13 Jun 2024 15:15:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718316917; x=1718921717; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=tPR5z/Cm2GgjWD7RHKWlwp6ByroK5RcgzYgxbsoWZVc=; b=eJNCDlL+jFcZrmXqItJ94ehAt0M63+yB2dyP5hTovLO4d590q1oAdmfIiwbEIGmHDG G6zkiy0EZrrTdJLzj0v/7NXwqGdMfmUnlkDTI37LWl/IAXdNFt0cE+Sb3RxyPAnf2KzL xJ8TE4qAO4aETXHUedKVxSAZC0cKokzHKjp3Ea8829NRQPROs/f98FvTpEK0l1GUB7E2 0+8TVh6oNLpHZUWYwHZkArGxyRaXoOaSqizEIv6TzIKL2vLuB7U/sxN+7GiWoUHApT/7 qncksEffrHn8DLTc/4lSzDfC08Y1XU9JufkpPG7KWVlF8ErhvDuevgmi6Ng9rogHYRkj +XqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718316917; x=1718921717; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tPR5z/Cm2GgjWD7RHKWlwp6ByroK5RcgzYgxbsoWZVc=; b=j8cu71usmptJYFaWTh/fGM5ct3M8i18OcGaI47Vx4F66GeFkJ8qpVg2Ln+BrgnBeSP PF8Nq93s85FyVcDDxeoHKaDJSbek5tXaMH5uDAd4Pj7xth80qpJ3gzpj0StLwO98wAS6 UfUWMw78bIXIvSfbMaHpGvfYaXWIRUMl75x5afipeAlpe+GtOIvGFKhET9rR9i+6pNmD 1HHY0BVRazygZBx2XIYmyKgpHEQ46jyTKRRrlQShLo0vP3EJW4X+p0Y6mzpaV0iJf8sS gdBhaf/wFhumtUGHdhaTg9XNoWqIAwPXkU6uh0KMk9un7dhwEDKsTU72lVO79ZnWqzEo XmgA==
X-Forwarded-Encrypted: i=1; AJvYcCWhY1k/XSEfRTchfa1Uw3CgRMcn9lfNXFE+DaVB7pXrB2Nnk0S11KUMh96B5zGqjkWqSeqZ/SEDQOdXuBetZnqANj3WNiLbWhIILZUN6jkJHF4xKA==
X-Gm-Message-State: AOJu0Yyzngj+ox72dLEhuoaUvIx7apCvopN60xbokzS2oYxVRNFyWdXc fFkvdhW5Bh9YzpzvpVdtFd864jBF72FRfo3w5BiZujK+KZrMoWnGBKcjdQ==
X-Google-Smtp-Source: AGHT+IGo8tJZiN6X86LB7bZ7z1ee5h2J9dQEMGi8j4WMvsNp8ZFTaGcuCLmwp8gTR3nPQ8wdjNfXdg==
X-Received: by 2002:a05:6a00:2f0e:b0:705:c029:c993 with SMTP id d2e1a72fcca58-705d7107c77mr900707b3a.14.1718316916616; Thu, 13 Jun 2024 15:15:16 -0700 (PDT)
Received: from smtpclient.apple ([212.102.46.223]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-705ccb3d1d7sm1826206b3a.134.2024.06.13.15.15.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Jun 2024 15:15:15 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Padma Pillay-Esnault <padma.ietf@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 13 Jun 2024 15:15:05 -0700
Message-Id: <5107A452-EDEF-439A-A2A7-7830B2C77C74@gmail.com>
References: <DEBC07FE-B74F-4D17-A77E-CB5D19B108F8@gmail.com>
In-Reply-To: <DEBC07FE-B74F-4D17-A77E-CB5D19B108F8@gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
X-Mailer: iPad Mail (21F90)
Message-ID-Hash: 4OHGCFRZHB3ESSVXMF5QYUOW5LIYQURD
X-Message-ID-Hash: 4OHGCFRZHB3ESSVXMF5QYUOW5LIYQURD
X-MailFrom: padma.ietf@gmail.com
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>, lisp-chairs@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/oXaeMW3lH38c2zC-s1ZkNAtuceM>
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>

Thanks for your responses - see below

> On Jun 13, 2024, at 2:34 PM, Dino Farinacci <farinacci@gmail.com> wrote:
> 
> 
>>>>> 
>>>>> What is the precedence between the L bit and the S bit? Must they both be set to 1? What is the procedure of L
>>>> 
>>>> There isn't one, they are treated independently.
>>> 
>>> PPE
>>> How is the decision to skip a node taken?
>>> Let’s take this example  ( n (L=1, S=0, P=0), n+1 (L=1,S=1),…., etr)
>>> 
>>> If we check S=0 first then the decision is just to Skip that hop “n” then will not do a look up and go to next
> 
> Right, if the encapsulator thinks the RLOC for n is down, it could go to n+1.

Here is where i wonder whether strict would have been best to drop the packet and not go to n+1 per the example for SFC where there are mandatory services.

I think it might be worthwhile to document this behavior so as there are no surprises.
Thoughts?

Padma
> 
>>> reencap hop n+1 . Get a valid RLOC by performing look up for next hops in the list. (Result “n”is skipped).
> 
> Then it looks up EID n+1 to get the RLOC for it.
> 
>>> If we check first L = 1 and then there is a valid RLOC we use the reencap hop n regardless of whether it was skippable
>>> (Result here “n” is not skipped)
> 
> Right.
> 
>>> If S =1 then we may do a look up (Result “n” not skipped)
>>> See more below on S=1 and unreachability.
>>> 
>>> I was wondering which is the actual behavior. As the text on S=0 is a “can skip” it seems implementation specific and still be ok.  Should some guidance on use of L and S bit be included for clarity?  FWIW I have no strong opinion on this.
> 
> You have to lookup the EID when L=1, you can't tell the EID is up or not, you have to probe its RLOC. When you do that, you can decide not to use it and move to the second one. If the S=1 is set for this EID, then you must stop using the ELP.
> 
> Dino
>