RFC 7358

Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)

📅 published October 2014, from ietf

RFC 7358 🦋

Okay bestie, let's get into RFC 7358, which is called Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs) 💅 It was written by K. Raza, S. Boutros, L. Martini (all at Cisco Systems, Inc.) and N. Leymann (Deutsche Telekom). It's a Standards Track doc from October 2014 with ISSN 2070-1721, and it updates RFCs 3212, 4447, 5036, 5918, 6388 and 7140. Main character energy, literally 🎀

Abstract ✨

So the label advertising behavior of an LDP speaker for a given Forwarding Equivalence Class (FEC) is decided by the FEC type, not necessarily by the session's negotiated label advertisement mode 👑 This doc updates RFC 5036 to make that crystal clear. It also updates RFCs 3212, 4447, 5918, 6388, and 7140 by spelling out the label advertisement mode for every LDP FEC type that's currently defined 🫶

Status of This Memo 📝

This is an Internet Standards Track document 🌈

This doc is a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 🍓

Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7358 💖

Copyright (c) 2014 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 were in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include 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 ....................................................2
2. Label Advertisement Discipline ..................................3
   2.1. Update to RFC 5036 .........................................3
   2.2. Specification for LDP FECs .................................4
3. Security Considerations .........................................4
4. IANA Considerations .............................................4
5. References ......................................................6
   5.1. Normative References .......................................6
   5.2. Informative References .....................................7
Acknowledgments ....................................................8
Authors' Addresses .................................................8

1. Introduction ✨

Okay so the Label Distribution Protocol (LDP) [RFC5036] lets two peers negotiate a label advertisement mode when they set up a session 💖 The LDP spec also says that only one label advertisement mode can be negotiated, agreed on, and used for a given LDP session between two Label Switching Routers (LSRs) 🦋

Here's the twist. The negotiated mode defined in RFC 5036 and carried in the LDP Initialization message is only indicative 🙈 It tells you how the LDP speakers on a session will advertise labels for some Forwarding Equivalence Classes (FECs), but it's not a rule that forces the speakers to act in one specific way. Also, for some FEC types the advertising behavior is controlled by the FEC type and not by the negotiated behavior, which is so iconic 👑

This document updates [RFC5036] to make that fact clear. It also updates [RFC3212], [RFC4447], [RFC5918], [RFC6388], and [RFC7140] so that, for each FEC type that's already been defined, it says whether the label binding advertisements for that FEC are constrained by the negotiated label advertisement mode or not. And finally, this document specifies the label advertisement mode to be used for all currently defined FECs 🌈

2. Label Advertisement Discipline 💅

To clear up any ambiguity and conflict about label advertisement discipline among different FEC types that share a common LDP session, this document specifies a label advertisement discipline for FEC types 🎀

This document introduces the following types for specifying a label advertisement discipline for a FEC type:

  • DU (Downstream Unsolicited)
  • DoD (Downstream on Demand)
  • As negotiated (DU or DoD)
  • Upstream ([RFC6389])
  • Not applicable
  • Unknown

2.1. Update to RFC 5036 🫶

Section 3.5.3 of [RFC5036] is getting updated with two new statements under the description of "A, Label Advertisement Discipline" 🍓

  • Each document defining an LDP FEC must state the applicability of the negotiated label advertisement discipline for label binding advertisements for that FEC. If the negotiated label advertisement discipline does not apply to the FEC, the document must also explicitly state the discipline to be used for the FEC.
  • This document defines the label advertisement discipline for the following FEC types:
+----------+----------+--------------------------------+
| FEC Type | FEC Name | Label Advertisement Discipline |
+----------+----------+--------------------------------+
| 0x01     | Wildcard | Not applicable                 |
| 0x02     | Prefix   | As negotiated (DU or DoD)      |
+----------+----------+--------------------------------+

2.2. Specification for LDP FECs 🧚

The label advertisement discipline for currently defined LDP FEC types is listed in Section 4 ✨

This document updates the respective RFCs where these FECs get introduced and defined 💖

3. Security Considerations 😭

Okay, this one's short, but it's SERIOUS 🔥 This document only clarifies the applicability of an LDP session's label advertisement mode, so it doesn't add any LDP security mechanics and considerations on top of the ones already defined in the LDP specification [RFC5036]. Keep that in mind, bestie 💜

4. IANA Considerations 🌈

This document mandates the specification of a label advertisement discipline for each defined FEC type. So IANA's "Forwarding Equivalence Class (FEC) Type Name Space" registry, under IANA's "Label Distribution Protocol (LDP) Parameters" registry, has been extended as follows 🍓

  • Added a new column titled "Label Advertisement Discipline" with these possible values:
    • DU
    • DoD
    • As negotiated (DU or DoD)
    • Upstream
    • Not applicable
    • Unknown
  • Made this document an additional reference for the registry itself and for all affected registrations.
  • Kept the other columns of the registry in place and populated as they were.

For the currently assigned FEC types, the updated registry looks like this 🦋

+=====+====+===============+==============+===========+============+
|Value|Hex | Name          |Label         | Reference |Notes/      |
|     |    |               |Advertisement |           |Registration|
|     |    |               |Discipline    |           |Date        |
+=====+====+===============+==============+===========+============+
| 0   |0x00|Reserved       |              |           |            |
+-----+----+---------------+--------------+-----------+------------+
| 1   |0x01|Wildcard       |Not applicable| [RFC5036] |            |
|     |    |               |              | [RFC7358] |            |
+-----+----+---------------+--------------+-----------+------------+
| 2   |0x02|Prefix         |As negotiated | [RFC5036] |            |
|     |    |               |(DU or DoD)   | [RFC7358] |            |
+-----+----+---------------+--------------+-----------+------------+
| 4   |0x04|CR-LSP         |DoD           | [RFC3212] |            |
|     |    |               |              | [RFC7358] |            |
+-----+----+---------------+--------------+-----------+------------+
| 5   |0x05|Typed Wildcard |Not applicable| [RFC5918] |            |
|     |    |FEC Element    |              | [RFC7358] |            |
+-----+----+---------------+--------------+-----------+------------+
| 6   |0x06|P2MP           |DU            | [RFC6388] |            |
|     |    |               |              | [RFC7358] |            |
+-----+----+---------------+--------------+-----------+------------+
| 7   |0x07|MP2MP-up       |DU            | [RFC6388] |            |
|     |    |               |              | [RFC7358] |            |
+-----+----+---------------+--------------+-----------+------------+
| 8   |0x08|MP2MP-down     |DU            | [RFC6388] |            |
|     |    |               |              | [RFC7358] |            |
+-----+----+---------------+--------------+-----------+------------+
| 9   |0x09|HSMP-upstream  |DU            | [RFC7140] | 2014-01-09 |
|     |    |               |              | [RFC7358] |            |
+-----+----+---------------+--------------+-----------+------------+
| 10  |0x0A|HSMP-downstream|DU, Upstream  | [RFC7140] | 2014-01-09 |
|     |    |               |              | [RFC7358] |            |
+-----+----+---------------+--------------+-----------+------------+
| 128 |0x80|PWid           |DU            | [RFC4447] |            |
|     |    |FEC Element    |              | [RFC7358] |            |
+-----+----+---------------+--------------+-----------+------------+
| 129 |0x81|Generalized    |DU            | [RFC4447] |            |
|     |    |PWid           |              | [RFC7358] |            |
|     |    |FEC Element    |              |           |            |
+-----+----+---------------+--------------+-----------+------------+
| 130 |0x82|P2MP PW        |Upstream      | [P2MP-PW] | 2009-06-03 |
|     |    |Upstream       |              | [RFC7358] |            |
|     |    |FEC Element    |              |           |            |
+-----+----+---------------+--------------+-----------+------------+
+-----+----+---------------+--------------+-----------+------------+
| 131 |0x83|Protection     |DU            |[FAST-PROT]| 2010-02-26 |
|     |    |FEC Element    |              | [RFC7358] |            |
+-----+----+---------------+--------------+-----------+------------+
| 132 |0x84|P2MP PW        |DU            | [P2MP-PW] | 2014-04-04 |
|     |    |Downstream     |              | [RFC7358] |            |
|     |    |FEC Element    |              |           |            |
+-----+----+---------------+--------------+-----------+------------+

5. References 📚

Part 2 is coming with the rest of the references, so stay tuned, bestie 🫶

5.1. Normative References

okay so these are the must-reads, bestie 📚✨ if you're implementing this stuff you NEED these, no skipping 💅

5.2. Informative References

these ones are more like bonus reading, the vibes are good but they're not strictly required 🧚

  • [FAST-PROT]: Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang, "PW Endpoint Fast Failure Protection", Work in Progress, draft-ietf-pwe3-endpoint-fast-protection-01, July 2014. 🌈
  • [P2MP-PW]: Sivabalan, S., Ed., Boutros, S., Ed., Martini, L., Konstantynowicz, M., Del Vecchio, G., Nadeau, T., Jounay, F., Niger, P., Kamite, Y., Jin, L., Vigoureux, M., Ciavaglia, L., Delord, S., and K. Raza, "Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP", Work in Progress, draft-ietf-pwe3-p2mp-pw-04, March 2012. 🫧

Acknowledgments 🫶

huge thanks to Eric Rosen and Rajiv Asati for reviewing this doc early on and giving input. you two are the real MVPs 💖

Authors' Addresses 🎀

meet the squad who wrote this thing 🧑‍💻💅

Kamran Raza
Cisco Systems, Inc.
2000 Innovation Drive
Ottawa, ON K2K-3E8
Canada

EMail: skraza@cisco.com
Sami Boutros
Cisco Systems, Inc.
3750 Cisco Way
San Jose, CA  95134
United States

EMail: sboutros@cisco.com
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO  80112
United States

EMail: lmartini@cisco.com
Nicolai Leymann
Deutsche Telekom AG
Winterfeldtstrasse 21
Berlin 10781
Germany

EMail: N.Leymann@telekom.de
📦 where this page comes from