Last Call Review of draft-ietf-mpls-ldp-multi-topology-09
review-ietf-mpls-ldp-multi-topology-09-secdir-lc-moriarty-2013-11-07-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.

Review:
It is unclear to me how there could not be any security considerations.  The
draft introduces the ability to segregate traffic, allowing for the MT
capability to be supported and then transitioned to equipment where the
capability is not supported.  See section 3.2:

If an LSR is changed from IGP-MT capable to non-MT capable, it may
      wait until the routes update to withdraw FEC and release the label
      mapping for existing LSPs of specific MT.

The introduction states this feature may be used to segregate traffic for
different purposes, including the use of management traffic.  Typically,
management traffic requires security protections such as session encryption. 
The labeling also appears to allow for labels to change in addition to the
feature support disappearing.  The security considerations should at least
mention that no additional protections are offered through this mechanism of
segregating traffic, so that the reader is informed of this risk.  The
advantages may be limited to QoS and other possible benefits.  Users should be
aware that the segregation offers no security advantage over MPLS without MT.

Editorial nits:

In Introduction, change from isolated to isolate:
Separate routing and MPLS domains may be used to isolated
      multicast and IPv6 islands within the backbone network.

To: Separate routing and MPLS domains may be used to isolate
      multicast and IPv6 islands within the backbone network.

Change Carries to carry:
 Management traffic could be separated from customer traffic using
      multiple MTs, where the management traffic MT does not use links
      that carries customer traffic.
To:  Management traffic could be separated from customer traffic using
      multiple MTs, where the management traffic MT does not use links
      that carry customer traffic.

Section 3.6: Change "imply" to "simply":
Since using different label spaces for different topologies would
   imply significant changes to the data plane, a single global label
   space is supported in this solution.
Change "peer" to "peers":
There will be one session
   supported for each pair of peer, even there are multiple topologies
   supported between these two peers.

Section 4.3.4:
Change from:
For the case that the LSP ping with return path not specified , the
   reply packet must go through the default topology instead of the
   topology where the Echo Request goes through.
To: For the case that the LSP ping with return path is not specified, the
   reply packet must go through the default topology instead of the
   topology where the Echo Request goes through.

Section 5.1:
Recommend breaking this text into multiple sentences.

Section 6:
Change from:
In case the bad things does happen, according
   to [RFC5036], processing of such message should be aborted.
To: In case the bad things happen, according
   to [RFC5036], processing of such messages should be aborted.

Section 7: I recommend breaking the second paragraph into multiple sentences.

Best regards,
Kathleen