Skip to main content

Early Review of draft-ietf-mpls-mldp-multi-topology-05

Request Review of draft-ietf-mpls-mldp-multi-topology
Requested revision No specific revision (document currently at 07)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2024-05-03
Requested 2024-04-18
Requested by Jim Guichard
Authors IJsbrand Wijnands , Mankamana Prasad Mishra , Syed Kamran Raza , Zhaohui (Jeffrey) Zhang , Arkadiy Gulko
I-D last updated 2024-05-02
Completed reviews Rtgdir Last Call review of -03 by Yingzhen Qu (diff)
Rtgdir Early review of -05 by Mike McBride (diff)
Opsdir Early review of -05 by Linda Dunbar (diff)
Secdir Early review of -05 by Christian Huitema (diff)
Genart Last Call review of -05 by Roni Even (diff)
Rtgdir Early review of -02 by Gyan Mishra (diff)
Assignment Reviewer Christian Huitema
State Completed
Request Early review on draft-ietf-mpls-mldp-multi-topology by Security Area Directorate Assigned
Posted at
Reviewed revision 05 (document currently at 07)
Result Ready
Completed 2024-05-02
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

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?