RFC 3612

Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP)

📅 published September 2003, from ietf

RFC 3612: Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) 🎀

Okay bestie, this is RFC 3612 🦋 and it's written by A. Farrel from Old Dog Consulting ✨. It came out of the Network Working Group 💜. It's marked Informational, which means it's giving "here's some guidance" and not a binding standard 💅. The date is September 2003 🌸. The header doesn't list anything it obsoletes or updates, so no drama there 🙈

Status of This Memo ✨

Quick legal bit, but make sure you read it 💖. This memo gives information to the Internet community ✨. It does not specify an Internet standard of any kind 🙅‍♀️. Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (2003). All Rights Reserved. 🔥

Abstract 🦋

Okay so this document is basically here to tell you when it's a good idea to add some kind of LDP restart mechanism 🎀, and which approach might be the better fit 💅. The issues and extensions it covers are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP" 🫶. Bestie, that's the whole vibe ✨

1. Introduction ✨

Multiprotocol Label Switching (MPLS) systems live in core networks where system downtime has to be kept to an absolute minimum 😭. Same deal when MPLS is at the network edges, like in Provider Edge (PE) routers [RFC2547], where downtime also has to be kept to a minimum 💀. So lots of MPLS Label Switching Routers (LSRs) may exploit Fault Tolerant (FT) hardware or software to keep the core highly available 👑

Now, how FT actually gets achieved for the parts of an FT LSR, like the switching hardware and the TCP stack, is totally implementation specific 🧚. Same goes for how a software module chooses to do FT for the state LDP creates 🌸. BUT there are several issues in the LDP specification [RFC3036] that make it really hard to build an FT LSR using LDP without some extensions to those protocols 😩. Proposals to address these issues have been made in [RFC3478] and [RFC3479] 🍓

2. Requirements of an LDP FT System 💜

Lots of MPLS LSRs may exploit FT hardware or software to provide high availability (HA) of core networks 🦋. To provide HA, an MPLS system needs to be able to survive a variety of faults with minimal disruption to the Data Plane 🔥. The fault types it has to survive include:

  • failure/hot-swap of the switching fabric in an LSR,
  • failure/hot-swap of a physical connection between LSRs,
  • failure of the TCP or LDP stack in an LSR,
  • software upgrade to the TCP or LDP stacks in an LSR.

Bestie, the first two of those can stay confined to the Data Plane 🫶. Those can be handled by adding redundancy in the Data Plane that stays transparent to LDP running in the Control Plane ✨. But a switching fabric failure or a dead physical link can have repercussions in the Control Plane too, since signaling might get disrupted 😭

The third one can be caused by a bunch of stuff, like processor or other hardware failure, and software failure 💀

Honestly, any of the last three can hit the Control Plane and will need action in the Control Plane to recover 🙈. That action should be designed to avoid disrupting traffic in the Data Plane 💅. Since lots of recent router architectures can separate the Control and Data Planes, forwarding can keep going unaffected by recovery action in the Control Plane 🌈. It's giving separation of concerns, iconic 👑

Other scenarios hit both the Data and Control Planes at once 😩. But HA still needs those two planes to be recovered together, back to a state that existed before the fault 🫶

Protection paths for MPLS LSPs, and protection of links, IP routes or tunnels using protection LSPs, are outside the scope of this document 🙅‍♀️. See [RFC3469] for more info 🦋

3. General Considerations 🎀

So, for the Data and Control Plane states to be successfully recovered after a fault, procedures are required 🔥. These procedures make sure that the state held on a pair of LDP peers (at least one of which was affected directly by the fault) is synchronized ✨. Those procedures must be implemented in the Control Plane software modules on the peers, using Control Plane protocols 💅

The required actions can operate fully after the failure, which is reactive recovery 😤. They can also contain elements that operate before the fault to minimize the actions needed after it, which is proactive recovery 🧚. Actions that operate solely in advance of the failure and need no further processing afterwards (preventive recovery) are rare 🙈. That's because signaling protocols are dynamic and fault timing is unpredictable 💀

Reactive recovery actions may include full re-signaling of state, re-synchronization of state between peers, and synchronization based on checkpointing 🌸. Proactive recovery actions may include hand-shaking state transitions and checkpointing 🍓

4. Specific Issues with the LDP Protocol 🌈

LDP uses TCP to give reliable connections between LSRs 💜. Those connections are used to exchange protocol messages, distribute labels, and set up LSPs 🫶. A pair of LSRs with such a connection are called LDP peers ✨

TCP lets LDP assume reliable transfer of protocol messages 💅. That means some messages don't need to be acknowledged, like Label Release 🙈

Here's the big rule: LDP is defined so that if the TCP connection fails, the LSR should immediately tear down the LSPs tied to the session between the LDP peers 😭. It should also release any labels and resources assigned to those LSPs 💀

Bestie, it is notoriously difficult to build a Fault Tolerant implementation of TCP 😩. Doing it might mean making copies of all the data sent and received 🔥. Implementers of other TCP applications, like BGP, know this struggle too 🦋

So during failover that affects the TCP or LDP stacks, the TCP connection may be lost 💔. Recovery is made worse because LDP control messages may have been lost during the connection failure 🙈. Those messages are unconfirmed, so LSP or label state information could be lost 😱

At the very least, the solution has to change the basic requirements of LDP so that an LDP session failure does not force the associated LDP or forwarding state to be torn down ✨. That's the minimum, no cap 👑

Any changes made to LDP for recovery processing must meet the following requirements:

  • offer backward-compatibility with LSRs that do not implement the extensions to LDP,
  • preserve existing protocol rules described in [RFC3036] for handling unexpected duplicate messages and for processing unexpected messages referring to unknown LSPs/labels.

Ideally, any solution for LDP should be equally applicable to CR-LDP 🫶

5. Summary of the Features of LDP FT 🦋

LDP Fault Tolerance extensions are described in [RFC3479] 💜. This approach involves:

  • negotiation between LDP peers of the intent to support extensions to LDP that facilitate recovery from failover without loss of LSPs,
  • selection of FT survival on a per LSP/label basis or for all labels on a session,
  • sequence numbering of LDP messages to facilitate acknowledgement and checkpointing,
  • acknowledgement of LDP messages to ensure that a full handshake is performed on those messages either frequently (such as per message) or less frequently as in checkpointing,
  • solicitation of up-to-date acknowledgement (checkpointing) of previous LDP messages to ensure the current state is secured, with an additional option that allows an LDP partner to request that state is flushed in both directions if graceful shutdown is required,
  • a timer to control how long LDP and forwarding state should be retained after the LDP session failure, but before being discarded if LDP communications are not re-established,
  • exchange of checkpointing information on LDP session recovery to establish what state has been retained by recovering LDP peers,
  • re-issuing lost messages after failover to ensure that LSP/label state is correctly recovered after reconnection of the LDP session.

The FT procedures in [RFC3479] focus on preserving label state for labels exchanged between a pair of adjacent LSRs when the TCP connection between them is lost 🎀. These procedures are not meant to support end-to-end protection for LSPs 🙅‍♀️

6. Summary of the Features of LDP Graceful Restart 🌸

LDP graceful restart extensions are defined in [RFC3478] ✨. This approach involves:

  • negotiation between LDP peers of the intent to support extensions to LDP that facilitate recovery from failover without loss of LSPs,
  • a mechanism whereby an LSR that restarts can relearn LDP state by resynchronization with its peers,
  • use of the same mechanism to allow LSRs recovering from an LDP session failure to resynchronize LDP state with their peers provided that at least one of the LSRs has retained state across the failure or has itself resynchronized state with its peers,
  • a timer to control how long LDP and forwarding state should be retained after the LDP session failure, but before being discarded if LDP communications are not re-established,
  • a timer to control the length of the resynchronization period between adjacent peers should be completed.

The procedures in [RFC3478] apply to all LSRs, both the ones that can preserve forwarding state during an LDP restart and the ones that can not 🧚. LSRs that can not preserve their MPLS forwarding state across the LDP restart would impact MPLS traffic during restart 😬. Still, by implementing a subset of the mechanisms in [RFC3478], they can minimize the impact 💅. That works best if their neighbor(s) can preserve their forwarding state across the restart of their LDP sessions or control planes by implementing the mechanism in [RFC3478] 🫶

7. Applicability Considerations 💖

This section looks at how fault tolerance schemes apply within LDP networks 🔥. It also covers issues that might lead you to choose one method over another 🦋. Bestie, many of the points raised below should be viewed as implementation issues rather than specific drawbacks of either solution 👑

7.1. General Applicability

okay so bestie, [RFC3478] and [RFC3479] are built for two different drama scenarios 🎭. In Session Failure, the LDP peers at both ends are still active, but the session breaks and gets restarted. Session failure doesn't automatically mean the data channel is dead, even when the control channel is in-band 💅. In Node Failure, the session dies because one of the peers got restarted (or at least the LDP component of the node did) 😭. These two have different vibes for how easily an LSR can hang onto LDP state, and we'll get into that in the sections below ✨.

These techniques only work in LDP networks where at least one LSR can keep LDP signaling state and the matching forwarding state alive across a session failure and recovery 🛡️. In [RFC3478], the LSRs holding onto state don't have to be adjacent to the failed LSR or session 🌍.

If traffic is not supposed to be impacted, both LSRs at the ends of an LDP session must at least keep their forwarding state 🧠. Keeping LDP state is not the same thing as keeping traffic flowing, so don't mix those up 🙈.

[RFC3479] requires that the LSRs at both ends of the session implement its procedures. So it's all or nothing: either traffic is preserved and recovery resyncs state, or no traffic is preserved and the LSP fails 💀.

Also, to use [RFC3479] to recover state on a session, both LSRs need a way to maintain some session state, plus a way to audit the forwarding state and the resynchronized control state 🔍.

[RFC3478] is scoped to preserve traffic if both LSRs implement its procedures. It also still works if only one LSR on the failed session supports retaining forwarding state and implements the mechanisms in the document 🦋. In that case traffic gets hit by the session failure, but the forwarding state gets recovered when the session comes back. And if there are simultaneous failures, [RFC3478] can relearn and redistribute state across multiple LSRs by combining its mechanisms with the usual LDP message exchanges of [RFC3036] 🧚.

7.2. Session Failure

In Session Failure, an LDP session between two peers fails and gets restarted 🔄. Neither LSR at the ends restarts, and LDP keeps running on both nodes 🙌.

In these cases it's pretty simple for implementations to keep the LDP state tied to the failed session and then link that state to the new session once it's established 🎀. Housekeeping can be used to figure out that the failed session isn't coming back, so the old LDP state can be released 🧹. Both [RFC3478] and [RFC3479] handle this case 💜.

Applicability of [RFC3478] and [RFC3479] to the Session Failure scenario should be considered with respect to the availability of the data plane 👀.

Sometimes the LDP session fails for reasons that have nothing to do with the physical (or virtual) link(s) between adjacent peers. For example, it could be a failure of the TCP/IP stack 🧊. In these cases the data plane is not impacted, and both [RFC3478] and [RFC3479] are applicable to preserve or restore LDP state 🌸.

LDP signaling may also operate out of band, meaning it might use different links from the data plane 🛤️. Then a failure of the LDP session may be a result of a failure of the control channel, but there is no implied failure of the data plane. For this scenario, [RFC3478] and [RFC3479] are both applicable to preserve or restore LDP state ✨.

In the case where the failure of the LDP session also implies the failure of the data plane, it can be an implementation decision whether LDP peers retain forwarding state, and for how long 🤔. In that situation, if forwarding state is retained and the LDP session is re-established, both [RFC3478] and [RFC3479] are applicable to preserve or restore LDP state 💖.

When the data plane has been disrupted, an objective of a recovery implementation might be to restore data traffic as quickly as possible 🏃‍♀️💨.

7.3. Controlled Session Failure

In some circumstances, the LSRs may know in advance that an LDP session is going to fail (e.g., perhaps a link is going to be taken out of service) 🛠️.

[RFC3036] includes provision for controlled shutdown of a session 📋. [RFC3478] and [RFC3479] allow resynchronization of LDP state upon re-establishment of the session 🔁.

[RFC3479] offers the facility to both checkpoint all LDP states before the shutdown, and to quiesce the session so that no new state changes are attempted between the checkpoint and the shutdown 📸. This means that on recovery, resynchronization is simple and fast 🚀.

[RFC3478] resynchronizes all state on recovery regardless of the nature of the shutdown 💅.

7.4. Node Failure

Node Failure describes events where a whole node is restarted, or where the component responsible for LDP signaling is restarted 😱. Such an event will be perceived by the LSR's peers as session failure, but the restarting node sees the restart as a full re-initialization 🔧.

The basic requirement is that forwarding state is retained, otherwise the data plane will necessarily be interrupted 🚨. If forwarding state is not retained, it may be relearned from the saved control state in [RFC3479]. [RFC3478] does not utilize or expect a saved control state 🙅. If a node restarts without preserved forwarding state, it informs its neighbors, which immediately delete all label-FEC bindings previously received from the restarted node 🗑️.

The ways to retain forwarding and control state are numerous and implementation specific 🧩. It is not the purpose of this document to espouse one mechanism or another, nor even to suggest how this might be done 🙅‍♀️. If state has been preserved across the restart, synchronization with peers can be carried out as though recovering from Session Failure, as in the previous section 🔄. Both [RFC3478] and [RFC3479] support this case 💕.

How much control state is retained is largely an implementation choice, but [RFC3479] requires that at least a small amount of per-session control state be retained 📦. [RFC3478] does not require or expect control state to be retained 🤷.

It is also possible that the restarting LSR has not preserved any state. In this case, [RFC3479] is of no help 😩. [RFC3478] however allows the restarting LSR to relearn state from each adjacent peer through the processes for resynchronizing after Session Failure 🙌. Further, in the event of simultaneous failure of multiple adjacent nodes, the nodes at the edge of the failure zone can recover state from their active neighbors and distribute it to the other recovering LSRs without any failed LSR having to have saved state 🌈.

7.5. Controlled Node Failure

In some cases (hardware repair, software upgrade, etc.), node failure may be predictable 🛠️. In these cases all sessions with peers may be shut down, and existing state retention may be enhanced by special actions ⭐.

[RFC3479] checkpointing and quiesce may be applied to all sessions so that state is up-to-date 📸.

As above, [RFC3478] does not require that state is retained by the restarting node, but can utilize it if it is 💜.

7.6. Speed of Recovery

Speed of recovery is impacted by the amount of signaling required ⏱️.

If forwarding state is preserved on both LSRs on the failed session, then the recovery time is constrained by the time to resynchronize the state between the two LSRs 🏁.

[RFC3479] may resynchronize very quickly. In a stable network, this resolves to a handshake of a checkpoint 🤝. At the most, resynchronization involves this handshake plus an exchange of messages to handle state changes since the checkpoint was taken 📨. Implementations that support only the periodic checkpointing subset of [RFC3479] are more likely to have additional state to resynchronize 🧾.

[RFC3478] must resynchronize state for all label mappings that have been retained. At the same time, resources that have been retained by a restarting upstream LSR but are not actually required, because they have been released by the downstream LSR (perhaps because it was in the process of releasing the state), they must be held for the full resynchronization time to ensure that they are not needed 😬.

The impact of recovery time will vary according to the use of the network 🌐. Both [RFC3478] and [RFC3479] allow advertisement of new labels while resynchronization is in progress ⚠️. Issues to consider are re-availability of falsely retained resources and conflict between retained label mappings and newly advertised ones 🥴. This may cause incorrect forwarding of data (since labels are advertised from downstream): an LSR upstream of a failure may continue to forward data for one FEC on an old label while the recovering downstream LSR might re-assign that label to another FEC and advertise it 😱. For this reason, restarting LSRs may choose to not advertise new labels until resynchronization with their peers has completed, or may decide to use special techniques to cover the short period of overlap between resynchronization and new LSP setup 🎯.

7.7. Scalability

Scalability is largely the same issue as speed of recovery and is governed by the number of LSPs managed through the failed session(s) 📈.

Note that there are limits to how small the resynchronization time in [RFC3478] may be made given the capabilities of the LSRs, the throughput on the link between them, and the number of labels that must be resynchronized 🧱.

Impact on normal operation should also be considered 👀.

[RFC3479] requires acknowledgement of all messages. These acknowledgements may be deferred as for checkpointing described in section 4, or may be frequent 📬. Although acknowledgements can be piggy-backed on other state messages, an option for frequent acknowledgement is to send a message solely for the purpose of acknowledging a state change message. Such an implementation would clearly be unwise in a busy network 🙃.

[RFC3478] has no impact on normal operations ✅.

7.8. Rate of Change of LDP State

Some networks do not show a high degree of change over time, such as those using targeted LDP sessions 🐢. Others change the LDP forwarding state frequently, perhaps reacting to changes in routing information on LDP discovery sessions 🌪️.

The rate of change of LDP state exchanged over an LDP session depends on the application for which the LDP session is being used 🎯. LDP sessions used for exchanging <FEC, label> bindings for establishing hop by hop LSPs will typically exchange state reacting to IGP changes. Such exchanges could be frequent 🔁. On the other hand, LDP sessions established for exchanging MPLS Layer 2 VPN FECs will typically exhibit a smaller rate of state exchange 🌷.

In [RFC3479], two options exist. The first uses a frequent (up to per-message) acknowledgement system, which is most likely to be applicable in a more dynamic system where it is desirable to preserve the maximum amount of state over a failure, to reduce the level of resynchronization required and to speed the recovery time ⚡.

The second option in [RFC3479] uses a less-frequent acknowledgement scheme known as checkpointing. This is particularly suitable to networks where changes are infrequent or bursty 💤.

[RFC3478] resynchronizes all state on recovery regardless of the rate of change of the network before the failure. This consideration is thus not relevant to the choice of [RFC3478] 💅🫶.

7.9. Label Distribution Modes ✨

okay so both [RFC3478] and [RFC3479] are good to go with Downstream Unsolicited label distribution 💖

[RFC3478] lists Downstream-On-Demand as an area for future study, so it's a no-go for any network running this mode 🙈 It's possible that future work will show that once a label has been handed out in either mode, [RFC3478] can hand it out again when a session recovers 🦋

[RFC3479] is the one for networks that use Downstream-On-Demand label distribution 🎀

According to [RFC3036], even networks set up for Downstream Unsolicited can sometimes want Downstream-On-Deman distribution, in theory 🧚 Nothing bans the Label Request message in a Downstream Unsolicited LDP network, so it's allowed 💅

People don't agree on whether a Label Request message is actually needed in a Downstream Unsolicited LDP network 🤷‍♀️ Current deployment experience suggests there isn't a requirement for it, so that's the vibe right now ✨

7.10. Implementation Complexity 💜

Complexity matters for both the implementer and the deployer, because complicated software is more error prone and harder to manage 😭

[RFC3479] is the more complex solution compared to [RFC3478] 👀 [RFC3478] doesn't need any changes to the normal signaling and processing of LDP state changing messages, which is so chill 🌸

[RFC3479] implementations can be made simpler by only implementing the checkpointing subset of the functionality 🍓

7.11. Implementation Robustness 🌈

Along with the robustness issues that come from how complex the solutions are, you also have to think about how preserving state affects robustness 🧠

If state has gone wrong for whatever reason, preserving state may keep the wrong state around 😬 In extreme cases the wrong state might be what caused the failure, and then keeping it would be a bad idea 💀

When state is preserved, exactly how much gets kept is an implementation issue 🛠️ The basic requirement is that forwarding state is kept (so the data path survives) and that the LDP software component can access that state 🔥

In both solutions, if the forwarding state is wrong and gets kept, it'll stay wrong 😤 Both solutions have a way to clean up and free the unwanted state once resynchronization is done 🧹 [RFC3478] might be better at getting rid of wrong forwarding state, because it replays all the message exchanges that originally filled the state in 👑

With [RFC3478], the recovering node only needs to have saved as much data as the forwarding state 💅 All the other LDP state can be relearned through message exchanges with peers 🫶 Whether those exchanges could cause the same wrong state to show up again on the recovering node is an obvious concern 👀

With [RFC3479], the forwarding state has to be supplemented with a small amount of state that's specific to the protocol extensions ✨ LDP state can be kept as is or rebuilt from the forwarding state 🦋 The same issues apply when rebuilding state, but they're softened by the fact that this is likely a different code path 💖 Errors in the retained state that's specific to the protocol extensions will stick around, though 😭

7.12. Interoperability and Backward Compatibility 🎀

It's really important that new LDP additions work with existing implementations, at least when it comes to keeping the existing levels of function 🫶

Both [RFC3478] and [RFC3479] handle this with rules for what to do when the FT optional negotiation object is missing during session initialization 🤝

On top of that, [RFC3478] can do limited recovery (basically redistributing state) even when only one of the participating LSRs supports the procedures 🌸 That can be a big win when you're interoperating with legacy implementations ✨

7.13. Interaction With Other Label Distribution Mechanisms 🧚

Lots of LDP LSRs also run other label distribution mechanisms 🌈 That includes management interfaces for configuring static label mappings, other separate instances of LDP, and other label distribution protocols 💅 The last one covers traffic engineering label distribution protocols, which are used to build the tunnels that LDP LSPs get set up through 🦋

Same as with reusing individual labels inside a restarting LDP system, you have to be careful that labels a restarting LDP session or protocol component needs to keep don't get picked up by some other label distribution mechanism 🙈 That could compromise data security, among other things 💀

It's up to implementations to avoid this, using things like a common label management component or segmented label spaces 🛠️

7.14. Applicability to CR-LDP 🍓

CR-LDP [RFC3212] uses Downstream-On-Demand label distribution 💜 [RFC3478] lists Downstream-On-Demand as an area for future study, so it isn't applicable for CR-LDP 🙅‍♀️ [RFC3479] is good for a network that's entirely CR-LDP, or one that's a mix of LDP and CR-LDP 👑

8. Security Considerations 🔒

This document is informational and introduces no new security concerns.

The security considerations for the original LDP protocol [RFC3036] are still relevant, so don't forget them 😤

[RFC3478] brings the possibility of extra denial-of- service attacks 😱 All of these attacks can be countered by using an authentication scheme between LDP peers, like the MD5-based scheme described in [LDP] 🛡️

In MPLS there's a data mis-delivery security issue that shows up if an LSR keeps using labels after the session that first caused them to be used has expired 🚨 Both [RFC3478] and [RFC3479] are open to this issue 💀

9. Intellectual Property Statement 📜

The IETF doesn't take a position on whether any intellectual property or other rights that might be claimed to cover the implementation or use of the technology in this document are valid or in scope, and it doesn't say whether any license under those rights would or wouldn't be available. It also doesn't claim it has tried to find any such rights. Info about the IETF's procedures for rights in standards-track and standards-related documentation is in BCP-11. Copies of claims of rights that were made available for publication, plus any assurances of licenses to be made available, or the results of any attempt to get a general license or permission to use such proprietary rights by implementors or users of this specification, can be obtained from the IETF Secretariat 📬

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard 💌 Send that info to the IETF Executive Director 🫶

10. References 📚

10.1. Normative References

  • [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
  • [RFC3478] Leelanivas, M., Rekhter, Y. and R. Aggarwal, "Graceful Restart Mechanism for LDP", RFC 3478, February 2003.
  • [RFC3479] Farrel, A., Editor, "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.

10.2. Informative References

  • [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
  • [RFC3212] Jamoussi, B., Editor, Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
  • [RFC3469] Sharma, V., Ed., and F. Hellstrand, Ed., "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.

11. Acknowledgements 🫶

The author would like to thank the authors of [RFC3478] and [RFC3479] for their work on fault tolerance of LDP 🙌 Many thanks to Yakov Rekhter, Rahul Aggarwal, Manoj Leelanivas and Andrew Malis for their considered input to this applicability statement 💜

12. Author's Address 📮

Adrian Farrel Old Dog Consulting

Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English 🌍

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees 💖

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🌈

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society 💅✨

📦 where this page comes from