Subject: RE: MLDv2 and RFC2461bis

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 12 Jul 2005 03:21:57 -0400

> This is a very purist view.  Even if you don't tell them 
 > what to do, at 
 > least give them a hint that they ought to think about the issue.
 > I suggest you put in a pointer to s.8 of 3810.

=> I don't think there is a problem with adding a hint. The issue
is 2461bis is not the right place for it. I guess whoever updates
3810 in future can consider this point. For now I think it's
sufficient to add a reference in 2461bis.

Hesham

 > 
 > Regards,
 > Elwyn
 > 
 > Soliman, Hesham wrote:
 > 
 > > > > My understanding that as well as a reference to MLDv2 we 
 > > > would need to 
 > > > > mention that if any of the routers are 'legacy' that 
 > support only 
 > > > > MLDv1, then any MLDv2 routers would have to have their 
 > > > configuration 
 > > > > flags set to make them operate in MLDv1 compatibility 
 > > > mode.  Hosts on 
 > > > > the other hand willl behave correctly whether they are 
 > > > MLDv2 or only 
 > > > > MLDv1 capable.
 > > > 
 > > > I don't think we want to add MLD configuration guidance in 
 > > > 2461bis.  If 
 > > > someone is
 > > > running a mix of MLDv1 and MLDv2 routers, they need to be 
 > > > aware of the 
 > > > operational
 > > > guidance provided in RFC 3810.
 > >
 > >=> Agreed. This seems like a 3810 issue of how to manage different
 > >versions on the same link (or ban it). 
 > >
 > >Hesham
 > >
 > > > 
 > > > Brian
 > > > 
 > >
 > >===========================================================
 > >This email may contain confidential and privileged material 
 > for the sole use
 > > of the intended recipient.  Any review or distribution by 
 > others is strictly
 > > prohibited.  If you are not the intended recipient please 
 > contact the sender
 > > and delete all copies.
 > >===========================================================
 > >
 > >  
 > >
 > 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 12 Jul 2005 08:49:19 +0100

I was thinking of something along the lines of:

...joining and leaving the solicited-node multicast group SHOULD be done 
using MLD v1 [MLD] or v2 {RFC3810]. Section 8 of [RFC3810] explains how 
nodes using MLDv1 and MLDv2 can coexist on a link.

Elwyn

---

From: Brian Haberman <[email-masked]>
Date: Tue, 12 Jul 2005 09:58:27 -0400

On Jul 12, 2005, at 3:49, Elwyn Davies wrote:

> ...joining and leaving the solicited-node multicast group SHOULD be 
> done using MLD v1 [MLD] or v2 {RFC3810]. Section 8 of [RFC3810] 
> explains how nodes using MLDv1 and MLDv2 can coexist on a link.
>

Two things with this suggestion.  First, the above text may be seen as a
Normative reference to RFC 3810.  That won't work for 2461bis given that
3810 is PS.  The second issue is that I still don't see the benefit of 
adding
operational guidelines for MLD in this spec.  I agree with Hesham that 
it
belongs somewhere and that somewhere is section 8 of RFC 3810.

If someone recognizes that they are mixing MLD versions, then I would
hope/expect that they are aware of the guidelines in 3810 already before
they get to any issues in 2461bis.  To me, it would be similar to having
text providing hints on interoperability between DHCPv6 and DHCPv6-lite
(as an example).

Regards,
Brian

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 12 Jul 2005 15:38:11 +0100

I can see that the world is against me here ;-) , but I am not sure that 
giving in quietly is actually the right answer in this case!
If you are offering alternatives, it is a legitimate question to ask 
whether all nodes in some context have to use the same alternative to 
achieve interoperability - we know that they don't have to and can say 
so in one short sentence!

Brian Haberman wrote:

> 3810 is PS.  

I have to say that this would be a rather hair splitting view, but you 
may well be right - I am not sure that saying you SHOULD use something 
is not normative but that pointing someone to a section of the document 
in case they do use it makes it normative.

> The second issue is that I still don't see the benefit of adding
> operational guidelines for MLD in this spec.  I agree with Hesham that it

or maybe in node requirements?  Anyway is this really an operational 
guideline?  I am not proposing you say what to do but rather that we 
*have* thought about it and 3810 has the answer.

> text providing hints on interoperability between DHCPv6 and DHCPv6-lite

It seems to me that there is a difference here: whether or not 2461bis 
says SHOULD use MLD all the routers around appear to implement MLD and 
(AFAIK) turn it on by default. People endeavouring to use IPv6 for 
unicast who are not interested in multicast may know little or nothing, 
and care less about MLD (sorry).  People who are using DHCP are making a 
poitive choice for it.

However, be that as it may, router vendors are going to have to point 
this issue out to their clients, and they need to be reminded to do so 
by some means.

Enough of this - Just make sure it doesn't get lost down the cracks!

Regards,
Elwyn

---

From: Brian Haberman <[email-masked]>
Date: Tue, 12 Jul 2005 12:56:23 -0400

Elwyn,

On Jul 12, 2005, at 10:38, Elwyn Davies wrote:

> I can see that the world is against me here ;-) , but I am not sure 
> that giving in quietly is actually the right answer in this case!

    Perhaps a review of Section 8.3.2 of RFC 3810 will clarify the
issue.

    The multicast-capable routers that support MLDv2 will manage
MLDv1 compatibility mode per multicast address.  That is, it will
only revert to MLDv1 mode for those addresses in MLDv1 Report
messages.  The routers will retain MLDv2 mode for other addresses
that are being reported in MLDv2 Report messages.

      Since the addresses at issue here are link-local in scope, having
them reported in an MLDv1 Report will not adversely affect the
multicast infrastructure supporting SSM via MLDv2.

Regards,
Brian