Re: [lisp] On the use of priority associated to RLOCs

Dino Farinacci <farinacci@gmail.com> Tue, 23 May 2023 18:57 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 02D98C14EB1E; Tue, 23 May 2023 11:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 5x896ZzKS08N; Tue, 23 May 2023 11:57:19 -0700 (PDT)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 8953AC151B1C; Tue, 23 May 2023 11:57:19 -0700 (PDT)
Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-253e0edc278so25533a91.3; Tue, 23 May 2023 11:57:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684868239; x=1687460239; 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=WbJrFrXB5HYMUmc+L9MwxRYLMDVQFdrSZUThdbPum1o=; b=l8l+hQve1252btdQYCVqR2y/6DlDSlATS/JBEZP4ifnOWqiqZSFamB8UXQ9QuxZ9pk IYqJHFtRwuDak9d+ZjbpsA3Ci6PIUS3eKm/i2ccVGuMsdBdqj2YeM4hM8w3bTzWn+M6w AZHm4UYEngl5meKW6rUjacCWx0/9ZPwQ8GH86JJwhvgVtEYQG6RGf0KGPnFnukhHH6oH QN3e+6/+UPoxZZnTTvlsBak+TzpywbJk7ZdWsmCXyQH/X1709kif2ZcdeiKU1QcPRZ5h +8EZJy3GGEOpzXcO9X7p7H+t+vwqj3irPMneoVFhS+DhGS66b2pQcdW9wEHUYem+h3zw x8rQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684868239; x=1687460239; 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=WbJrFrXB5HYMUmc+L9MwxRYLMDVQFdrSZUThdbPum1o=; b=PE76IDpif6GOeVFy8+8bKAlD/cU/bZlrwS/yfK9lOBcc10tJGpLEwVGDYRlS8j5cWr g1nbEyC59V5rFltDBYQr9AObwVr2XeF6pJF9iOWCEP6OOV3zIZPgz8NiR13E3OhWb5tD L9kHZk66ZD35JErWxnfsQAaeeQiBp352zMmaqb49jEYQR6Cr1sV31ybfgj8iVVDNXUYc wVCC632wE/9ddZtwIylFUxtmdOHOwdhGioJq5QoROy3xUHhEQy7OsqqSwWG63FMPI49t qWQsivYqBF4H4FSiT3X/cE7eaw8YULsQG7UumhBMxGmtO8tz6FkE+hAqBxMCXOrm+/Gi DGlg==
X-Gm-Message-State: AC+VfDwNs4Wk0DdxnK06fIO0EJU5CWkj8854irKrse0WwxIp/0ahmbT0 P1/G+PRl8Ms0dFyhShooo6w=
X-Google-Smtp-Source: ACHHUZ7hDAbz20963pYmidpNnClXvI1xHmXXICv11KxEAMRlWwTxW2CEGa0SIRfSkUL+uMTha58+BA==
X-Received: by 2002:a17:90a:c712:b0:250:2192:1bff with SMTP id o18-20020a17090ac71200b0025021921bffmr14426620pjt.23.1684868238543; Tue, 23 May 2023 11:57:18 -0700 (PDT)
Received: from smtpclient.apple ([2601:646:9600:d610:2130:86c7:ed83:64fb]) by smtp.gmail.com with ESMTPSA id v5-20020a63f205000000b005134fc049d7sm6356234pgh.31.2023.05.23.11.57.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2023 11:57:18 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <97B0D7ED-C1E1-4285-A401-DA2BA2FDCE3E@gigix.net>
Date: Tue, 23 May 2023 11:57:07 -0700
Cc: "lisp@ietf.org list" <lisp@ietf.org>, lisp-chairs@ietf.org, "Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C23CF756-7F9B-4064-B975-51831B4364D5@gmail.com>
References: <97B0D7ED-C1E1-4285-A401-DA2BA2FDCE3E@gigix.net>
To: Luigi Iannone <ggx@gigix.net>
X-Mailer: Apple Mail (2.3731.400.51.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/t-pJqjGosLH39bPQM0SVf9DPTPE>
Subject: Re: [lisp] On the use of priority associated to RLOCs
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: Tue, 23 May 2023 18:57:24 -0000

Maybe I can provide some color, so folks know why this design decision was made. 

(1) An xTR behind a NAT will register its global RLOC (and port) and the RTRs it has learned to the mapping system.
(2) When another ITR wants to encapsulate to this xTR, it CANNOT do so with the global RLOC.
(3) When an RTR wants to encapsulate to this xTR, it CAN do so with the global RLOC.
(4) So when either the ITR or RTR do a Map-Request lookup, the map-server returns a PARTIAL RLOC-set to the requester. That is, it returns the global RLOC(s) to the RTR and the RTR RLOC(s) to the ITR.

For the map-server to know in an RLOC-set which RLOCs belong to RTRs, they are registered with RLOC priority 254.

Dino

> On May 23, 2023, at 7:07 AM, Luigi Iannone <ggx@gigix.net> wrote:
> 
> Hi All,
> 
> 
> TL;DR: Should the priority associated to RLOCs be used to indicate something else?
> 
> Long Version:
> 
> As you may (or may not) know Dino submitted the lispers.net NAT traversal solution (https://datatracker.ietf.org/doc/draft-farinacci-lisp-lispers-net-nat/ ) for publication on the Independent Stream (https://www.rfc-editor.org/about/independent/).
> 
> Current ISE Editor is Eliot Lear (well known by old lispers like me ;-) )
> 
> During the review of the document an interesting question came up:
> 
> Lispers.net NAT traversal uses priority 254 to indicate that the RLOC belongs to a RTR.
> 
> No text in old and new specs suggest a usage of the priority to deliver something different than the priority itself.
> Even the value 255 is related to priority: do not use this RLOC = no priority.
> 
> It goes without saying that there is no IANA registry about special value of priority associated to RLOCs.
> 
> At the same time there is no text that explicitly states “priority indicates only the priority and CANNOT be used for something else”.
> 
> So the question is: Should we (the WG) consider that priorities can be used to indicate something different from priority?
> 
> If not: we may want to write it down somewhere.
> 
> If yes: Well…. This deserves a longer discussion (may be to be included in the new charter…).
> 
> Thoughts ?
> 
> Ciao
> 
> Luigi
>    _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp