During the IESG review of the multicast router discovery
draft (draft-ietf-idmr-igmp-mrdisc-10.txt), it was noted that
the option defined in section 7.2 is very similar to the mipv6
interval option defined in section 7.3 of the mipv6 spec.

     A suggestion was made that we combine these two options
and utilize the reserved field in the mipv6 spec to indicate
whether the option applies to the mipv6 or the mrd interval
being advertised.  What are your thoughts on this?

     The two immediate things that come to my mind are that
the timer granularities are different.  The mipv6 option uses
milliseconds and the mrd option is in seconds.  The other is
whether or not there are any issues with having the option
appear twice in an RA if the router is supporting both
protocols.

     If we were to go down this path, it would probably
require the extraction of the option from the mipv6 spec into
a separate spec.

     Comments, thoughts, suggestions? 

----------

Jari Arkko responds to Brian Haberman: Is my understanding correct
that the mrdisc parameter defines the MLD query interval? The MIPv6
option defines the RA interval. These are separate behaviours
involving different ICMP messages, even if both are broadcast and sent
by the same routers. This must be reason which leads to the need to
use a flag that you mention below? I suspect the interval values are
also likely different -- supported by the fact that the units are
different.

Hmm... to me it starts to sound like the options really should be
different options, if they don't share anything common.  Are we in
short supply of ND option space? Checking... hmm...  256 values
available in theory. I don't know about the current allocation
status. Is the lack of values the reason that the IESG wants to merge
the options?

Or perhaps the concern is that the length of RAs is getting larger,
with new options? But in order to fix that we would need to have a
common interval, which does not appear possible at the moment.

Strawman proposal: keep the two options separate since they share no
common semantics. I don't think we are going to run out of ND option
space, MLD and MIPv6 are pretty fundamental pieces of technology and
we are unlikely to come by a lot of similar extensions in the
future. But if we do run out of the space, we could use the technique
that we employed in EAP -- we reserved the last number for extended
space, and all messages that use this last number begin with a 32 bit
number which is the real type.

Or did I miss something? 

----------

Brian Haberman responds to Jari Arkko: Jari, I tend to agree with your
assessment.  In essence, you could derive the unit of measure from the
option type that identifies the multicast vs. the unicast usage, but
the benefit really doesn't seem to justify the cost.

Any differing opinions? 

----------

----------