Re: [v6ops] Interesting problems with using IPv6

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
>