[magma] Re: Last Call: Multicast Router Discovery SSM Range Option to Proposed Standard

[Pekka Savola <[e-mail]>]

Hi,

On Mon, 30 Jun 2003, The IESG wrote:
> The IESG has received a request from the Multicast & Anycast Group 
> Membership Working Group to consider Multicast Router Discovery SSM 
> Range Option <draft-ietf-magma-mrdssm-03.txt> as a Proposed Standard.  
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the 
> [e-mail] or [e-mail] mailing lists by 2003-7-14.

A few comments.

The most important first:  I don't believe this is the right approach to
enable administratively scoped SSM group range configuration at hosts.  
Instead, if admin scoped SSM group ranges are really necessary, one should
specify a part of the 232/8 SSM space or a part of the reserved 239/8
(ASM) space for this purpose, and leave it at that (or even reserve some
other /8 for admin-scoped SSM but that would seem like an overkill).  For
proper operation, all hosts and routers have MRD and SSM range option, and
this seems like an overkill.

There seems to be some form of support for this kind of change in the WG.  
In that event I might suggest that this RFC will not be published, or that 
it will be published as Info/Experimental with a disclaimer.

As for the other comments:

substantial:
------------

     Multicast Router Advertisement messages are IGMP messages sent to
the All-Systems multicast group (224.0.0.1) which is not forwarded by   
routers. Only rogue systems on a connected link can masquerade as
multicast routers. Such rogue systems can include the SSM Range
Discovery option in their messages and cause the SSM range mapping to be
incorrectly set by hosts on the link. The next Multicast Router
Advertisement from a real valid router on the link will restore the
correct mapping. 

==> will restore the correct mapping until it's overridden again..

This spec mandates that routers log the reception of
inconsistent range advertisements which makes it easier to detect rogue
systems.

==> as a matter of fact, the spec *doesn't*.  you're probably referring to 
the first bullet in the introduction section, but it actually doesn't 
mandate anything.

semi-editorial:
---------------

==> add IPR considerations and copyrights sections at the end

Mask-Len-n
     The mask length in bits for the nth address range.

==> note that for v4, only 5 bits is required, and if at some point one 
would require similar for v6, that would be 6 bits.  Would it make sense 
to reserve the rest from the 8 bits and have them must-be-zero?


editorial:
----------

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type=X     |   Length=var  |  Mask-Len-1   |    Prefix-1 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Mask-Len-2   |   Prefix-2 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            ...                                |

==> fix the 32th bit on the right ("|")

Type The type value of the Multicast Router Advertisement SSM Range
     Discovery option is X (TBD by IANA).


Length
     The length of the option in octets excluding the type and length
     fields. The length of the SSM Range Discovery option is variable
     and depends on the number of destination ranges present in the
     option as well as the sizes of the ranges.
 

Mask-Len-n
     The mask length in bits for the nth address range.

==> should one say explicitly what's the length of these values (you can 
see it from the diagram, but..) ?

Prefix-n
     The multicast destination address prefix for the nth range present
     in this option. The size of the prefix field is variable and
     depends on the number of significant bits in the prefix (specified
     in the corresponding Mask-Len field). The field is padded by enough
     trailing bits to make the end of the field fall on an octet
     boundary. The value of the trailing bits must be sent as zero and
     ignored on receipt. For example a prefix with a mask length field
     holding the value 16 would have a prefix field that takes up two 
     octets and requires no padding.  A prefix with a mask length of 17
     would have a prefix field that takes up three octets and includes 7
     trailing padding bits.

==> split to two paragraphs at "For example.."
==> note that the definition of padding is slightly ambiguous without the 
example ("padding after each prefix-n, or padding if all of prefix-n don't 
align well")

     The SSM range specified by routers originating Multicast Router   
Advertisement messages with the SSM Range Discovery option MUST not   
include any part of the link-local multicast range 224.0.0/24.  Systems
with a multicast capable IP host stack that receive a Multicast Router
Advertisement message with a SSM Range Discovery option that includes
destination addresses in the link-local multicast range 224.0.0/24 MUST
use as the active SSM range the contents of the option excluding any
addresses in the range 224.0.0/24.

==> reword the last sentence of the paragraph.  IMO, especially the last 
2-3 lines are rather not as clear as one would hope.

9.  Informative References

[3] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", work in
     progress, <draft-ietf-ssm-arch-00.txt>, 21 November 2001.

==> has seen a couple of updates.

-- 
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