Re: [v6ops] Interesting problems with using IPv6

[Brian E Carpenter <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>