Re: [v6ops] Interesting problems with using IPv6

Andrew 👽 Yourtchenko <ayourtch@gmail.com> Wed, 10 September 2014 10:18 UTC

Return-Path: <ayourtch@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 9D2CA1A06E6 for <v6ops@ietfa.amsl.com>; Wed, 10 Sep 2014 03:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 wakHGB5tBtJA for <v6ops@ietfa.amsl.com>; Wed, 10 Sep 2014 03:18:30 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC5F1A06DA for <v6ops@ietf.org>; Wed, 10 Sep 2014 03:18:30 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id rl12so5785056iec.14 for <v6ops@ietf.org>; Wed, 10 Sep 2014 03:18:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6wY3DWnzi88vMONWSVExh6SI9AwZeMoP50SfVQo8/3Y=; b=nEr8KMKf7eMTn7TppJVblGIyrtGNEXzqrw1LSZqYAwrcxTDurjeMKknIcC8P1XPaON BPoPnVg2bFHG+VFdsO4HIl2GxXrphpZQUn9TdYVkO0do2A5zEpqIoXbxob47D2N485sC 9i8NAO5aLs+9MWyjF9Y4bTQvv4ynJ+2NcHpkcWQHRMuGqeOw+N01kPv1Xzl2aNwiDBeZ 2F/w3tZaiQd52rGvqS+pySQ9nsr8cD3rUF2fzBtl7Yu2RkWYDSQ/d33F2sGJmNAN0wEx omjbEcu01T1P6SRJa+V91q0jUkJC7/39jI5jFGtAgqr5OYFdvJyhsfJaBNbRkpudFX8w 1LZg==
MIME-Version: 1.0
X-Received: by 10.42.23.16 with SMTP id q16mr45913769icb.0.1410344309798; Wed, 10 Sep 2014 03:18:29 -0700 (PDT)
Received: by 10.107.137.39 with HTTP; Wed, 10 Sep 2014 03:18:29 -0700 (PDT)
In-Reply-To: <540FB46F.2010200@gmail.com>
References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar> <540F3432.5030702@innovationslab.net> <540F65C4.7050503@gmail.com> <540F9FA9.3070300@si6networks.com> <540FB46F.2010200@gmail.com>
Date: Wed, 10 Sep 2014 12:18:29 +0200
Message-ID: <CAPi140MmfaqG9kFNTdAi=RhH8YJDV2OVXYvi4FgxvkD_mEQx=Q@mail.gmail.com>
From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= <ayourtch@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_OW6mBlTqnaxddXf6_e1vHTift0
Cc: Fernando Gont <fgont@si6networks.com>, 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: Wed, 10 Sep 2014 10:18:31 -0000

On 9/10/14, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> On 10/09/2014 12:47, Fernando Gont wrote:
>> On 09/09/2014 05:40 PM, Brian E Carpenter wrote:
>>>>> Then, let me change the question: Why do I need MLD for *this*?
>>> I think Brian Haberman's reply shows why that is the wrong question.
>>> You need MLD for every multicast group, including a solicited-node
>>> group, and if you insist on MLD snooping in the bridges (let's not
>>> obfuscate by calling them switches) then you need to snoop every
>>> solicited-node group.
>>>
>>> My question is orthogonal to MLD snooping: why do we require
>>> router-alert
>>> for MLD messages referring to a solicited-node group, since it by
>>> definition is limited to a single L2 link (even if that link is
>>> split up by bridges)?
>>
>> .. to avoid them being a special case?  -- i.e., all MLD packets carry a
>> Router Alert option.
>
> Yes, it would be an exception. But we know that HbH options in general
> and Router Alert in particular are a serious performance issue, and
> that all links carry this particular kind of MLD traffic, so an
> exception seems like something to be discussed.

How does this interact with the case where a "pure L2" switch within
the link would want to snoop MLD ? Presumably, today the L2 switch
would see the "router alert" and know that it needs to process this
traffic.

If this were to be removed, then it would be much trickier to direct
the traffic to the slow path in that scenario, wouldn't it ?

--a

>
>> And, actually, an MLD report could potentially
>> include groups other than solicited-node (so you probably wouldn't want
>> to turn the "include a router-alert" on and off).
>
> Sure, the exception would have to be for messages containing only
> solicited-nodes data.
>
>    Brian
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>