I have reviewed this document following a request from the routing Area director to the security directorate. This is an early review, for the benefit of the security area director, the transport area director, and the document authors. Multi topology routing using MPLS. As I understand it from my 10,000ft high point of view, within a graph of routers and links, instead of just computing a single set of forwarding tables with a single routing metric such as "shortest path", MTR allows for computing multiple such forwarding tables, each using specific metrics and possibly specific constraints. Each set of forwarding tables and selected paths is regarded as a topology. The multiple topologies can be computed using the Multi-Topology Routing (MTR) extensions to IGP such as OSPF or IS-IS, or the MTR extensions to the Label Distribution Protocol (LDP). The draft is concerned with creating such topologies using MPLS, starting with point to multipoint or multipoint to multipoint MTR graphs established with Multipoint LDP (mLDP). The flexible algorithm (FA, RFC9350) is used to create sub-topologies from existing topologies, by applying constraints. The draft goes no defining the protocol elements to add such functions to LDP, defining topologies for IPv4 or IPv6, ensuring support for multipoint, or defining how to use Label Switched Path (LSP) Ping to test the topologies. Such drafts may be easy to read when people are very familiar with the current work in the routing area. For me, they were a bit of a stretch. I would probably need much more time than assigned to this review to fully understand how the various mechanisms interoperate, beyond the 10,000ft view mentioned earlier. My high level summary would be that this draft defines an extension, so simple mechanisms like LDP can now be used to create a variety of topologies. The classic risks with extensions are resource exhaustion and the difficulty to manage the increased complexity. The security section says that "This extension to mLDP does not introduce any new security considerations beyond that already apply to the base LDP specification [RFC5036], base mLDP specification [RFC6388], and MPLS security framework [RFC5920]." That may very well be true, but I would encourage the authors to examine at least two risks: creating multiple topologies create additional work in the "control plane", thus potential resource exhaustion if trying to support too many topologies; traffic carried by multiple topologies may end up competing for finite data plane resource, thus risking local overload. I am speculating, but have the authors studied the corresponding failure modes? How hard is it for configuration mistakes or adversarial actions to exploit such failure modes?