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

Dino Farinacci <farinacci@gmail.com> Thu, 13 June 2024 21:34 UTC

Return-Path: <farinacci@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 38E51C1E640C; Thu, 13 Jun 2024 14:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 YwuAjvfyy4wg; Thu, 13 Jun 2024 14:34:17 -0700 (PDT)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 BD8CAC1D4CF5; Thu, 13 Jun 2024 14:34:17 -0700 (PDT)
Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1f47f07aceaso14031845ad.0; Thu, 13 Jun 2024 14:34:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718314457; x=1718919257; 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=0G+Fgm8SO6cdbTStfVJyWWuegjz42KAV8rxuPGhHutQ=; b=aw6hh6cLKYgNZ24jhFdklLSI6xv7UoOstiqBLKF6fKzFYoPI1j5CwANgScM3Z3iRuV 0BnBapmMFpZt2N1xyIEJ01ZWoniJi8ak7CgPqRRfmEmabQrf79TsFeZ99xKuRXNuyeKY yd9Mc8PXBOy9LmDLkFkGVUY8jkvYcqjv+ktXfU7HRS1HJd8sg6ivTLcArxMky8gwYdtw 278ebt4oXtiIkK7SMUK/2DYFUUOI382rzPfFAD4DOyiAtdxIG+pyP9cYpd7djIYpx6Uz gHTp2f8rAkWnPlfcslhqTuw5fJPvGCPzJFnRnBvN+8aw4eZC/rEPaFdV6U3jzEsv+LNf y0Yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718314457; x=1718919257; 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=0G+Fgm8SO6cdbTStfVJyWWuegjz42KAV8rxuPGhHutQ=; b=P7q5OxkD8bzDezasiEHI75v7SoOLUAJrQ9fROznpIUNxHVK+SlbOOa8J/9mUoRPq9N jlMvCJOrRqMfnK50DzJ1n2nKUTM8bQCh3fdTSt+llMaYlqhBGbfoEgPKuErN9VLQWqk/ wMwAjTC+X+PkpK+m505TwnMVojtug4TTO3HbHA+odwQZ92xp5PfUwmyvxHcdTY4RKmUS C1Cxl2x+k2AUsMhVPKgBUA5TZgodHRqpSPvA8rMBsWGEJNcbruAbA/WlzZQ71Hhs0+BZ TClqqSdyq58R0p/Z++3sefI0UwYUkuwMUDAcxafN2PDcOIXYzTAhaHY7zplnn+JFH3+4 ciLA==
X-Forwarded-Encrypted: i=1; AJvYcCX+Z5Ul/DnNGClGL9zqqiI1dNHXtsRjgo09e7vVM7wxAR1sPfGepkz8MxM/c+pCi54Xcac3lCKtvUzEfPICIxc2eWTssRxLd8ppD0x7ASxHEwEddQ==
X-Gm-Message-State: AOJu0YzxwcV0XBHq/X1FetaX4Zb9dmUQHGHlccbLYXYekCpES0j5LX6i Qsr49Mxb6eidWIZBQBcSO8QIUJck7NPtuFt4y7Cs1KTChQ2VzuQT
X-Google-Smtp-Source: AGHT+IEyOBoZH1CD9i/G9D5T+9Dxca7z2AclogOdCMLW8Uko//yh+zm9kJ+5Y/IMNdBGHOO65JM97w==
X-Received: by 2002:a17:902:e88a:b0:1f3:b55:e247 with SMTP id d9443c01a7336-1f862a16a35mr9882455ad.55.1718314456800; Thu, 13 Jun 2024 14:34:16 -0700 (PDT)
Received: from smtpclient.apple (c-24-5-184-219.hsd1.ca.comcast.net. [24.5.184.219]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1f855f43ce3sm18696665ad.278.2024.06.13.14.34.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jun 2024 14:34:16 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <D08F672B-70DD-4950-A89E-5762CA1953CF@gmail.com>
Date: Thu, 13 Jun 2024 14:34:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <DEBC07FE-B74F-4D17-A77E-CB5D19B108F8@gmail.com>
References: <D08F672B-70DD-4950-A89E-5762CA1953CF@gmail.com>
To: Padma Pillay-Esnault <padma.ietf@gmail.com>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
Message-ID-Hash: IITUGMTLWR46FJFAYRVONDGKVNU2RXDH
X-Message-ID-Hash: IITUGMTLWR46FJFAYRVONDGKVNU2RXDH
X-MailFrom: farinacci@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/rtSQHIqTwta_85MF-5efzpWO-28>
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>

>>>> 
>>>> 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.

>> 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