Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Tom Herbert <tom@herbertland.com> Thu, 14 October 2021 23:33 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340513A1801 for <spring@ietfa.amsl.com>; Thu, 14 Oct 2021 16:33:08 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi5R0RJ_H8Uz for <spring@ietfa.amsl.com>; Thu, 14 Oct 2021 16:33:04 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB463A1803 for <spring@ietf.org>; Thu, 14 Oct 2021 16:33:03 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id y30so13587361edi.0 for <spring@ietf.org>; Thu, 14 Oct 2021 16:33:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eNqZUYu5eHqgUWUJTCtxYxfVOPeBkmJcDwzFYay68w0=; b=JbvDMbcRPaJMIGbDdwb4mQIoP9KHjSODVd7M+vtzHQ0C704JEObHCZNTDQfBci7nMd 8K/gu0jX3A5JSVg56KeEkuURakhR6RRPHJu44CFEKcBPm0XRB6TNT0scfVee3TMOs4du UDzbDhAuYkZUIjF/eCdlZwlwz8Nlvs7Jjmzn4V/hE8D+dsgyu935Fn7ETIO7h8RYf64y 8ttz2NxjtSBafb8YrdlyFTxAbmMmcj+Q2G0gsVvHvDIhx0WsItUvToADHqq6IaoU2dYq um4VVzOGe3MbpR7/NvCVTV5RHKRf4w8pNNdSuLR0d9nN7kCI59cKvWr+LdUL2q1lVGfu L3Aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eNqZUYu5eHqgUWUJTCtxYxfVOPeBkmJcDwzFYay68w0=; b=uFnHpJNX5KNp+npxw/40uQp+CVlsLz+Eg1L278IXMQ94acnoVWXGszaVwAOSvHjY3f tohAq/RPI3vzt/JwxHeJ02Dvimg3KZHx/b8YxgVL4QnyKJ+eayHBGxXPB/jSGU0Nakd+ dA9QW2DQxNMBdd/PT4HMPHPxSfE9TJjZpbUUq/Y36wuH/Aj5GLbBE3UWlgXoKpngmxMJ KMsC3D/zt2awz8viXe/omz1WKTsgnjLuGup8QAgCNKq2qUXU7Q71Yo+VyHI0QtBFPK1/ K2Zolqf50uaoNEpNSp4OeHlrY51z6dp28IwEckJu3BZVLmWmQYuAQ63X9/ckQbaMeF+1 eb4w==
X-Gm-Message-State: AOAM530879BKKTZ0DDeRyMA8pXyL0VqYdRJ5TmWFwHDrq7N2qrwM3cca ZBDQHviS4+8+boIglO74mjSUPxnkCxhBx/KPL9C/CA==
X-Google-Smtp-Source: ABdhPJyhaQQB14PhXaiTZSBZTB8A1BK+FS9BWCDNT+lup6QBhIX7qt2Th0UdHquXJjnsDsUs5CcjOOkcDibNDB4fz9A=
X-Received: by 2002:a50:e384:: with SMTP id b4mr12759343edm.314.1634254380334; Thu, 14 Oct 2021 16:33:00 -0700 (PDT)
MIME-Version: 1.0
References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1daf3d20-22b2-d111-5131-bd53f51c53a3@gmail.com> <CA+9kkMCk6D-7q-LTu0gwL_ZsyBAaFvn=3_CizK56oHG5dGRwYA@mail.gmail.com> <60f71d8c-8165-111c-4099-7f926a897d22@gmail.com>
In-Reply-To: <60f71d8c-8165-111c-4099-7f926a897d22@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 14 Oct 2021 16:32:49 -0700
Message-ID: <CALx6S35dGZAcRzpkciK7_DMg+ePcQQzsRGXwsYLKkYZr+BPnYA@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Ted Hardie <ted.ietf@gmail.com>, "spring@ietf.org" <spring@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/4i15lTLq6dvfrQMgMCsxoqv3pO8>
Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2021 23:33:09 -0000

On Thu, Oct 14, 2021 at 2:07 PM Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
>
> On 14-Oct-21 22:41, Ted Hardie wrote:
> > On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> >
> >
> >
> >     Including semantics *of any kind* in an IP address is a very fundamental
> >     change to the concept of IP.<https://www.ietf.org/mailman/listinfo/ipv6>
> >
> >
> > Would you mind elaborating what you mean by semantics in the statement above?  Clearly there are semantics in things like the IPv4 multicast and experimental address ranges (aka "Class D" and "Class E"); especially for the multicast case, the very fundamental semantics of the distribution are signalled using the address and there has been significant deployment using those semantics.  Isn't that semantics in the meaning above?
>
> Yes, I should have restricted my remark to *unicast* addresses. But there
> is a difference, I think, between semantics that describe the *type of address* and semantics that actively describe *what the recipient is going to do*. It's the latter that I was getting at.
>
Brian,

Joel's description is very good, and it makes me think that this
mechanism is best described as yet another form of NAT. Similar to a
NAT device, these devices are rewriting destination addresses per some
algorithm which is not necessarily exposed to the outside world. In
both NAT and Sid compression, packets are being routed to some
intermediate node which is performing address translation and
forwarding. The Sid compression method has the advantage that the
translation is  stateless. While SId compression is explicit as
encoded in the destination address set by the sender, it seems like
Sid compression would still be transparent to any intermediate node
that's not the destination address-- that would include the Internet
in packets that were leaked.

Given that NAT seems to work okay, I don't immediately see how SId
compression would be any more of a problem :-)

Tom

> (This applies to Carsten's comment too. Port numbers or multiple addresses per host are not actively describing what the recipient will do; they're just numbers.)
>
> Also, I tried not to express shock and horror at the notion of semantics in address, but concern about how this will impact existing hardware and software.
>
> >
> > Thanks for any clarification,
> >
> > Ted
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------