RFC 8403

A Scalable and Topology-Aware MPLS Data-Plane Monitoring System

📅 published July 2018, from ietf

RFC 8403 🦋💖

okay bestie, let's get into this one 🧚

A Scalable and Topology-Aware MPLS Data-Plane Monitoring System 🎀 is an IETF doc from July 2018 📅. It's an Informational doc, which means it's sharing knowledge and not a Standards Track spec. The ISSN is 2070-1721 ✨.

The authors are R. Geib, Ed. from Deutsche Telekom 💅, plus C. Filsfils, C. Pignataro, Ed., and N. Kumar, all from Cisco Systems, Inc. 🫶. The title block doesn't list any RFCs that it obsoletes or updates 🙈.

Abstract 🦋

this doc describes features of an MPLS path monitoring system and the use cases for it 💜. segment-based routing gives you a scalable, simple way to check the data-plane liveliness of the whole set of paths in a single domain ✨. the MPLS monitoring system adds features on top of the classic MPLS ping and Label Switched Path (LSP) trace, in a very complementary way 🔥. and MPLS topology awareness cuts down on the management and control-plane work for Operations, Administration, and Maintenance (OAM) measurements while also unlocking brand new OAM features 👑.

Status of This Memo 📜

this document is not an Internet Standards Track specification. it's published for informational purposes 🌸.

this doc is a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community 🫶. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every doc the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 💅.

info about the current status of this doc, any errata, and how to send feedback is at https://www.rfc-editor.org/info/rfc8403.

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved 💖.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date of publication. please read these carefully, because they describe your rights and restrictions for this doc 📖. Code Components pulled out of this doc must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🧚.

Table of Contents 🌸

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology and Abbreviations . . . . . . . . . . . . . . . .   5
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   6
   3.  An MPLS Topology-Aware Path Monitoring System . . . . . . . .   6
   4.  Illustration of an SR-Based Path Monitoring Use Case  . . . .   8
     4.1.  Use Case 1: LSP Data-Plane Monitoring . . . . . . . . . .   8
     4.2.  Use Case 2: Monitoring a Remote Bundle  . . . . . . . . .  11
     4.3.  Use Case 3: Fault Localization  . . . . . . . . . . . . .  12
   5.  Path Trace and Failure Notification . . . . . . . . . . . . .  12
   6.  Applying SR to Monitoring LSPs That Are Not SR Based (LDP and
       Possibly RSVP-TE) . . . . . . . . . . . . . . . . . . . . . .  13
   7.  PMS Monitoring of Different Segment ID Types  . . . . . . . .  14
   8.  Connectivity Verification Using PMS . . . . . . . . . . . . .  14
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  15
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     11.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1. Introduction ✨

okay so network operators need to be able to monitor the forwarding paths that carry user packets 👀. the monitoring packets are supposed to get forwarded in the data plane the same way user packets do 💅. Segment Routing (SR) lets packets follow predefined paths and segments, so an SR monitoring packet can stay in the data plane while it passes along one or more segments you want to monitor 🧚.

this doc describes a system as a functional component called the (MPLS) Path Monitoring System, or PMS 🎀. the PMS uses capabilities for MPLS data-plane path monitoring 💖. the use cases here are limited to a single Interior Gateway Protocol (IGP) MPLS domain 🌸. the use cases in this doc treat the PMS as a separate node. even though a lot of the use cases draw the PMS as a physical node, you shouldn't assume that. the node could be virtual 🫶. this system is defined as a functional component that's abstracted so it can have many realizations 🦋. the terms "PMS" and "system" get used interchangeably here 💜.

the system works for monitoring non-SR LSPs, like the ones using Label Distribution Protocol (LDP), and also for monitoring SR LSPs (Section 7 has more info) ✨. compared to non-SR approaches, SR is expected to make this kind of monitoring system simpler, because MPLS topology detection can be based on IGP-signaled segments 🔥. the MPLS topology should get detected and correlated with the IGP topology, which is also detected through IGP signaling 👑. that means a centralized, MPLS-topology-aware monitoring unit can be built in an SR domain 💅. this topology awareness can then be used for Operation, Administration, and Maintenance (OAM) purposes, as this doc describes 🫶.

here's what the system gets you 🎀:

  • the ability to set up an SR-domain-wide centralized connectivity validation 💖. lots of big network operators think a centralized monitoring system is really useful 🙌.
  • the MPLS ping (or continuity check) packets never leave the MPLS user data plane 🌸.
  • SR lets you transport MPLS path trace or connectivity validation packets for every LSP, to all the nodes in an SR domain 🦋. this use case doesn't describe new path-trace features. what the system does add is the ability to set up SR-domain-wide centralized connectivity validation, which is super useful in big network operator domains 💅.
  • the system that sends the monitoring packet is also the one receiving it 🔁. you can pick the payload of the monitoring packet pretty freely 🌈. that means you can send probing packets that look like customer traffic, maybe from several services (like small Voice over IP packets or bigger HTTP packets) ✨. you can also embed useful monitoring data in them, like accurate timestamps, since the sender and receiver share the same clock and sequence numbers that make the measurement easier 🧚.
  • you can set up a flexible MPLS monitoring system in terms of deployment, from one single centralized system to a bunch of distributed systems (say, per region or per service) 💜. and for redundancy, it can go from 1+1 all the way to N+1 👑.

monitoring paths isn't the whole story, though. you also need problem localization 🔍. topology awareness is an important feature of link-state IGPs that big network operators deploy 💖. MPLS topology awareness combined with IGP topology awareness gives you a simple, scalable, data-plane-based monitoring mechanism 🔥. faults can get localized in these ways 🎀:

  • by capturing the IGP topology and analyzing the IGP messages that signal changes to it 👀.
  • by correlating different SR-based monitoring probes 🫶.
  • by setting up an MPLS traceroute packet for a path (or segment) you want to test, then sending it to a node so it can validate path connectivity from that node onward 🧚.

MPLS OAM offers flexible traceroute (connectivity verification) features for detecting and running the data paths in an MPLS domain 💅. by using the ECMP-related tool set offered by RFC 8029 [RFC8029], an SR-based MPLS monitoring system can do the following 🌸:

  • figure out how to route packets along different ECMP-routed paths 🦋.
  • construct ping packets that can be steered along a single path, or along ECMP, toward a particular LER/LSR whose connectivity you want to check 💖.
  • limit the MPLS label stack of a ping packet, so it checks the continuity of each single IGP segment with a maximum of 3 labels 🙌. a smaller label stack can help too, if a router only looks at a limited number of packet header bytes to pick the ECMP path to route the packet along ✨.

you can also execute any path by building suitable label stacks. this lets you execute paths without being ECMP-aware 🌈.

the MPLS PMS can be any server attached to a single interface of the domain being monitored 🫶. the PMS doesn't need to support the full MPLS routing or control plane 💜. what it does need is to be able to learn and maintain an accurate MPLS and IGP topology 🧠. MPLS ping and traceroute packets need to be set up and sent with the correct segment stack 🔥. the PMS must also be able to receive and decode the ping or traceroute packets that come back 👑.

there's a whole variety of protocols you can use to check continuity 🎀. these include Internet Control Message Protocol (ICMP) [RFC0792] [RFC4443] [RFC4884] [RFC4950], Bidirectional Forwarding Detection (BFD) [RFC5884], Seamless Bidirectional Forwarding Detection (S-BFD) [RFC7880] [RFC7881] (see Section 3.4 of [RFC7882]), and MPLS LSP ping [RFC8029] 💖. they can also use any other OAM format the PMS supports 🦋. as long as the packet used to check continuity returns to the server while no IGP change is detected, the monitored path can be considered validated ✨. if monitoring needs a big label stack pushed on, a software-based implementation is usually more flexible than a hardware-based one 💅. so router label stack depth and label composition limits don't limit your MPLS OAM choices 🙌.

RFC 8287 [RFC8287] talks about SR OAM applicability and MPLS traceroute enhancements that add functionality to the use cases in this doc 🌸.

this doc covers both the use cases and a standalone monitoring framework 🧚. the monitoring system reuses existing IETF OAM protocols and leverages Segment Routing (Source Routing), so a single device can send, have exercised, and receive its own probing packets 🔁. because of that, there are no new interoperability considerations 🫶. a Standards Track RFC isn't required, so Informational status is the right fit for this doc 💜.

2. Terminology and Abbreviations 🎀

2.1. Terminology 💅

Continuity Check 🔗: see Section 2.2.7 of RFC 7276 [RFC7276].

Connectivity Verification 🔗: see Section 2.2.7 of RFC 7276 [RFC7276].

MPLS topology 🗺️: the MPLS topology of an MPLS domain is the complete set of MPLS- and IP-address information, plus all the routing and data-plane information needed to address and use every MPLS path in this domain, from an MPLS PMS attached to this domain at any arbitrary access 💖. this doc assumes the MPLS topology is available (it can be detected with available protocols and interfaces) 🌸. none of the use cases will describe how to set it up 🙈.

this doc also adopts the terminology and framework described in [RFC8402] 🦋.

2.2. Abbreviations 💅✨

okay so here's the abbreviation list, bestie. read it once and you'll be fluent 🧚

   ECMP    Equal-Cost Multipath

   IGP     Interior Gateway Protocol

   LER     Label Edge Router

   LSP     Label Switched Path

   LSR     Label Switching Router

   OAM     Operations, Administration, and Maintenance

   PMS     Path Monitoring System

   RSVP-TE Resource Reservation Protocol - Traffic Engineering

   SID     Segment Identifier

   SR      Segment Routing

   SRGB    Segment Routing Global Block

3. An MPLS Topology-Aware Path Monitoring System 🦋

okay this section is giving main character energy 💖

any node that's at least listening to the IGP of an SR domain is MPLS topology aware 👀 (so it knows all the related IP addresses, SR SIDs and MPLS labels). an MPLS PMS that can learn the IGP Link State Database (LSDB), SIDs included, is able to execute arbitrary chains of LSPs. ngl that's a lot of power 💅 to monitor an MPLS SR domain, a PMS needs to set up a topology database of that domain first. the PMS may be used to send ping-type packets that only check continuity along a path chain, using just the topology information. it can also trace MPLS LSPs, which lets it verify their connectivity and the match between control and data planes, respectively. and the PMS can aim suitable MPLS traceroute packets at any node along a path segment 🎀

let's walk through how the PMS builds a label stack to get a packet to LER i, monitor its path to LER j, and then get the packet back 🌸

the PMS may do this by sending packets that carry the following MPLS label stack info:

  • Top Label: a path from the PMS to LER i, expressed as the Node-SID of LER i.
  • Next Label: the path you want to monitor from LER i to LER j. if that path is a single physical interface (or a bundle of connected interfaces), it can be expressed by the related Adj-SID. if the shortest path from LER i to LER j is the one to monitor, the Node-SID of LER j can be used. another option is to insert a list of segments that express the path you want (hop by hop as an extreme case). if LER i pushes a stack of labels based on an SR policy decision and you want to monitor that stack of LSPs, the PMS needs an interface that collects the info it needs to address this SR-created path 🫶
  • Next Label or address: the path back to the PMS. probably no further segment or label is needed here 🙈 once the packet reaches LER j, the steering part is done, and the probe just has to head back to the PMS. the best way to do that is to pop the MPLS stack and reveal a probe packet with the PMS as its destination address (in this case, the source and destination addresses could be the same). if an IP address is applied, no SID or label has to be assigned to the PMS (for example, if it's a host or server sitting in an IP subnet outside the MPLS domain).

the PMS should be physically connected to a router that's part of the SR domain, and it must be able to send and receive MPLS packets through that interface. as mentioned above, routing protocol support isn't required, and the PMS itself doesn't have to take part in IGP or MPLS routing. a static route will do ✨ connecting a PMS to an MPLS domain through a tunnel may be attractive to some operators. but so far, MPLS keeps networks securely separated by avoiding tunnel access to MPLS domains 🔥 tunnel-based access of a PMS to an MPLS domain is out of scope for this document, because it brings additional security aspects with it 🔒

4. Illustration of an SR-Based Path Monitoring Use Case 🌈

4.1. Use Case 1: LSP Data-Plane Monitoring 🧚

here's a picture of the functional component. it can be a physical or virtual system 📸

                  +---+     +----+     +-----+
                  |PMS|     |LSR1|-----|LER i|
                  +---+     +----+     +-----+
                     |      /      \    /
                     |     /        \__/
                   +-----+/           /|
                   |LER m|           / |
                   +-----+\         /  \
                           \       /    \
                            \+----+     +-----+
                             |LSR2|-----|LER j|
                             +----+     +-----+

Figure 1: Example of a PMS-Based LSP Data-Plane Monitoring

for simplicity, let's assume all the nodes are configured with the same SRGB [RFC8402] 💜

let's give the nodes these Node-SIDs: PMS = 10, LER i = 20, LER j = 30 🍓

the goal is a continuity check of the path between LER i and LER j. like we said, the monitoring packets are sent and received by the PMS. let's say the design aim is to work with the smallest possible SR label stack 👑 a pretty simple option is to run an MPLS path trace, as specified by RFC 8029 [RFC8029] (using the Downstream (Detailed) Mapping info from a path trace). the starting point for the path trace is LER i, and the PMS sends the MPLS path trace packet to LER i. the MPLS echo reply from LER i should be sent to the PMS. as a result, the IP destination address choices get detected, and they're then used to target any one of the ECMP-routed paths between LER i and LER j with MPLS ping packets, to check path continuity later. the label stack of these ping packets doesn't need more than 3 labels 😭 finally, the PMS sets up and sends packets to monitor connectivity of the ECMP-routed paths. it does this by creating a measurement packet with this label stack (top to bottom): 20 - 30 - 10. the ping packets reliably use the monitored path if the IP address info detected by the MPLS traceroute is used as the IP destination address (note that this IP address isn't used or needed for any IP routing) 🦋

LER m forwards the packet it gets from the PMS to LSR1. assuming Penultimate Hop Popping is deployed, LSR1 pops the top label and forwards the packet to LER i. there, the top label has the value 30, and LER i forwards it to LER j. this happens by sending the packet via LSR1 or LSR2. the LSR pops the top label again. LER j then forwards the packet, now carrying top label 10, to the PMS (and it passes an LSR and LER m along the way) 🌸

a few observations on the example in Figure 1 👀

  • the path from the PMS to LER i must be available (in other words, a continuity check along the path to LER i must succeed). if you want, an MPLS traceroute can be used to exactly detect the data-plane path taken for this MPLS segment. it's usually enough to just apply any of the existing Shortest Path routed paths 💅
  • if ECMP is deployed, separate continuity checks that monitor all possible paths a packet may use between LER i and LER j may be desired. this can be done by applying an MPLS traceroute between LER i and LER j. another option is to use SR, but that will likely require additional label info within the label stack of the ping packet. also, if multiple links are deployed between two nodes, SR methods to address each individual path require an Adj-SID to be assigned to each single interface. this method is based on control-plane information. a connectivity verification based on MPLS traceroute seems to be a pretty good option for handling ECMP and validating the correlation between control and data planes 🔥
  • the path from LER j to the PMS must be available (in other words, a continuity check only along the path from LER j to the PMS must succeed). if you want, an MPLS traceroute can be used to exactly detect the data-plane path taken for this MPLS segment. it's usually enough to just apply any of the existing Shortest Path routed paths 🫶

once the MPLS paths (Node-SIDs) and the info needed to handle ECMP have been detected, the PMS can monitor path continuity between LER i and LER j. monitoring continuity with ping packets doesn't require the MPLS OAM functionality described in RFC 8029 [RFC8029]. all monitoring packets stay on the data plane, so path continuity monitoring doesn't need control-plane interaction in any LER or LSR of the domain ✨ to keep the results consistent, the PMS should be aware of any changes in IGP or MPLS topology or ECMP routing. this document describes path connectivity checking as a basic application, but extra monitoring (like checking continuity of the underlying physical infrastructure or doing delay measurements) may be desired. a change in ECMP routing that isn't caused by an IGP or MPLS topology change may not be desirable for connectivity checks and delay measurements. so a PMS should also periodically verify connectivity of the SR paths that it monitors for continuity 🌈

you can also decide which path to run before a measurement by setting up a label stack that includes all the Node-SIDs along that path. (if LSR1 has Node-SID 40 in the example and it should be passed between LER i and LER j, the label stack is 20 - 40 - 30 - 10.) the upside is that this doesn't involve connectivity verification as specified in RFC 8029 [RFC8029], and if there's only one physical connection between all the nodes, the approach doesn't depend on ECMP functionality. the method can still monitor all link combinations of all paths in an MPLS domain. but if you need to check that forwarding along the desired paths is correct, or if multiple physical connections exist between any two nodes, all the Adj-SIDs along that path should be part of the label stack 💖

a single PMS can detect the complete MPLS control- and data-plane topology, but a reliable deployment requires two separate PMSs 🧚 scalable permanent surveillance of a set of LSPs could require several PMSs. the PMS may be a router, but it could also be a dedicated monitoring system. if measurement system reliability is an issue, more than one PMS may be connected to the MPLS domain 🛡️

monitoring an MPLS domain with a PMS based on SR gives you the option to monitor complete MPLS domains with limited effort, plus a unique way to scale a flexible monitoring solution however the operator needs (the number of PMSs deployed doesn't depend on where the origin and destination of the monitored paths are) 🍓 the PMS can be enabled to send MPLS OAM packets, with label stacks and address info identical to those of the monitoring packets, to any node in the MPLS domain. the routers of the monitored domain should support MPLS LSP ping [RFC8029] (that's RFC 8029 [RFC8029] in the original). they may also include the extra enhancements defined in RFC 8287 [RFC8287] to add more MPLS traceroute features 💜 ICMP-ping-based continuity checks don't require any router control-plane activity. before monitoring a path, MPLS OAM may be used to detect ECMP-dependent forwarding of a packet. a PMS may be designed to learn the IP address info needed to run a particular ECMP-routed path, along with the interfaces on that path. this makes it possible to monitor these paths with label stacks reduced to a limited number of Node-SIDs from Shortest Path First (SPF) routing. the PMS doesn't need access to any LSR or LER management or data-plane info to do this 🦋✨

4.2. Use Case 2: Monitoring a Remote Bundle 🎀

okay bestie, this one is giving "check every single lane of the highway" 🛣️✨ here's the setup:

               +---+    _   +--+                    +-------+
               |   |   { }  |  |---991---L1---662---|       |
               |PMS|--{   }-|R1|---992---L2---663---|R2 (72)|
               |   |   {_}  |  |---993---L3---664---|       |
               +---+        +--+                    +-------+

      Figure 2: SR-Based Probing of All the Links of a Remote Bundle

so in the figure, R1 names Link "x" (Lx) with the Adj-SID 99x, and R2 names that same Lx with the Adj-SID 66(x+1) 💅

the PMS needs to check the data-plane availability of all the links in a remote bundle that connects R1 and R2. no cap, every link counts 🫶

the monitoring system grabs the SID/label info from the IGP LSDB and slaps this segment list/label stack onto its IP probe, {72, 662, 992, 664}. the probe's source and destination addresses are both the PMS's address 🧚

the PMS sends the probe to the router it's connected to. the MPLS/SR domain then forwards it to R2 (72 is R2's Node-SID, so that's the first stop 🌸). R2 sends it to R1 over link L1 using Adj-SID 662. R1 sends it to R2 over link L2 using Adj-SID 992. R2 sends it to R1 over link L3 using Adj-SID 664. then R1 hands the IP probe back to the PMS with regular classic IP forwarding, and the whole loop is complete ✨

remember Section 4.1? the PMS has to keep an eye on two things here: the path from the PMS to R2 (Node-SID 72), and the path from R1 back to the PMS. if both checks are given and packets go missing, then forwarding on one of the three interfaces connecting R1 to R2 must be disturbed. one of those three lanes is the culprit 🚨

4.3. Use Case 3: Fault Localization 🔍

in the previous example, a unidirectional fault on the middle link in the direction from R2 to R1 could be pinned down by sending these two probes, each with its own segment list:

  • 72, 662, 992, 664
  • 72, 663, 992, 664

the first probe succeeds and the second one fails. when you compare the results, the only difference is the Adj-SID 663 that the failing measurement uses for the middle link from R2 to R1 🕵️‍♀️ assuming the second probe was routed correctly, the problem is that, for some (possibly unknown) reason, SR packets being forwarded from R2 out of the interface identified by Adj-SID 663 are getting lost. 💀

the example above only shows one way to localize a fault with correlated continuity checks. any real deployment needs well-designed engineering so you can get an unambiguous diagnosis of the monitored section of the SR network 🎯 "section" here could mean a path, a single physical interface, the set of all links in a bundle, or an adjacency of two nodes (just to name a few).

5. Path Trace and Failure Notification 🚨

sometimes forwarding along a single path doesn't work even though the control-plane information looks healthy 🙃 this can happen after maintenance work inside a domain. an operator can run on-demand tests, but automated PMS path trace checks can be set up too (the scope might be limited to a subset of the important end-to-end paths that cross the router or network section once the maintenance work there is done). when a path that can't be used is detected, the operator needs to be notified 📣 a check that tells a re-routing event apart from a path whose forwarding behavior doesn't match the control-plane information is necessary, but that check is out of scope of this document.

adding an automated problem solution to the PMS only makes sense if the root cause of the symptom shows up often, its symptoms make it unambiguous, it can be fixed by a predetermined chain of commands, and the automated PMS reaction doesn't cause collateral damage 🙈 a closer analysis is out of scope of this document.

the PMS is expected to check control-plane liveliness after a path repair effort has been executed. it doesn't matter whether the repair was triggered manually or by an automated system 🫶

6. Applying SR to Monitoring LSPs That Are Not SR Based (LDP and Possibly RSVP-TE) 🌈

the MPLS PMS described in this document can be built with technology that isn't SR based. but a monitoring system that isn't SR MPLS based needs to know the domain's complete MPLS topology, and getting there takes, for example, management-plane access to the routers of the domain being monitored, or setting up a dedicated tLDP tunnel per router to bring up an LDP adjacency 😮‍💨 to avoid using stale MPLS label information, the IGP must be monitored and the MPLS topology must be kept aligned with the IGP topology in a timely manner. enhancing IGPs to exchange MPLS-topology information, the way SR does, makes such an MPLS PMS way simpler and more stable 💖

an SR-based PMS connected to an MPLS domain made of LERs and LSRs that run SR and LDP or RSVP-TE in parallel on all nodes can use SR paths to send packets to and from the start and end points of the non-SR LSPs being monitored ✨ in the example from Figure 1, the label stack, top to bottom, may look like this when sent by the PMS:

  • Top: SR-based Node-SID of LER i at LER m.
  • Next: LDP or RSVP-TE label identifying the path or tunnel, respectively, from LER i to LER j (at LER i).
  • Bottom: SR-based Node-SID identifying the path to the PMS at LER j.

even with this mixed operation, the PMS still has to be aware of the LER LDP-MPLS topology, but it can learn the SR MPLS topology through the IGP and use that info too 🧠

there's an implementation report on a PMS operating in an LDP domain in [MPLS-PMS-REPORT]. it also compares delays measured with a single PMS against results from systems that are conformant with IP Performance Metrics (IPPM) and connected to the MPLS domain at three sites (see [RFC6808] for IPPM conformance) 📊 the delay measurements of the PMS and the IPPM Measurement Agents were compared with a statistical test in [RFC6576]. the Anderson Darling k-sample test showed that the PMS round-trip delay measurements are equal to those captured by an IPPM-conformant IP measurement system for 64 Byte measurement packets with 95% confidence. 👑

the authors aren't aware of any similar deployment for RSVP-TE. identifying tunnel entry and transit nodes may add complexity 🥺 those are not within the scope of this document.

7. PMS Monitoring of Different Segment ID Types 🦋

MPLS SR topology awareness should let the PMS monitor the liveliness of SIDs related to interfaces within the SR and IGP domain, respectively 👀 tracing a path where an SR-capable node assigns an Adj-SID for a node that is not SR capable may fail. this and other backward compatibility with non-SR devices is discussed in RFC 8287 [RFC8287].

to match control-plane info with data-plane info for all the relevant types of Segment IDs, RFC 8287 [RFC8287] enhances the MPLS OAM functions defined by RFC 8029 [RFC8029] 🔥

8. Connectivity Verification Using PMS 💅

the PMS-based use cases explained in Section 5 are enough to provide continuity checks between LER i and LER j, but they may not help with connectivity verification 🙃

                       +---+
                       |PMS|
                       +---+
                         |
                         |
                      +----+     +----+     +-----+
                      |LSRa|-----|LSR1|-----|LER i|
                      +----+     +----+     +-----+
                         |      /      \    /
                         |     /        \__/
                       +-----+/           /|
                       |LER m|           / |
                       +-----+\         /  \
                               \       /    \
                                \+----+     +-----+
                                 |LSR2|     |LER j|
                                 +----+     +-----+

              Figure 3: Connectivity Verification with a PMS

let's assign these Node-SIDs to the nodes in the figure: PMS = 10, LER i = 20, LER j = 30, LER m = 40. the PMS is meant to validate the path between LER m and LER j. to do that, the PMS will send the probe packet with a label stack of (top to bottom): {40} {30} {10}. now imagine one of these forwarding entries is misprogrammed 😱

  • LSRa receiving any packet with top label 40 will POP and forward it to LSR1 instead of LER m.
  • LSR1 receiving any packet with top label 30 will pop and forward it to LER i instead of LER j.

in either of those situations, the probe packet comes right back to the PMS, which leads to a falsified path liveliness indication from the PMS's point of view 🫠

connectivity verification functions help us check whether the probe is actually taking the expected path ✨ for example, the PMS can intermittently send the probe packet with a label stack of (top to bottom): {40;ttl=255} {30;ttl=1} {10;ttl=255}. the probe packet may carry information about LER m, which could be carried in the Target FEC Stack in case of an MPLS Echo Request, or in the Discriminator in the case of Seamless BFD. when LER m receives the packet, it will punt due to Time-To-Live (TTL) expiry and send a positive response. in the misprogramming situation above, LSRa will forward to LSR1, which will send a negative response to the PMS, because the information in the probe does not match the local node 🙅‍♀️ the PMS can do the same for the bottom label as well. this helps perform connectivity verification and confirm that the path between LER m and LER j is working as expected 💜

9. IANA Considerations 🌸

This document has no IANA actions.

10. Security Considerations 🔒💅

okay bestie, this section is SERIOUS but also kind of iconic, so let's get into it 🫶

The PMS builds packets to do OAM tasks 🛠️ and it grabs its address info from topology information instead of from a protocol. Main character energy, but also a big responsibility!

The PMS lets traffic get inserted into non-SR domains 🚪. This might be needed when there's an LDP domain hanging off the SR domain, BUT it can be abused to sneak traffic into external IP domains and MPLS-based VPNs 😭 yikes.

So to stop a PMS from inserting traffic into an MPLS VPN domain, you can reserve one or more sets of label ranges for service labels inside an SR domain 🎀. The PMS SHOULD be configured to reject these service label values. Same vibe for IP destination addresses: misuse gets blocked if the only IP destination addresses the PMS can set are ones that conform to [RFC8029] 🌸.

Access to a PMS needs to be authorized 🔐 and it SHOULD be logged. OAM with a PMS takes skilled people 🧠, so only the experts who actually need PMS access should get it. It's recommended to attach a PMS directly to an SR domain 💖. Hooking it up through a tunnel is technically possible but adds extra security issues 🙈, so a tunnel-based access of a PMS to an SR domain is NOT RECOMMENDED. Not me saying no cap 🚫

Now the stale routing stuff, which is a whole thing ngl 😱. Stale MPLS or IGP routing info could make a PMS-monitoring packet leave the domain it started in 🏃‍♀️💨. PMS-monitoring packets SHOULD NOT be sent using stale MPLS- or IGP-routing information. To measure properly, the PMS MUST be aware of and respect actual route changes, convergence events, and the assignment of Segment IDs that matter for measurements 👑. At a minimum, the PMS MUST be able to listen to IGP topology changes or pull routing and segment info from routers that signal topology changes 📡.

Traffic insertion by a PMS might be unintended, especially if its locally stored IGP or MPLS topology is stale 😬. As soon as the PMS has an indication that its IGP or MPLS topology is stale, it SHOULD stop operations involving network sections whose topology might not be accurate 🛑. Note that it's the job of an OAM system to find and locate network sections where forwarding behavior doesn't match control-plane state 🔍. As soon as a PMS (or its operator) has the impression that its topology info is stale, measures need to be taken to refresh it ♻️. These measures SHOULD be part of the PMS design. Matching forwarding and control-plane state by periodically and automatically running the mechanisms in [RFC8029] may be one such feature 🤖. Whenever operators do network maintenance, PMS topology discovery SHOULD be started asynchronously once the maintenance is finished 🧹.

A PMS that loses network connectivity or crashes MUST remove all IGP- and MPLS-topology information before restarting operation 💥. Like, clean slate or nothing!

A PMS may run routine measurements at large scale 📈. Care MUST be taken to avoid unintended traffic insertion after topology changes, for example changes of label assignments to routes or interfaces within a domain 🏷️. If the labels concerned are part of the label stack the PMS composes for any measurement packet and their state is stale, the measurement initially needs to be stopped 🛑. Setting up and running routine measurements MAY be automated 🤖. Secure automated PMS operation REQUIRES a working automated detection and recognition of stale routing state 💜.

11. References 📚

11.1. Normative References 💅

11.2. Informative References 🦋

Acknowledgements 🫶

The authors would like to thank Nobo Akiya for his contribution 💖. Raik Leipnitz kindly provided an editorial review ✨. The authors would also like to thank Faisal Iqbal for an insightful review and a useful set of comments and suggestions 🌈. Finally, Bruno Decraene's Document Shepherd review led to a clarified document 🙌.

Authors' Addresses 🖋️

Ruediger Geib (editor) Deutsche Telekom Heinrich Hertz Str. 3-7 Darmstadt 64295 Germany

Phone: +49 6151 5812747 Email: Ruediger.Geib@telekom.de

Clarence Filsfils Cisco Systems, Inc. Brussels Belgium

Email: cfilsfil@cisco.com

Carlos Pignataro (editor) Cisco Systems, Inc. 7200 Kit Creek Road Research Triangle Park, NC 27709-4987 United States of America

Email: cpignata@cisco.com

Nagendra Kumar Cisco Systems, Inc. 7200 Kit Creek Road Research Triangle Park, NC 27709-4987 United States of America

Email: naikumar@cisco.com

📦 where this page comes from