RE: Accurate history [Re: "professional" in an IETF context]

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 04 November 2021 16:26 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B8D3A0E11 for <ietf@ietfa.amsl.com>; Thu, 4 Nov 2021 09:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 n4q-ugCWLSDt for <ietf@ietfa.amsl.com>; Thu, 4 Nov 2021 09:26:47 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6845C3A0E0D for <ietf@ietf.org>; Thu, 4 Nov 2021 09:26:47 -0700 (PDT)
Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HlTYD6TVkz67bFW for <ietf@ietf.org>; Fri, 5 Nov 2021 00:26:40 +0800 (CST)
Received: from mscpeml500002.china.huawei.com (7.188.26.138) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Thu, 4 Nov 2021 17:26:42 +0100
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500002.china.huawei.com (7.188.26.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Thu, 4 Nov 2021 19:26:41 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2308.015; Thu, 4 Nov 2021 19:26:41 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "sarikaya@ieee.org" <sarikaya@ieee.org>, IETF <ietf@ietf.org>
Subject: RE: Accurate history [Re: "professional" in an IETF context]
Thread-Topic: Accurate history [Re: "professional" in an IETF context]
Thread-Index: AQHX0CVovVGa7jvYXUCxunxuZ8u5Aqvxc5hQgAHV/ACAAA76AIAAN+JA
Date: Thu, 04 Nov 2021 16:26:41 +0000
Message-ID: <eae026b8fc7a42eeb2210dcb156d5f56@huawei.com>
References: <8F4B97EA-665F-4A59-B99D-791B4AB9F2F7@yahoo.co.uk> <746C1453-FFB0-46E5-ABF2-8630DC23B959@network-heretics.com> <c3e9fe1b-8e48-a364-9e25-4084dac70889@meetinghouse.net> <3a6bf8ad-5492-0942-a451-6317e8a93705@network-heretics.com> <3e685576-a230-a7c4-f371-d66a55aa820d@necom830.hpcl.titech.ac.jp> <7a087707-499f-e3bf-8701-1a58930a8a22@meetinghouse.net> <4ec32d7a-a17b-635b-91bc-4152313d6800@necom830.hpcl.titech.ac.jp> <885e62bf-7d6a-4501-a48a-e7c2cbf20382@joelhalpern.com> <e59adb61-a55c-7f5f-a60a-40bf186c139d@necom830.hpcl.titech.ac.jp> <CAC8QAceMSrfkqGTYcMNr3JargO3gxJqTaEyf02LGHd-KVeUDHw@mail.gmail.com> <6286da3e-2beb-9556-089a-2e1951573b1e@gmail.com> <59c80b60-438f-b10f-ad61-ba839f6e4f95@necom830.hpcl.titech.ac.jp> <e834916e85ea47ef94fce07c23928d2b@huawei.com> <37b299c8-e821-07e5-6240-68fb9d1ca137@gmail.com> <23b450fb11eb4a51bb4ee837b5c52657@huawei.com> <a805b50d-3ccd-dd2a-4931-6c6dc9a8ede3@necom830.hpcl.titech.ac.jp> <CAC8QAceY1gtK5v3WGMd4OB0z826jDiDDw_g1LbjWef7MKTnrcg@mail.gmail.com>
In-Reply-To: <CAC8QAceY1gtK5v3WGMd4OB0z826jDiDDw_g1LbjWef7MKTnrcg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.193.58]
Content-Type: multipart/alternative; boundary="_000_eae026b8fc7a42eeb2210dcb156d5f56huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/sZs4YhXCz4QGQxlorJzONbbpb30>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Nov 2021 16:26:52 -0000

The fact that IPv6 is not possible to extend above 64 bits is more or less important by itself.

Interface ID is still not used for something usefull, but ND creates a lot of problems.
It is still possible to return it to MAC and cancel the biggest part of the ND that creates a lot of problems.

Eduard
From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Thursday, November 4, 2021 7:04 PM
To: IETF <ietf@ietf.org>
Subject: Re: Accurate history [Re: "professional" in an IETF context]

Folks,

I am unable to understand what Ohta-san or Vasilenko are trying to achieve,
I sympathize with those who expressed concern on the running code that lacks architecture.
 I think this discussion is at least 10 years late. We can not get IPv6 to have 64 bit addresses at this point.
It is just simply time-consuming and unnecessary "gossiping".

It would probably be more productive to propose to start new activity on Next Generation IP and see if it goes somewhere in IETF. Even if it goes, remember IP is the base protocol and changing the base shakes things all the way up. So then we restart  and possibly redo many things that have been done long ago when IPv6 standardization was finished.

Behcet

On Thu, Nov 4, 2021 at 10:10 AM Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp<mailto:mohta@necom830.hpcl.titech.ac.jp>> wrote:
Vasilenko Eduard wrote:

> Then why Address Resolution Protocol was needed in principle? (ND or
> whatever) If the L3 address always had an L2 address inside?

There is no such specification in rfc1526 to mandate "L3 address
always had an L2 address inside", which means ARP is necessary for
other address formats, which means optional specification of
"L3 address always had an L2 address inside" was purposelessly
specified.

> The OSI was calling for layers isolation. It was a big deal for OSI.

According to wikipedia

    https://en.wikipedia.org/wiki/Abstraction_layer
    In computing, an abstraction layer or abstraction level is a
    way of hiding the working details of a subsystem, allowing
    the separation of concerns to facilitate interoperability
    and platform independence.

that is, isolation/separation should be a property of layering
in general not specific to OSI.

> It is not the isolation when addresses from different layers are
> inserted into each other.

See above that layering is merely "allowing the separation", not
forcing the separation. As such, even with a properly layered
protocol, you can have implementations actively destroying the
separation, though, I think them purposelessly complicated.

                                        Masataka Ohta

PS

Existence of running code for some specification means
not that the specification is good but that we can
operate and evaluate the specification to judge whether
it is good or not.

                                                Masataka Ohta