IETF Logo Mail Archive

Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

Padma Pillay-Esnault <padma.ietf@gmail.com> Tue, 23 April 2024 18:28 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 36973C14F6A8 for <lisp@ietfa.amsl.com>; Tue, 23 Apr 2024 11:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.084
X-Spam-Level:
X-Spam-Status: No, score=-7.084 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, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 43Igm2U-y8pu for <lisp@ietfa.amsl.com>; Tue, 23 Apr 2024 11:28:19 -0700 (PDT)
Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com [IPv6:2607:f8b0:4864:20::1129]) (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 1AB59C14F708 for <lisp@ietf.org>; Tue, 23 Apr 2024 11:28:19 -0700 (PDT)
Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-61ae6c615aaso63615117b3.0 for <lisp@ietf.org>; Tue, 23 Apr 2024 11:28:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713896898; x=1714501698; 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=2EMQZOHj0z4ynlsQWpP/i+74Evx6VSvuRRbrf269zLI=; b=Heb/EaGLAMx+N88fmWP+9kwTSwkyWZU+1yuos2gCwS7U9buKrJrQXfdwlcTXYQMCsm dDJgvAGi6RTkufzyZnlmJdWqWHQg38txVnD1CbkpoAkz+RqzmKtLQ0pXKjQLFDwhVq+d EduJPFKvpE6jZL5xU2+1Wg3vlDD+1MZ3gVU2f7YqwS4V3vdcF0H2t2X6FUP5/iO/5dny hDRoNnVJKUL/PYYW2GtHsCt81gjstkpGPf01RIC+j7DGZwhetjMwHtXf8jZ8wZXPXepw VmZkACBSVapd/0j6coVVSu73PRQ5Mm6vNjCvKxyUmxq2JXaQ/pPZRh+FbBroRcR6XAKv bSDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713896898; x=1714501698; 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=2EMQZOHj0z4ynlsQWpP/i+74Evx6VSvuRRbrf269zLI=; b=OfcbfvKdp2vW7hC7itTA52OX8vguBnswUtgPQJuejc9KfllC4LF7hxKO4z+JYjp7ge EJ7S/w52RfFlve0Fhm99bQjxR1scDY5NvjXlpzQ3fJ8kIW09YZMrCcGCyecT4IGuGOPR 79cmhFE+IN6beIG7qOMxKV7VZs1tY2BYiagBgDi1p4Ocp3pTYVxAME6c0I2qBq323Xny OZz9JNtM2DNdOjAbgi/tR8Ou9QGjzdWOXVJfFGwq5Az+moPQAo7Crq3k020vR37y21rb T7l5TgSCyehJs0NKqzeGaIftqaBFmiHHL9I1UuBt2tYRZgi3xBMjPHhgjAu86U/5iclK loaw==
X-Forwarded-Encrypted: i=1; AJvYcCXO+HFuzpays9k4qcTfKb2ZOO/5Swsl5p+yghV2l9XyJo/tvmSViYMJ1tuzyGMyvQprtAzDqhAyTZChJzwd
X-Gm-Message-State: AOJu0YzMmT4h2CYUyDOmUi/dF0PMjuItfFv1aYQiZBjVfEnoQFD557Ve bW8253REr7kzQ9TiXP0b4plDxI8YA+2PgvWxgQ2uF2s2DQxpbvbtd+TFfg==
X-Google-Smtp-Source: AGHT+IGKVYKD0ZeIWa0mViivWaaJpgtkjT66Q4oZ6DW+sbH5eUaJaep5e0m2Syxy0Ub4Cy2pgbwWxg==
X-Received: by 2002:a05:6902:2402:b0:de0:f737:95f with SMTP id dr2-20020a056902240200b00de0f737095fmr460804ybb.7.1713896897846; Tue, 23 Apr 2024 11:28:17 -0700 (PDT)
Received: from smtpclient.apple ([2600:1700:5450:3740:54f3:c1ad:c091:4666]) by smtp.gmail.com with ESMTPSA id 64-20020a251343000000b00dc6d51c8555sm2717640ybt.17.2024.04.23.11.28.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Apr 2024 11:28:17 -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: Tue, 23 Apr 2024 11:28:05 -0700
Message-Id: <833137D7-679B-4C14-9515-017D0CB942F3@gmail.com>
References: <0F9A592C-DCEA-4DA6-91A1-DF5EAF49C701@gmail.com>
Cc: Joel Halpern <jmh@joelhalpern.com>, LISP mailing list list <lisp@ietf.org>
In-Reply-To: <0F9A592C-DCEA-4DA6-91A1-DF5EAF49C701@gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
X-Mailer: iPhone Mail (21E236)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/9id33nS1TEB1LmURyhBdE5uBZ6Y>
Subject: Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
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 Apr 2024 18:28:23 -0000


> On Apr 23, 2024, at 09:25, Dino Farinacci <farinacci@gmail.com> wrote:
> 
> My preference is to update RFC 8060.
> 
How many implementations are using RFC 8060 and will be impacted?

Thanks
 Padma

> Dino
> 
>> On Apr 23, 2024, at 12:24 PM, Joel Halpern <jmh@joelhalpern.com> wrote:
>> 
>> From where I sit, doing nothing should be a non-starter.  We have a published RFC.  We are allowed to change our mind.
>> 
>> But...
>> 
>> 1) We need to be explicit about making such a change.  Which involves updating the existing RFC.
>> 
>> 2) Any such change needs to explain why it is being changed. Just because a later implementation did it differently, without a standard, does not justify changing the standard.  If there is an actual benefit to the change we should step up, admit we are changing it, and explain why.
>> 
>> Yours,
>> 
>> Joel
>> 
>> On 4/23/2024 11:48 AM, Dino Farinacci wrote:
>>>> As I said, the simplest solution is to use a different type value. This allows to still use the old encoding and does not obsoletes implementations that use it.
>>> You will obsolete implementations if we do that. Which really means you make the spec irrelevant. So I say stay with the same code point.
>>> 
>>>> Option B. This document officially updates 8060, but this means that existing implementation of the 8060 encoding are not valid anymore.
>>> Right. But so much time has passed between from when the lisp-geo spec was published I believe most implementations have done lisp-geo encoding vs RFC 8060. My lispers.net implementation does the lisp-geo encoding with the type defined in the draft which is the same as RFC 8060.
>>> 
>>>> How many implementation of this draft are you aware of?
>>> I think cisco and lispers.net. But cisco has to confirm.
>>> 
>>> I think we should do Option C which is do nothing to RFC 8060 and put text in the lisp-geo spec which indicates its encoding takes precedent over RFC 8060 using the same code point and document all implementations have evolved to the lisp-geo spec.
>>> 
>>> Dino
>>> 
>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

v2.29.0 | Report a Bug | By Email | System Status