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