Re: [Int-area] draft-eckert-intarea-functional-addr-internets-00.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 13 July 2021 22:25 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D743A0CB9 for <int-area@ietfa.amsl.com>; Tue, 13 Jul 2021 15:25:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USAr-I5A4cx9 for <int-area@ietfa.amsl.com>; Tue, 13 Jul 2021 15:25:06 -0700 (PDT)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 2F3A13A0CC4 for <int-area@ietf.org>; Tue, 13 Jul 2021 15:25:06 -0700 (PDT)
Received: by mail-pf1-x435.google.com with SMTP id m83so116818pfd.0 for <int-area@ietf.org>; Tue, 13 Jul 2021 15:25:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=g09ylDhqYHlU9Cb7jyz0+/8NzV0WzOARIRsJqA6BCmI=; b=tNcsHya7yEZn5+NpcUALFiA+v3WRlDRtCmJ7fMHHglzHqVl8agko9i6mM2gJfa7c17 v8eVjj7btPzuLSoLagd+28rOSpOX0PcbFHyMhVns+pMWXdaUXG6YFZhJ+g8F4dDSpCra U+84cRC8Q/up/FX80M1vnURvgKEhtc+EWaeZdBn+mSyqb6nRPuHB/hDDaroxsTkGEp0/ 2hwHuIX7+siVBcSUVH+yoUGWCzGC1wfELlPV3b6312X0AVVHSKzmaT9oE4saJzQz0YW0 Pl+LlRxNGz15Eux8EMgG1fPd8Q72hlcLzJlgDbCsr+HDAu/04gaYgNEjyAH/57hfTCnW HMag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=g09ylDhqYHlU9Cb7jyz0+/8NzV0WzOARIRsJqA6BCmI=; b=rD3RrZeA1yTd9zUMZT4D0yf/i2ChVGJqVUksNnszMVcUeTwhInW0szc9dxY/j8yGdq zl1xEPtnkWoLWWTguZmIWZFGT/jND/EJJEOutvdo6cTMuCHH9whqWf4hgJEC52Q1/NBx crDUJ37HyWCUlEb7HJB4c4KlIQ1lkXwuB8bC8foxOEwZRI8a1P8gyGt4Pe/fly5mzoxT KqAEePYmAO/1InxjgnwrXMtyzJ3deSA37aw966vdAE+gURL54i65Yp3/lAFxRCbEyizM LRXW5RmdB2/StgdTwOHJ6yYZK0qhVhHLOHPrj9bxbX821lzrg2ButxuBbaqQik2mTxzR cZ9g==
X-Gm-Message-State: AOAM5330t5+3ojCBc8+RAFIkmyjK9lUx50ulOMYsh+P2tyvRiE/rUuoy zbPwa0KBmAO4/q7JK/rlXxFvZKc62R84Qw==
X-Google-Smtp-Source: ABdhPJwY6yzSIJIN4jcoFS4t40UlWJOviJegitPPSfpxyKaqy36XMISWEteL+/OSZvCdqHaOPRPiJA==
X-Received: by 2002:a63:2b92:: with SMTP id r140mr6212265pgr.394.1626215104687; Tue, 13 Jul 2021 15:25:04 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id l6sm118008pgh.34.2021.07.13.15.25.02 for <int-area@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jul 2021 15:25:04 -0700 (PDT)
To: int-area@ietf.org
References: <20210712230411.GB24216@faui48e.informatik.uni-erlangen.de> <BC56402F-D785-405F-A770-206DFE208D40@gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <983f79cd-3dfc-c60c-d832-885508fead15@gmail.com>
Date: Wed, 14 Jul 2021 10:25:02 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <BC56402F-D785-405F-A770-206DFE208D40@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/E-Ix-NC5eLxB3ocQumNGHoG_iXY>
Subject: Re: [Int-area] draft-eckert-intarea-functional-addr-internets-00.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jul 2021 22:25:11 -0000

On 13-Jul-21 17:57, Stewart Bryant wrote:
> An interesting draft Toerless.
> 
> From a background POV it is worth noting ISO 8473 which is in deployment with multi-type variable length address.

Pretty ugly and limited though, and as I understand it the major (unclassified) deployment, in the airline trade, is trying to migrate away. I have no idea if there are classified deployments, but if so, I expect they use the non-variable GOSIP format.

I think ISO 8473 is a pretty good model of how not to do it.

> It is also worth noting that SA is different from DA to the extent that 
it may not belong in the network layer header of the outgoing packet. The 
SA is arguably a function of the payload and the application. Indeed some 
MPLS OAM solutions do just that by making the return address implicit in the arrival LSP, or a parameter in a payload TLV. SA as in IP is arguably 
just a convenience for a simplified method of operating an application.

My favourite article on that topic is https://www.cl.cam.ac.uk/techreports/FUCAM-CL-TR-849.pdf

   Brian

> 
> Stewart
> 
> Sent from my iPad
> 
>> On 13 Jul 2021, at 00:05, Toerless Eckert <tte@cs.fau.de> wrote:
>> Dear Int-area
>>
>> As attached below, i have written up an idea about why and how variable-length
>> addresses in the network layer would be useful for many limited domain 
internetworks,
>> but also how they could provide a simple and easily extensible framework to
>> add additional semantics (the likes of multicast, BIER, ICN), and also 
make it easier 
>> to express the programmability that SRv6 introduced.
>>
>> Would very much welcome discussion/feedback, and will be asking for a slot
>> to present/discuss this int-area 111.
>>
>> Note that the -00 writeup is mostly inspirational for what i think the 
cool
>> things one could do with it are and to explain the concepts.
>>
>> Obviously, if/when there is interest in this
>> direction, the harder work of figuring out how to best introduce this
>> incrementally, and ideally backward compatible into existing networks wold
>> be the next big set of items to work out.
>>
>> Cheers
>>    Toerless
>>
>> On Mon, Jul 12, 2021 at 01:00:25PM -0700, internet-drafts@ietf.org wrote:
>>> A new version of I-D, draft-eckert-intarea-functional-addr-internets-00.txt
>>> has been successfully submitted by Toerless Eckert and posted to the
>>> IETF repository.
>>>
>>> Name:        draft-eckert-intarea-functional-addr-internets
>>> Revision:    00
>>> Title:        Functional Addressing (FA) for internets with Independent Network Address Spaces (IINAS)
>>> Document date:    2021-07-12
>>> Group:        Individual Submission
>>> Pages:        30
>>> URL:            https://www.ietf.org/archive/id/draft-eckert-intarea-functional-addr-internets-00.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-eckert-intarea-functional-addr-internets/
>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-eckert-intarea-functional-addr-internets
>>>
>>>
>>> Abstract:
>>>   Recent work has raised interest in exploring network layer addressing
>>>   that is more flexible than fixed-length addressing as used in IPv4
>>>   (32 bit) and IPv6 (128 bit).
>>>
>>>   The reasons for the interest include both support for multiple and
>>>   potentially novel address semantics, but also optimizations of
>>>   addressing for existing semantics such as unicast tailored not for
>>>   the global Internet but to better support private networks / limited
>>>   domains.
>>>
>>>   This memo explores in the view of the author yet little explored
>>>   reasons for more flexible addresses namely the problems and
>>>   opportunities for Internetworking with Independent Network Address
>>>   Spaces (IINAS).
>>>
>>>   To better enable such internetworks, this memo proposes a framework
>>>   for a Functional Addressing model.  This model also intends to
>>>   support several other addressing goals including programmability and
>>>   multiple semantics.
>>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>
>> -- 
>> ---
>> tte@cs.fau.de
>>
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>