Re: [v6ops] Interesting problems with using IPv6

Mark,

My point is that it's worth *understanding* such problems and then
perhaps writing up operational or implementation recommendations.
Exactly what the v6ops charter says we should do, in fact.

"1. Solicit input from network operators and users to identify
operational issues with the IPv4/IPv6 Internet, and
determine solutions or workarounds to those issues. These issues
will be documented in Informational or BCP RFCs, or in
Internet-Drafts."

Or recommend protocol changes if they might help, which is why I
want to understand the value of Router Alert in MLD messages for
Solicited-Node multicast addresses. Or should we revive
draft-pashby-magma-simplify-mld-snooping-01?

    Brian

On 09/09/2014 13:55, Mark ZZZ Smith wrote:
> 
> 
> 
> ----- Original Message -----
>> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
>> To: Dale W. Carder <dwcarder@wisc.edu>
>> Cc: IPv6 Operations <v6ops@ietf.org>; l.wood@surrey.ac.uk
>> Sent: Tuesday, 9 September 2014, 7:59
>> Subject: Re: [v6ops] Interesting problems with using IPv6
>>
>> I switched to the relevant list.
>>
>> On 09/09/2014 06:33, Dale W. Carder wrote:
>>>  Thus spake Brian E Carpenter (brian.e.carpenter@gmail.com) on Mon, Sep 08, 
>> 2014 at 07:50:26AM +1200:
>>>>  If they really are interesting problems, it might be more to the
>>>>  point to analyse them over on v6ops. Given the number of large
>>>>  IPv6 deployments that don't have such problems, it seems like
>>>>  this particular deployment hit an unfortunate combination of
>>>>  implementation issues.
> 
> 
> If this email is referring to this blog post:
> 
> http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/
> 
> 
> then I think this particular network was already on the verge of catastrophic failure, and some of IPv6's ND differences were just the trigger to push it over that threshold.
> 
> 
> According to the blog post, they might have:
> 
> - hardware errors
> - software errors
> - 'bridge loops' causing the control plane to overload
> 
> In some of these cases they've taken actions to try to resolve them, however the actions taken seem to be based on speculating what is happening rather than finding evidence to support the hypothesised cause before taking action.
> 
> For example, there isn't any evidence that they've actually determined that 'bridge loops' are occurring, found out what is causing them, and then taking measures to prevent them or at least reduce the chances of them occurring. If a 'bridge loop' can cause the control plane to overload, then adding anything to this network like IPv6 is likely to only make the problem worse.
> 
> I'd like to see them get to the bottom of and then fix these 'bridge loop' and other problems first before any value is placed on addressing their criticisms of IPv6. Other people have deployed IPv6 without these problems, so what is different between this network and everybody else's that doesn't have these sorts of problems?
> 
> 
> 
>  That is worth understanding (for example,
>>>>  how large is the layer 2 network that leads to the MLD listener
>>>>  report overload?).
>>>  Implementing MLD snooping for Solicited-Node multicast addresses 
>>>  is probably a bad idea.
>>>
> 
>>>  See: draft-pashby-magma-simplify-mld-snooping-01
>> OK, but I would also like to understand why we require
>> MLD messages for a Solicited-Node multicast address to
>> set Router Alert.
>>
>>     Brian
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> 