Skip to main content

Last Call Review of draft-ietf-mpls-mldp-hsmp-04
review-ietf-mpls-mldp-hsmp-04-secdir-lc-kaufman-2013-12-05-00

Request Review of draft-ietf-mpls-mldp-hsmp
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-12-10
Requested 2013-11-28
Authors Lizhong Jin , Frederic JOUNAY , IJsbrand Wijnands , Nicolai Leymann
I-D last updated 2013-12-05
Completed reviews Genart Last Call review of -04 by Roni Even (diff)
Genart Telechat review of -05 by Roni Even (diff)
Secdir Last Call review of -04 by Charlie Kaufman (diff)
Assignment Reviewer Charlie Kaufman
State Completed
Request Last Call review on draft-ietf-mpls-mldp-hsmp by Security Area Directorate Assigned
Reviewed revision 04 (document currently at 06)
Result Has nits
Completed 2013-12-05
review-ietf-mpls-mldp-hsmp-04-secdir-lc-kaufman-2013-12-05-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This document defines a new variation of MPLS for multipoint to multipoint
communication. The document does not state why anyone would prefer this new
variation over the existing one, though I can guess a few reasons. The new
variation is less efficient in that packets sent travel over many links twice
instead of once and packet delivery has longer latency in that most packets
travel over more links from their original source to ultimate destination. The
two advantages I can imagine are (1) in almost all cases, all packets will
arrive at all destinations in the same order (in the original protocol, packets
from different sources could arrive at different destinations in different
orders); and (2) the root of the multicast tree could filter messages - for
example, to throttle the total volume of messages from a single source. A third
possible use that seems to be disavowed by the document is to allow members of
the multicast group to signal their status only to the root node. It would be
nice if the document was more explicit about what this protocol was for, but it
doesn't affect security considerations.

The document correctly notes that there are no new security considerations
beyond those discussed in the protocol that this competes with. That protocol 
is defined in RFC6388 and RFC6425.

Nits:

Last sentence of abstract reads "The communication among the leaf nodes are not
allowed." I believe the grammar is incorrect, but more importantly I believe it
should read "Direct communication among the leaf nodes is not allowed." because
communication among the leaf nodes is supported by this protocol with all
packets being relayed by the root node.

Near the end of the introduction  is the phrase "except that it follows the
node of reverse downstream path of the tree". I believe the word 'node' is
incorrect here, though I don't know what was intended.

Page 11: "In some scenario," should be "In some scenarios,"

        --Charlie