[magma] mrdisc-00 comments

[Pekka Savola <[e-mail]>]

Some comments on the new, revamped document.  Good stuff -- but there 
are some rather minor odds and ends which should be fixed.

substantial
-----------

                       Multicast Router Discovery

==> I'd consider rewording this to "Link-local Multicast Router Discovery"
(LLMRD) or something like that, to better reinforce the applicability from
the start.  If done, this would have to be rippled through to the rest of
the document.

   Advertisements are sent

     1. Upon the expiration of a periodic timer

==> note that this doesn't say anything about randomization, which is
referred to in other sections, such as 3.4!

   The Query Interval field is set to the Query Interval value in use
   by IGMP or MLD on the interface.  If IGMP or MLD is not enabled on
   the advertising interface, this field MUST be set to 0.

==> If I recall correctly (can't check, on the airplane... :),
query interval and robustness variable were encoded in the IGMP/MLD
in some wacky format.  What's the presentation format here?

   Advertisement messages are sent when the following events occur:

==> would it be worth noting, that a configuration change in
robustness/query interval values is NOT a reason to regenerate this message
-- BUT remind that the next scheduled advertisement message should include
the current variable values!

   Solicitations are sent to the All-Routers multicast address and
   SHOULD be rate-limited. 

==> solicitations are sent only when MRD is enabled, or the interface is
re-initialized.  It should be obvious as these don't happen all too often. 
Therefore, I think we should remove this completely.

   Should a Multicast Router Terminate message be spoofed with the
   source address of a valid multicast router, a device may discontinue
   forwarding of multicast source data to that router. This would
   disrupt the reception of this data beyond the local subnet.

==> the current specification does not even check the source address, other
than being link-local, so this spoofing is even more trivial.  Slight reword
here please :-)

   This document also introduces three new MLD messages.  Each of these
   messages requires a new ICMPv6 Type value.  This document requests
   IANA to assign three new ICMPv6 Type values to the Multicast Router
   Discovery Protocol (for IPv6 Advertisements, Solicitations, and
   Terminations).

==> one should probably specify from which range (Informational, for ICMPv6)
these should be allocated from.  And for better clarity, one should probably
use a presentation format like:

IGMP Type        Section         Message Name
X1               3.1             Multicast Router Advertisement
Y1               4.1             Multicast Router Discovery
Z1               5.1             Multicast Router Termination

ICMPv6 Type      Section         Message Name
X2               3.1             Multicast Router Advertisement
Y2               4.1             Multicast Router Discovery
Z2               5.1             Multicast Router Termination

10. References

  10.1 Normative References

  10.2 Informative References

==> should really add something, e.g. ND for Normative and
draft-ietf-send-ndopt for Informative.

editorial
---------

Abstract

   The concept of IGMP snooping requires the ability to identify the

==> s|IGMP|IGMP/MLD| (plus one should spell these out!)

   
   Multicast Router Discovery messages are useful for determining which
   nodes attached to a switch have multicast routing enabled.  This 
   capability is useful in a layer-2 bridging domain with snooping    
   switches.  By listening to MRD messages, layer-2 switches can 
   determine where to send multicast source data and group membership 
   messages [RFC1112][RFC2236].

==> yes, the switches need to "listen" to MRD messages as well, but they can
also send them -- maybe reword: s|listening|listening and/or sending| ?


   Advertisement messages are sent when the following events occur:

        . The expiration of the periodic advertisement interval timer.
           Note that it this timer is not strictly periodic since it is
           a random number between MaxAdvertisementInterval and
           MinAdvertisementInterval.
        . After a random delay less than

==> following the style of the previous section, I'd rather use "1.", "2."
etc. or "o" or "-" than "." as a bullet marker -- the same elsewhere.

   An Advertisement not meeting the validity requirements MUST be
   silently discarded or logged in a rate-limited manner. 

==> discarding is not optional, so I'd reword: s/or/and may be/ 
The same elsewhere in the document.

        . After waiting for a random delay less than 
           SOLICITATION_INTERVAL when an interface first becomes

==> this constant was not mentioned in the protocol constants section.

13. Full Copyright Statement

==> please add IPR boilerplate in a section prior to this.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


_______________________________________________
magma mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/magma