Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses
Behcet Sarikaya <sarikaya2012@gmail.com> Mon, 01 March 2021 20:46 UTC
Return-Path: <sarikaya2012@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 ED92C3A22A3; Mon, 1 Mar 2021 12:46:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Kbry54v7cyxE; Mon, 1 Mar 2021 12:46:39 -0800 (PST)
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 081263A22A2; Mon, 1 Mar 2021 12:46:39 -0800 (PST)
Received: by mail-yb1-xb2d.google.com with SMTP id m9so18382705ybk.8; Mon, 01 Mar 2021 12:46:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=/NVvf5dycl1WYWYorXFwElEUhswH5HQkUXQ/dWnNtr4=; b=ITsodZajLxnMf6vrHp36xz7cpwM0iPVbaNA6D0c++PE0K8RJa23LAe57T5ZVAVWonn JMId1+kRXcyqnnlHy05Qfvp7nCRE+OtkMpnzDGIvsyUhrShZOtYeWOgzo9WJXb11AW1f mxe/Smw0yvoErtb0kY4OEEL6BHU2hAILQKl2gD/7aWpHxzbW7lDmNbap5Mf9VZZrf1zo ixV5fdgNSJT7tttXCK5j85cbWh3OhxFGEcNzuUcXYFEC+7UXAV11Tjcdk3ockzOU3RtS d1ly/8MSILgG5jGmk/GEj0+uV2iklagvLNFhBwLJ1SMt5DRnGfliz0NeKqz6xJs27e/v eB7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=/NVvf5dycl1WYWYorXFwElEUhswH5HQkUXQ/dWnNtr4=; b=i5LeZhiPBCnUC1TQsMy2PrK6y7g1b1Y2CqCVxlQrgHnh9jWS9GBlqPbs0VLENxkcOx cCP3qPkm5x3FGtYTQT+PjlJy3oiSSv9cG1oqfCkcT1gefOsIAkJKHWKDKqB5Q6J3GrH5 t2WE/KoSmMxUUiyz/OP2yYFmsTyYdW8yNgAfEPyAbdmnnZBRXi0XXRtzrxp4GSSlbpb2 LnZ1CQg6Tnwt6PcP6D7pRaZiFTzJ6U7hRbmy8Ek/3lb1YxeRTMBFnY86fq24GPW5rmaR LV2FSuBDq6WOXlf67lb6v+f1QhasHZmMyhD+SBcYtHZ7XInfoekzz4kNldE1yd3APVmk hdCA==
X-Gm-Message-State: AOAM531QMRRtsTUcUaW2LRPiSRUQgEost6nif6ri6RCPEOKkLMgWiM4g eWCJheVEnAJfAIJMjVsCx83U8q+HCkXiVtoZTVk=
X-Google-Smtp-Source: ABdhPJyjXklrZ6zvWI8yavbBLVkP6ZZfPkBjJFAUksJqg5FMz83Gao+MM7nUaVrfzj2YS0fk0FVQur/O2ovBhM9MQJc=
X-Received: by 2002:a25:20f:: with SMTP id 15mr24845553ybc.423.1614631597105; Mon, 01 Mar 2021 12:46:37 -0800 (PST)
MIME-Version: 1.0
References: <CDB32FF0-5CE0-4C0F-B1D1-B6BFEA42E817@gmail.com> <3dd5a712bd2b4fdbb882d860ab2ece82@huawei.com> <7A6DB0D7-A2A3-4995-A6D9-ABDFF4F7879B@gmail.com> <20210301153259.GB11539@faui48f.informatik.uni-erlangen.de> <3ee2a63b-45db-b296-d6da-c1b4263b8fd6@gmail.com>
In-Reply-To: <3ee2a63b-45db-b296-d6da-c1b4263b8fd6@gmail.com>
Reply-To: sarikaya@ieee.org
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Mon, 01 Mar 2021 14:46:25 -0600
Message-ID: <CAC8QAcdRNhTe4dvq4MwQ1i3JFxOuP7Gi_ThZ1Z+pMREyMv3X1Q@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Toerless Eckert <tte@cs.fau.de>, Stewart Bryant <stewart.bryant@gmail.com>, "draft-jia-flex-ip-address-structure@ietf.org" <draft-jia-flex-ip-address-structure@ietf.org>, "draft-jia-scenarios-flexible-address-structure@ietf.org" <draft-jia-scenarios-flexible-address-structure@ietf.org>, int-area <int-area@ietf.org>, Jiayihao <jiayihao@huawei.com>
Content-Type: multipart/alternative; boundary="000000000000c9e5fd05bc7fb6a8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/aYxqtP5IB0DwVK66P-nsPBVKKQ8>
Subject: Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses
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: Mon, 01 Mar 2021 20:46:41 -0000
On Mon, Mar 1, 2021 at 2:08 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi Toerless, > On 02-Mar-21 04:33, Toerless Eckert wrote: > > It is somewhat ironic to see how it was IP and IPv6 that where the > protocols that where > > successfully enhanced with additional adress semantics not considered > when they where designed > > (ok, at last IPv4, but arguably also in a more subtle fashion IPv6). > Even though as Stewart > > points out, CLNP would be more easily able to absorb additional > semantics because of its > > flexible address length. But of course new semantics are looking for the > best model to see > > actual deployments, and that best happens with protocols already most > widely deployed. > > > > Which at the time IP Multicast was designed was obviously IPv4 (at least > in the USA where it > > originated), not CLNP. > > > > So now we're stuck that adopting newer semantics like BIER or ICN > natively into IPv6 is > > primarily not possible because of IPv6 fixed address length. Instead, > BIER had to do its > > own second network hop-by-ho forwarding protocol/header duplicating all > of IPv6 as needed, > > just to have longer addresses, and ICN (hICN) proposing which in by book > is really an > > overlay solution to leave IPv6 pretty much untouched. > > > > I really don't understand why the IPv6 world has not understood how the > most easy way > > to allow for the applicability of IPv6 to grow (especially beyond "just > more addresses thn IPv4") > > would be to come up with a backward compatible encap on the wire that > would support additional > > address lengths. > > There is work on supporting shorter address lengths in limited domains > where that is sufficient. I don't think we have a viable use case yet for > longer addresses, although we do have a need for 3GPP operators to support > prefixes shorter than /64, but that's a deployment issue, not a standards > issue. > > (BIER doesn't strike me as such a use case; an overlay is the natural > solution and it's roughly what Rick Boivie and others proposed in XCAST 20 > years ago, as eventually recorded in RFC5058. I'm fairly uninformed about > ICN but again it seems to me that an overlay is the natural solution and > blending it into the network layer would be spaghetti engineering.) > > > It would take but a minute to design a longer-address mechanism for IPv6, > although I don't have space to include it in the margin of this email**. > But it would take many years for it to be widely implemented and deployed, > during which time the Internet would be opaque to such addresses. > > Well said :) Behcet > > We've already seen with SRv6 how more flexible use of addresses can help > > solutions. > > Have we really seen that? How many sites are running production traffic > using SRv6? In any case, 128 bits seem to be largely sufficient for SRv6 > purposes, since the semantics are local. > > Brian > > ** Basically, use a prefix such as fb00::/8 to indicate an extended > address. > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >
- [Int-area] Using ISO8473 as a network layer to ca… Stewart Bryant
- [Int-area] 答复: Using ISO8473 as a network layer t… Jiayihao
- Re: [Int-area] Using ISO8473 as a network layer t… Stewart Bryant
- Re: [Int-area] Using ISO8473 as a network layer t… Toerless Eckert
- Re: [Int-area] Using ISO8473 as a network layer t… Brian E Carpenter
- Re: [Int-area] Using ISO8473 as a network layer t… Behcet Sarikaya
- Re: [Int-area] Using ISO8473 as a network layer t… Jiayihao
- Re: [Int-area] Using ISO8473 as a network layer t… Toerless Eckert
- Re: [Int-area] Using ISO8473 as a network layer t… Liguangpeng (Roc, Network Technology Laboratory)
- Re: [Int-area] Using ISO8473 as a network layer t… Stewart Bryant
- Re: [Int-area] Using ISO8473 as a network layer t… Stewart Bryant
- Re: [Int-area] Using ISO8473 as a network layer t… Stewart Bryant
- Re: [Int-area] Using ISO8473 as a network layer t… Liguangpeng (Roc, Network Technology Laboratory)
- Re: [Int-area] Using ISO8473 as a network layer t… Toerless Eckert
- Re: [Int-area] Using ISO8473 as a network layer t… Stewart Bryant
- Re: [Int-area] Using ISO8473 as a network layer t… Alexandre Petrescu
- Re: [Int-area] Using ISO8473 as a network layer t… Stewart Bryant
- Re: [Int-area] Using ISO8473 as a network layer t… Brian E Carpenter
- Re: [Int-area] Using ISO8473 as a network layer t… Brian E Carpenter
- Re: [Int-area] Using ISO8473 as a network layer t… Liguangpeng (Roc, Network Technology Laboratory)
- Re: [Int-area] Using ISO8473 as a network layer t… Carsten Bormann
- Re: [Int-area] Using ISO8473 as a network layer t… Alexandre Petrescu
- Re: [Int-area] Using ISO8473 as a network layer t… Stewart Bryant
- Re: [Int-area] Using ISO8473 as a network layer t… Pascal Thubert (pthubert)
- Re: [Int-area] Using ISO8473 as a network layer t… Luigi Iannone
- Re: [Int-area] Using ISO8473 as a network layer t… Toerless Eckert
- Re: [Int-area] Using ISO8473 as a network layer t… Luigi Iannone
- Re: [Int-area] Using ISO8473 as a network layer t… Toerless Eckert
- Re: [Int-area] Using ISO8473 as a network layer t… Pascal Thubert (pthubert)
- Re: [Int-area] Using ISO8473 as a network layer t… Toerless Eckert