Re: [v6ops] Multicast problem in IPv6 address management

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Wed, 12 August 2020 13:57 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340233A12A3; Wed, 12 Aug 2020 06:57:57 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.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 bi-iC92V1rGy; Wed, 12 Aug 2020 06:57:55 -0700 (PDT)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42413A129F; Wed, 12 Aug 2020 06:57:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 07CDvp96024624; Wed, 12 Aug 2020 09:57:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1597240673; bh=h02r2amykREDuwaGjWcElQ62gWblPPe5jp4LJD2jtik=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=K38Hpy9O4KCjMcRhQlOxkHMK9v285n+bH67W/sP6o2vFQcC6JuM0bodrTl6+IIcYE qFeZumauQjkX8iI7IH0je23epzZY3ANxvGOA10bt380KUvA3lb5lRlfaCTafs3OWw3 J8PdjLj6OxyxA5W3sfkr4G+aBnEUKAZflJlQ92U4jAdE1Mf/aceLGSbor41rN0sWSN 18NqQsnalUB1N3zjNVSd0QQzQO2MS3aodiIHDGMU11UxkhKgZf90Wm+g/SvqT1GfWL rVWTHfLvAOiQCwH6u/LLztApz2Owr7yhRDZk2nJtFKpQ31NJ4pPEoUpWsofzy+3V0C VN7RR/KzqdR/Q==
Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 07CDvc3H022660 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 12 Aug 2020 09:57:38 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 12 Aug 2020 06:57:36 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Wed, 12 Aug 2020 06:57:36 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>, "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, Ted Lemon <mellon@fugue.com>
CC: "v6ops@ietf.org" <v6ops@ietf.org>, IPv6 List <ipv6@ietf.org>
Thread-Topic: Multicast problem in IPv6 address management
Thread-Index: AdZwipzxSyA49jGGRsKhoVN1GRZp7wAJRt/Q
Date: Wed, 12 Aug 2020 13:57:36 +0000
Message-ID: <16dc5091ff6149128c1001e2c444ba96@boeing.com>
References: <fa3788c64f1a4c3b8fea99536a08dcb3@huawei.com>
In-Reply-To: <fa3788c64f1a4c3b8fea99536a08dcb3@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 5D2191343EF1A0969DB6FB14EEDCEEC87D1486F45B63C53A71DCF75C2EFB8BF02000:8
Content-Type: multipart/alternative; boundary="_000_16dc5091ff6149128c1001e2c444ba96boeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ojSp-_CmDSD3oUbhIUgYms6yXdY>
Subject: Re: [v6ops] Multicast problem in IPv6 address management
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Aug 2020 13:57:57 -0000

Hi, aeronautical radios are another example of an L2 that supports a native broadcast capability,
but may not be so impacted by scale on the order of what you mentioned for WiFi and cellular.
Intelligent Transportation Systems are also looking at short-range multi-party wireless for
terrestrial vehicles, pedestrians and urban air mobility. Here, the scale may well be on the
order of 1B or more.

Fred

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Vasilenko Eduard
Sent: Wednesday, August 12, 2020 3:49 AM
To: Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org>rg>; Ted Lemon <mellon@fugue.com>
Cc: v6ops@ietf.org; IPv6 List <ipv6@ietf.org>
Subject: [EXTERNAL] Multicast problem in IPv6 address management




Hi all,
This dispute is about: Should we assume that Multicast is the basic technology available on any L2? Should we rely fundamental mechanisms on Multicast?

Statista tells us that 9B mobile connections this year.
3GPP have effectively discarded Multicast (RFC 7849), because they have personal GTP tunnel for every subscriber. 3GPP have solved the problem limiting IP topology to P2P only.
Underlay is not IP between Terminal and Base Station – no chicken and egg problem (no need for IP underlay address on smartphone to start PDCP).
As a result: There is no multicast problem in Mobile.

Statista tells us that 18B WiFi connections this year (22B next year).
Multicast snooping is formally supported by majority of WiFi vendors. But Wireless have natural restrictions on multicast:

1.       Loss probability is much high (especially on overloaded) – protocols should guaranty delivery, that is partially supported by SLAAC: NS would be sent many times if NA is not received, but RA would not be retransmitted

2.       It should be transmitted with lowest effectiveness (worst bandwidth and modulation from all registered clients) – some bandwidth is wasted

3.       Handover requirement did push admins to keep broadcast domain big – it is the primary reason why you could still see huge number of announcements per second (for old installations). One AP is not so powerful to connect more than a few dozens of clients anyway, but many APs connected to the same VLAN – it is very different story. You could not just say: “keep broadcast domain small”, because would be immediate question “what is the easy way to preserve IP address on handover between APs?”.
Modern Wireless WiFi Controller could split big broadcast domain on independent AP domains and play stateful proxy – it would limit number of multicast messages per one AP band – it should resolve 2k multicasts per second problem.
Stateful proxy for Stateless protocol (SLAAC) - looks like not good architecture decision, looks like work-around, but not much choice left.
We are close to the situation that WiFi would resolve multicast problems by itself. Especially at times when WiFi is becoming faster and faster (1G->10G).
It is not mandatory to help WiFi – they would survive by themselves, they would find proper set of work-arounds.
The final point could be to move to Overlay completely and put SLAAC in P2P topology (like 3GPP) – proxy everything on AP/Controller. Degenerate case would work perfectly fine, host would not spot any difference.


There is a well-known story about 50B of IoT devices that additionally to WiFi problems would have: (1) low power, (2) sleeping mode, (3) low bandwidth,
Where multicast just not a question that make sense to discuss in principle.

One important question that was not touched here yet: is multicast a something that is needed only for internal network operation or is it important for end user services too?
Unfortunately the answer is negative.
Primary multicast application (any media: video or audio) is moving away from “broadcast mode” to “personalized user stream”, even Carriers have migrated from IPTV STB (multicast) to OTT STB (unicast).
It is not because of technology, users prefer personalized content more and more.
Multicast is becoming something that is demanded primarily by technical geeks for their toys. It is less and less a business requirement.

Eduard
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: 12 августа 2020 г. 1:03
To: Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>>
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>; IPv6 List <ipv6@ietf.org<mailto:ipv6@ietf.org>>
Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups

Hello Ted

Some APs and controllers snoop the protocols and turn broadcasts to unicast day or drop them. The problem is that snooping gives us only an imperfect view of who is connected with IPv6.

I know for having written such code and tons of tricks, some of which we published either as drafts or patents.

We found the result to be non-satisfactory largely because of the limitations of snooping. So we brought RFC 8605 yo the IETF with no IPR attached.

I guess others will have to go through the same hassles ad we did and still do before they realize why we ended up with a stateful ND, not for all situations but for many modern use cases that involve a solid state in the network. Including APs. And fabrics.

I’m happy that Fred uses BGP, we do that too in eVPN. But how do you feed BGP? If the host does not speak BGP then we need a host to router interface that has similar properties but is abstract to the routing protocol.

There’s already 2 protocols, RPL and RIFT, that benefit from RFB 8505 advertisements to inject (redistribute) host addresses.
Take care,

Pascal

Le 11 août 2020 à 22:58, Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>> a écrit :
 On Aug 11, 2020, at 4:47 PM, Fred Baker <fredbaker.ietf@gmail.com<mailto:fredbaker.ietf@gmail.com>> wrote:
On the air interface, they are either transmitting or not. In the receiving NIC, the question is whether or not they store the message; if they are not configured to receive a certain multicast group, regardless of transmission type, they receive and store the message and then forget that they have done so, re-using the buffer for the next message. If they forward the message on, it uses the bandwidth on the other side, whatever it is, with the same destination address.

The place where one might distinguish “broadcast” from “multicast” is on a data center switch, where “multicast” might mean keeping a list of relevant ports and only sending to them. They want to send a message once. If they are sending the same message several times, “to whom” is an important question.

Hm. What I do know about WiFi is that actual multicast messages are not acknowledged (because they can’t be) and are therefore sent at lower data rates, so that multicasts occupy much larger time slices per packet. A multicast is notionally only intended for a subset of all connected nodes. If the WiFi base station knows which nodes are interested in a particular multicast address, and that number is small, then it would nearly always be faster to transmit the message to each node as a unicast.

The question is, for a particular WiFi AP, can it know which of its connected WiFi nodes are interested in a particular NS, or do we have to multicast it to every node?

If this is known in the data center, then it must be known on the AP, right?

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------