Re: [v6ops] Interesting problems with using IPv6

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 16 September 2014 00:03 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1703F1A0066 for <v6ops@ietfa.amsl.com>; Mon, 15 Sep 2014 17:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 KTqjLHLi0rsP for <v6ops@ietfa.amsl.com>; Mon, 15 Sep 2014 17:03:26 -0700 (PDT)
Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DDA1A0049 for <v6ops@ietf.org>; Mon, 15 Sep 2014 17:03:25 -0700 (PDT)
Received: by mail-pd0-f171.google.com with SMTP id p10so7345955pdj.30 for <v6ops@ietf.org>; Mon, 15 Sep 2014 17:03:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=F40BjTL0wLBy8Y2/BDDkbEdjaf4w7mbJDbdk37zDvSo=; b=R18ExzzYGBM+hfgkNZ4HJkDSkcxvGfERntuU7icmgdS0TPyTsoqaNlqiwGKOvMs3UN xeXKX2zzmIUj0Wj8aSboivd4SXwM+X7k6Pm/JP0eHXwInR4povZiy0WYaiNyaY66sFBu R6YnGb+W4cbWw9P3k0Ld+eqNAnn+BQNMTz1ZhgMHoy9wpviOuGpxOAGo+cAChrlOQhxe QJR9XD1nSdalmIFFd1FSZcOLHOs+IvOK/r8e4NtgZESXJjNwXhN30kt9ZxR9muX42WOI 4oE34xOCtXss54gQtLihQ7jPO8bZmkJYuo5Pmgf+djDqXih2VvopHemECvDsAdTTfoi1 qAIg==
X-Received: by 10.70.131.199 with SMTP id oo7mr52157017pdb.95.1410825805685; Mon, 15 Sep 2014 17:03:25 -0700 (PDT)
Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id cz1sm2916928pdb.85.2014.09.15.17.03.23 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Sep 2014 17:03:25 -0700 (PDT)
Message-ID: <54177E4B.5010004@gmail.com>
Date: Tue, 16 Sep 2014 12:03:23 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Nick Hilliard <nick@foobar.org>
References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540E6299.2050003@gmail.com> <1410743000.11973.YahooMailNeo@web162204.mail.bf1.yahoo.com> <54166EE5.9080007@gmail.com> <alpine.DEB.2.02.1409150702180.14735@uplift.swm.pp.se> <54174A26.1050206@gmail.com> <541778F8.8090605@foobar.org>
In-Reply-To: <541778F8.8090605@foobar.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xC1_UjDt0sXICIDR61q0MlbhcIc
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Interesting problems with using IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 16 Sep 2014 00:03:28 -0000

On 16/09/2014 11:40, Nick Hilliard wrote:
> On 15/09/2014 21:20, Brian E Carpenter wrote:
>>> How else is L2 equipment going to make intelligent decisions about
>>> multicast forwarding within an L2?
>> They're not. That's why DEC Gigaswitches had ARP throttling, for example,
>> to control broadcast storms. It's unavoidable if you build big L2
>> networks. I learnt not to do that.
> 
> let's be careful what we're talking about here.  The problems of yesteryear
> were related to large broadcast domains.  The problems we're discussing
> here relate to modest-sized broadcast domains, but potentially with a large
> number of them traversing a single switch.  These are different problem
> spaces and it is not helpful to confuse the two.

Well, that's true, and the definition of "large" has changed
as microelectronics has continued to improve. But the point is
that for any particular scenario and generation of technology,
there is scaling limit for L2. What you say below is also
very true.

    Brian

> 
> This original issue brings up a number of awkward questions about
> scalability, which at heart is a protocol design issue and not - as stated
> by others - either a vendor implementation issue or a protocol issue.  The
> IETF created a protocol dependency mechanism to assist scalability by
> allowing large numbers of v6 addresses to exist on the same l2 network
> (both single broadcast domain and multiple broadcast domains).
> 
> The mechanism operates along the lines of:
> 
> - ND depends on multicast for basic functionality
> 
> - ND multicast addressing uses multicast groups to assist scalability
> 
> - MLD is implemented to help l2 devices decide how and where to prune v6
> multicast transmission
> 
> - this mechanism pushes state into the l2 forwarding control plane (SP =
> switch processor)
> 
> - privacy addresses increase the number of v6 addresses on any single/multi
> broadcast domains by an order of magnitude, give or take.
> 
> - anecdotally, it seems that the continued existence of large-ish but
> segmented multiple vlan l2 networks and the advent of privacy addresses
> means that switches are seeing a problematic quantity of state being pushed
> to the SP on some networks.
> 
> Stepping back a little to broadcast vs multicast, the v6 protocol was
> designed this way to work around the rampant broadcast storm problems of
> the 1990s where large broadcast domains were all the rage.  Those who were
> around at the time will remember windows 3.1 cpus pegging due to 10 megs of
> broadcast traffic on the campus /16.  In this sort of situation, mld
> snooping might well have worked nicely to stop problems at the network edge
> 
> The problem set has changed - modern networks rarely use large flat
> networks but instead segment networks into large numbers of vlans on a
> shared physical infrastructure.  This means that today, the protocol that
> was designed to help at the network edge is hurting at the network core and
> we are applying a solution to a problem which largely no longer exists in
> its original context.
> 
> The irony is that the solution which was created to allow ipv6 to scale on
> large layer 2 domains is restricting scalability on large layer 2 domains.
>  We have merely swapped one scaling problem for another.
> 
> Nick
> 
> (*) there is an exception in large scale virtualised infrastructure, where
> VM networking people have not learned the lessons of the past and there is
> a massive push to create underlay protocols to allow enormous l2 domains
> which span multiple locations.
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>