RFC 8234

Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode

📅 published August 2017, from ietf

RFC 8234: Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode 🎀

Okay bestie, so this is RFC 8234 💖. It's a Standards Track document from the IETF, dated August 2017, with ISSN 2070-1721. The authors are J. Ryoo and T. Cheung from ETRI, H. van Helvoort from Hai Gaoming BV, and I. Busi and G. Wen from Huawei Technologies. It updates RFC 7271 (that's the Updates: 7271 bit), and it doesn't list anything it obsoletes. ✨

Abstract 🦋

Okay so this doc is an update to MPLS-TP linear protection in APS mode, which is the thing RFC 7271 defined. The vibe is: it adds rules for how the PSC Control Logic (aka the state machine, where all the drama happens) gets initialized when you're in APS mode. It also clears up how the state transition table lookup works. Lowkey essential reading if you're building this stuff 💅

Status of This Memo 🌸

This is an Internet Standards Track document, no cap.

It's a product of the Internet Engineering Task Force (IETF), which means it reflects consensus from the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want the deets on Internet Standards, check out Section 2 of RFC 7841.

If you want the current status, any errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc8234. 💖

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please actually read these, because they spell out your rights and restrictions for this doc. Code Components pulled out of this document 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.  Conventions Used in This Document . . . . . . . . . . . . . .   4
3.  Abbreviations . . . . . . . . . . . . . . . . . . . . . . . .   4
4.  Updates . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
  4.1.  Initialization Behavior . . . . . . . . . . . . . . . . .   5
  4.2.  State Transition Modification . . . . . . . . . . . . . .   6
  4.3.  Operation Related to State Transition Table Lookup  . . .   6
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
  7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction ✨

Okay so MPLS-TP linear protection in APS mode is defined in RFC 7271 [RFC7271]. It gives you a set of alternate and extra mechanisms for some of the jobs that linear protection does, which are described in RFC 6378 [RFC6378]. Here's the tea: neither [RFC7271] nor [RFC6378] actually describes what happens when the PSC Control Logic initializes. People assume the state machine starts at the Normal state, but nobody ever wrote that down explicitly. So implementers and the MPLS working group mailing list kept asking what exactly the PSC Control Logic should do 🙈

The state machine in [RFC7271] assumes that both end nodes of a linear protection domain start in the Normal state. But if one node reboots while the other is still running, things can go sideways in a bunch of ways. This document fixes all of those problematic cases and cuts down on traffic disruption during initialization, for both cold and warm reboots that need the PSC Control Logic to be re-initialized. Iconic behavior 👑

This document updates the MPLS-TP linear protection in APS mode defined in [RFC7271]. It adds rules for initializing the PSC Control Logic (the state machine lives in there) when you're running APS mode. It also tweaks the state transition table defined in Section 11.2 of [RFC7271]. The table changes were checked to make sure they don't introduce any new problems, which is very responsible of them 💜

This document doesn't cause backward compatibility issues with implementations of [RFC7271]. If a node running this document restarts, the new state changes won't cause trouble at a remote node still running [RFC7271], and both ends will end up converging to the same local and remote states. If a node running [RFC7271] restarts, the two ends act exactly like they do today 🦋

This document also clarifies how state transition table lookup works.

Just a heads up: the reader is assumed to already know [RFC7271].

2. Conventions Used in This Document 🌷

The BCP 14 key words are the ones that carry the RFC-style meaning, so here's the official line on them: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Capitals = serious business, lowercase = just vibes 💅

3. Abbreviations 🧚

Here are the abbreviations this document uses:

APS     Automatic Protection Switching
DNR     Do-not-Revert
E::R    Exercise state due to remote EXER message
EXER    Exercise
MS-P    Manual Switch to Protection path
MS-W    Manual Switch to Working path
MPLS-TP MPLS Transport Profile
NR      No Request
PF:DW:R Protecting Failure state due to remote SD-W message
PF:W:L  Protecting Failure state due to local SF-W
PF:W:R  Protecting Failure state due to remote SF-W message
PSC     Protection State Coordination
RR      Reverse Request
SA:MP:R Switching Administrative state due to remote MS-P message
SA:MW:R Switching Administrative state due to remote MS-W message
SD      Signal Degrade
SD-W    Signal Degrade on Working path
SF      Signal Fail
SF-P    Signal Fail on Protection path
SF-W    Signal Fail on Working path
UA:P:L  Unavailable state due to local SF-P
WTR     Wait-to-Restore

4. Updates 💖

This section lays out what happens when the PSC Control Logic initializes, plus the changes to the state transition table defined in Section 11.2 of [RFC7271]. It also adds some clarifications on state transition table lookup. Let's gooo 🚀

4.1. Initialization Behavior 🌸

Okay so this section defines initialization behavior that [RFC7271] doesn't cover.

When the PSC Control Logic gets initialized, the following actions MUST be performed:

  • Stop the WTR timer if it's running.
  • Clear any operator command in the Local Request Logic.
  • If an SF-W or SF-P is the highest local request, the node being initialized starts at the PF:W:L or UA:P:L state, respectively.
  • If the node being initialized has no local request:
    • If the node doesn't remember the active path, or it remembers the working path as the active path, it starts at the Normal state.
    • Else (it remembers the protection path as the active path), it starts at the WTR state sending NR(0,1), or at the DNR state sending DNR(0,1), depending on whether the configuration allows or prevents automatic reversion to the Normal state.
  • In case any local SD exists, the local SD MUST be considered as an input to the Local Request Logic only after the local node has received the first protocol message from the remote node and finished processing it (i.e., it updated the PSC Control Logic and decided which action, if any, goes to the PSC Message Generator). 🫶
  • If the local node receives an EXER message as the first protocol message after initialization, and the remote EXER becomes the top-priority global request, the local node MUST set the position of the bridge and selector according to the Path value in the EXER message, and transit to the E::R state. ✨

In the case of no local request, remembering the active path cuts down on traffic switchovers when the remote node is still running. This approach is still fine even if the remembered active path is no longer valid, because of some local input that happened at the remote node while the initializing node was out of operation. Big brain move 🧠

Note that in some restart scenarios (e.g., cold rebooting), there may be no valid SF/SD indications at the input of the Local Request Logic. In that case, the PSC Control Logic restarts as if there are no local requests. If a valid SF/SD indication shows up later, the PSC Control Logic gets notified and a state change is triggered 🦋

okay so, on top of the state transition table lookup rules in Section 11 of [RFC7271], this operation gets one extra rule 🎀

  • When the local SF-P is cleared and the priorities of the local and remote requests get re-evaluated, the last received remote message might not be valid anymore, because the protection path failed earlier. So the last received message MUST be treated as if it were NR, and only the local request shall be evaluated. 🙈

The last paragraph in Section 11 of [RFC7271] is also getting an update ✨ Here's the before and after, verbatim so nothing gets lost in translation:

---------
Old text:
---------
In the state transition tables below, the letter 'i' stands for
"ignore" and is an indication to remain in the current state and
continue transmitting the current PSC message.

---------
New text:
---------
In the state transition tables below, the letter 'i' is the
"ignore" flag; if it is set, it means that the top-priority
global request is ignored.

If re-evaluation is triggered, the ignore flag is checked.  If it
is set, the state machine will transit to the supposed state, which
can be Normal or DNR as indicated in the footnotes to the state
transition table in Section 11.1 of [RFC7271].  If the ignore flag
is not set, the state machine will transit to the state indicated
in the cell of the state transition table.

If re-evaluation is not triggered, the ignore flag is checked.  If
it is set, the state machine will remain in the current state, and
the current PSC message continues to be transmitted.  If the ignore
flag is not set, the state machine will transit to the state
indicated in the cell of the state transition table.

So the big glow-up here is that the 'i' is now the ignore flag, not just a vibe. 🦋 When re-evaluation is triggered and the flag is set, the machine transits to the supposed state (Normal or DNR, per the footnotes in Section 11.1 of [RFC7271]). When the flag isn't set, it goes to whatever the table cell says. When re-evaluation is not triggered and the flag is set, the machine stays put and keeps sending the current PSC message. Flag not set? Table cell, no notes 💖

5. Security Considerations 🔥

Okay, bestie, this part is serious, so listen up 👑 No new security issue is raised beyond the ones already covered in [RFC7271]. BUT, and this is a big but, tightening how the initializing behavior is described can help protect networks from restart attacks 😭 Protect your restarts, babe 🛡️

6. IANA Considerations 🌸

This document does not require any IANA actions. Zero registries, zero paperwork, pure vibes ✨

7. References 📚

7.1. Normative References

7.2. Informative References

Acknowledgements 🫶

The authors want to give a shoutout to Joaquim Serra, who raised the issue about initializing the PSC Control Logic right at the very beginning 🙌 They also thank Adrian Farrel and Loa Andersson for their super valuable comments and suggestions on this document 💜

Authors' Addresses 🦋

Jeong-dong Ryoo ETRI

Email: ryoo@etri.re.kr

Taesik Cheung ETRI

Email: cts@etri.re.kr

Huub van Helvoort Hai Gaoming BV

Email: huubatwork@gmail.com

Italo Busi Huawei Technologies

Email: Italo.Busi@huawei.com

Guangjuan Wen Huawei Technologies

Email: wenguangjuan@huawei.com 🌈

📦 where this page comes from