RE: I-D Action: draft-thubert-6man-ipv6-over-wireless-09.txt

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 19 May 2021 06:05 UTC

Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA60C3A1FE5 for <ipv6@ietfa.amsl.com>; Tue, 18 May 2021 23:05:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 jcETx2d9o4QY for <ipv6@ietfa.amsl.com>; Tue, 18 May 2021 23:05:17 -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 8E5CC3A1FE1 for <ipv6@ietf.org>; Tue, 18 May 2021 23:05:17 -0700 (PDT)
Received: from fraeml707-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4FlMVc4DgVz6ft5X; Wed, 19 May 2021 13:53:28 +0800 (CST)
Received: from msceml702-chm.china.huawei.com (10.219.141.160) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 19 May 2021 08:05:08 +0200
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 19 May 2021 09:05:07 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.2176.012; Wed, 19 May 2021 09:05:07 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: 6man <ipv6@ietf.org>
Subject: RE: I-D Action: draft-thubert-6man-ipv6-over-wireless-09.txt
Thread-Topic: I-D Action: draft-thubert-6man-ipv6-over-wireless-09.txt
Thread-Index: AQHXS2dZ7FnKPTG8CUOTX/wP0AtrIKron2aAgABa4gCAAI/tAIAABP4AgADAmaA=
Date: Wed, 19 May 2021 06:05:07 +0000
Message-ID: <43543b97d7e146a989d26a6e55af7509@huawei.com>
References: <162126274647.25711.8162789738375511264@ietfa.amsl.com> <32c96d37-a743-f0fa-c858-36333b102d2b@gmail.com> <CAO42Z2w_F9G_1vTrjFrzNEbN1t7qhPKdv1qgNZ0Ld8gLT+J9yA@mail.gmail.com> <CO1PR11MB488124EFFA391EF5844AEC5DD82C9@CO1PR11MB4881.namprd11.prod.outlook.com>, <248ffb81-f157-05cb-3e00-825fd64515c5@gmail.com> <B94A0BAB-1E69-4F16-BFD3-1BE5477DFE6F@cisco.com>
In-Reply-To: <B94A0BAB-1E69-4F16-BFD3-1BE5477DFE6F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.207.194]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/66RfsUAdvxLL3gbF80SBPnNx-GQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2021 06:05:23 -0000

The problem is even bigger:
the most popular L2 technology in the world (by number of interfaces) claims that it is shared multi-access
then fails to sustain this claim.
Because WiFi is P2MP in reality.
Let us treat it as P2MP - many problems would disappear.

It is already a decade late to do what has been promised in RFC 4861:
" However, because ND uses link-layer multicast for some of its
   services, it is possible that on some link types (e.g., Non-Broadcast
   Multi-Access (NBMA) links), alternative protocols or mechanisms to
   implement those services will be specified (in the appropriate
   document covering the operation of IP over a particular link type)."

Ed/
-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: Wednesday, May 19, 2021 12:24 AM
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: 6man <ipv6@ietf.org>
Subject: Re: I-D Action: draft-thubert-6man-ipv6-over-wireless-09.txt

I agree with that Brian; 

the definition is too limiting for many networks we observe today, typically networks where one will not set the onlink bit in a PIO.

In a sense it was already an over-limiting definition at the time that rfc was published, e.g., some implementations like Proteon/IBM could model a frame relay network as P2MP or NBMA in the late 90’s. In the same time frame, RFC 2461 recognized the existence of NBMA and the need for further studies to support it.

I guess we’re here to broaden the picture.

More importantly, the rfc describes the lower layer network as opposed to the abstraction of it that one choses to apply at the IO layer. It is important to remind the user that the L3 model is a conscious decision that is not fully dictated by the lower layer subnetwork.

Regards,

Pascal

> Le 18 mai 2021 à 23:06, Brian E Carpenter <brian.e.carpenter@gmail.com> a écrit :
> 
> On 19-May-21 00:31, Pascal Thubert (pthubert) wrote:
>> RFC 3819 is mostly not an overlap with what we’re trying to do here, Mark. But that’s a cool reference to keep in mind, thank you for this.
> 
> Specifically, it says:
> 
>   Subnetworks fall into two categories: point-to-point and shared.  A
>   point-to-point subnet has exactly two endpoint components (hosts or
>   routers); a shared link has more than two endpoint components, using
>   either an inherently broadcast medium (e.g., Ethernet, radio) or a
>   switching layer hidden from the network layer (e.g., switched
>   Ethernet, Myrinet [MYR95], ATM).
> 
> and that is exactly what is no longer always true.
> 
>   Brian
> 
>> 
>>  
>> 
>> Pascal
>> 
>>  
>> 
>> *From:* ipv6 <ipv6-bounces@ietf.org> *On Behalf Of *Mark Smith
>> *Sent:* mardi 18 mai 2021 9:06
>> *To:* Brian E Carpenter <brian.e.carpenter@gmail.com>
>> *Cc:* 6man <ipv6@ietf.org>
>> *Subject:* Re: I-D Action: 
>> draft-thubert-6man-ipv6-over-wireless-09.txt
>> 
>>  
>> 
>>  
>> 
>> On Tue, 18 May 2021, 07:55 Brian E Carpenter, <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
>> 
>>    Hi,
>> 
>>    IMHO this draft now includes some important new material, namely 
>> definitions of two terms "IP Link" and "IP Subnet" (at 
>> https://www.ietf.org/archive/id/draft-thubert-6man-ipv6-over-wireless
>> -09.html#name-terminology 
>> <https://www.ietf.org/archive/id/draft-thubert-6man-ipv6-over-wireles
>> s-09.html#name-terminology> ). While I'm not sure yet that I 
>> completely agree with the text, I think the topic is very important, 
>> since the previous
> doctrine has effectively been that all "links" behave like Ethernet. 
> And, by the way, the socket API incorporates that doctrine.
>> 
>>  
>> 
>> RFC 3819, Advice for Internet Subnetwork Designers, also being BCP
> 89, would seem to me to be the or close to the IETF's definition of a "link" since it is providing advice on the design of them:
>> 
>>  
>> 
>> Abstract
>> 
>>    This document provides advice to the designers of digital
>>    communication equipment, link-layer protocols, and packet-switched
>>    local networks (collectively referred to as subnetworks), who wish to
>>    support the Internet protocols but may be unfamiliar with the
>>    Internet architecture and the implications of their design
> choices on
>>    the performance and efficiency of the Internet.
>> 
>>  
>> 
>>  
>> 
>> Regards,
>> 
>> Mark.
>> 
>>  
>> 
>> 
>>    (This is something that gave us quite a lot of angst in ANIMA, 
>> especially in clarifying the "link" model in the Autonomic Control 
>> Plane, since we depend on link-local multicast.)
>> 
>>    Regards
>>       Brian
>> 
>>>    On 18-May-21 02:45, internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> wrote:
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> 
>>> 
>>>          Title        
>    : IPv6 Neighbor Discovery on Wireless Networks
>>>          Author        
>   : Pascal Thubert
>>>        Filename        : draft-thubert-6man-ipv6-over-wireless-09.txt
>>>        Pages          
>  : 25
>>>        Date            : 2021-05-17
>>> 
>>> Abstract:
>>>     This document describes how the original IPv6 Neighbor Discovery and
>>>     Wireless ND (WiND) can be applied on various abstractions of wireless
>>>     media.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wirele
>>> ss/ 
>>> <https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wirel
>>> ess/>
>>> 
>>> There is also an HTML version available at:
>>> https://www.ietf.org/archive/id/draft-thubert-6man-ipv6-over-wireles
>>> s-09.html 
>>> <https://www.ietf.org/archive/id/draft-thubert-6man-ipv6-over-wirele
>>> ss-09.html>
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-thubert-6man-ipv6-over-wirel
>>> ess-09 
>>> <https://www.ietf.org/rfcdiff?url2=draft-thubert-6man-ipv6-over-wire
>>> less-09>
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of
> submission
>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/ 
>>> <ftp://ftp.ietf.org/internet-drafts/>
>>> 
>>> 
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org> 
>>> https://www.ietf.org/mailman/listinfo/i-d-announce 
>>> <https://www.ietf.org/mailman/listinfo/i-d-announce>
>>> Internet-Draft directories: http://www.ietf.org/shadow.html 
>>> <http://www.ietf.org/shadow.html> or 
>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
>>> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>>> 
>> 
>>    --------------------------------------------------------------------
>>    IETF IPv6 working group mailing list
>>    ipv6@ietf.org <mailto:ipv6@ietf.org>
>>    Administrative Requests: 
>> https://www.ietf.org/mailman/listinfo/ipv6
> <https://www.ietf.org/mailman/listinfo/ipv6>
>>    
>> --------------------------------------------------------------------
>> 
> 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------