Difference between revisions of "RFC7358"
imported>Admin (Created page with " Internet Engineering Task Force (IETF) K. RazaRequest for Comments: 7358 S. BoutrosUpdates: 3212, 4447, 5036...") |
|||
Line 1: | Line 1: | ||
+ | Internet Engineering Task Force (IETF) K. Raza | ||
+ | Request for Comments: 7358 S. Boutros | ||
+ | Updates: 3212, 4447, 5036, 5918, 6388, 7140 L. Martini | ||
+ | Category: Standards Track Cisco Systems, Inc. | ||
+ | ISSN: 2070-1721 N. Leymann | ||
+ | Deutsche Telekom | ||
+ | October 2014 | ||
+ | Label Advertisement Discipline | ||
+ | for LDP Forwarding Equivalence Classes (FECs) | ||
− | + | '''Abstract''' | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | Abstract | ||
The label advertising behavior of an LDP speaker for a given | The label advertising behavior of an LDP speaker for a given | ||
Line 17: | Line 19: | ||
label advertisement mode for all currently defined LDP FEC types. | label advertisement mode for all currently defined LDP FEC types. | ||
− | Status of This Memo | + | '''Status of This Memo''' |
This is an Internet Standards Track document. | This is an Internet Standards Track document. | ||
Line 31: | Line 33: | ||
http://www.rfc-editor.org/info/rfc7358. | http://www.rfc-editor.org/info/rfc7358. | ||
− | + | '''Copyright Notice''' | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | Copyright Notice | ||
Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2014 IETF Trust and the persons identified as the | ||
Line 66: | Line 50: | ||
== Introduction == | == Introduction == | ||
− | The Label Distribution Protocol (LDP) [RFC5036] allows label | + | The Label Distribution Protocol (LDP) [[RFC5036]] allows label |
advertisement mode negotiation at the time of session establishment. | advertisement mode negotiation at the time of session establishment. | ||
The LDP specification also dictates that only a single label | The LDP specification also dictates that only a single label | ||
Line 80: | Line 64: | ||
governed by the FEC type and not by the negotiated behavior. | governed by the FEC type and not by the negotiated behavior. | ||
− | This document updates [RFC5036] to make that fact clear. It also | + | This document updates [[RFC5036]] to make that fact clear. It also |
− | updates [RFC3212], [RFC4447], [RFC5918], [RFC6388], and [RFC7140] to | + | updates [[RFC3212]], [[RFC4447]], [[RFC5918]], [[RFC6388]], and [[RFC7140]] to |
indicate, for each FEC type that has already been defined, whether | indicate, for each FEC type that has already been defined, whether | ||
− | |||
− | |||
− | |||
− | |||
the label binding advertisements for the FEC are constrained by the | the label binding advertisements for the FEC are constrained by the | ||
Line 106: | Line 86: | ||
- DoD (Downstream on Demand) | - DoD (Downstream on Demand) | ||
- As negotiated (DU or DoD) | - As negotiated (DU or DoD) | ||
− | - Upstream ([RFC6389]) | + | - Upstream ([[RFC6389]]) |
- Not applicable | - Not applicable | ||
- Unknown | - Unknown | ||
− | === Update to RFC 5036 === | + | === Update to [[RFC5036|RFC 5036]] === |
− | Section 3.5.3 of [RFC5036] is updated to add the following two | + | Section 3.5.3 of [[RFC5036]] is updated to add the following two |
statements under the description of "A, Label Advertisement | statements under the description of "A, Label Advertisement | ||
Discipline": | Discipline": | ||
Line 131: | Line 111: | ||
| 0x02 | Prefix | As negotiated (DU or DoD) | | | 0x02 | Prefix | As negotiated (DU or DoD) | | ||
+----------+----------+--------------------------------+ | +----------+----------+--------------------------------+ | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
=== Specification for LDP FECs === | === Specification for LDP FECs === | ||
Line 154: | Line 125: | ||
label advertisement mode and hence does not add any LDP security | label advertisement mode and hence does not add any LDP security | ||
mechanics and considerations to those already defined in the LDP | mechanics and considerations to those already defined in the LDP | ||
− | specification [RFC5036]. | + | specification [[RFC5036]]. |
== IANA Considerations == | == IANA Considerations == | ||
Line 179: | Line 150: | ||
- Kept other columns of the registry in place and populated as they | - Kept other columns of the registry in place and populated as they | ||
were. | were. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
For the currently assigned FEC types, the updated registry looks | For the currently assigned FEC types, the updated registry looks | ||
Line 204: | Line 161: | ||
| 0 |0x00|Reserved | | | | | | 0 |0x00|Reserved | | | | | ||
+-----+----+---------------+--------------+-----------+------------+ | +-----+----+---------------+--------------+-----------+------------+ | ||
− | | 1 |0x01|Wildcard |Not applicable| [RFC5036] | | | + | | 1 |0x01|Wildcard |Not applicable| [[RFC5036]] | | |
− | | | | | | [RFC7358] | | | + | | | | | | [[RFC7358]] | | |
+-----+----+---------------+--------------+-----------+------------+ | +-----+----+---------------+--------------+-----------+------------+ | ||
− | | 2 |0x02|Prefix |As negotiated | [RFC5036] | | | + | | 2 |0x02|Prefix |As negotiated | [[RFC5036]] | | |
− | | | | |(DU or DoD) | [RFC7358] | | | + | | | | |(DU or DoD) | [[RFC7358]] | | |
+-----+----+---------------+--------------+-----------+------------+ | +-----+----+---------------+--------------+-----------+------------+ | ||
− | | 4 |0x04|CR-LSP |DoD | [RFC3212] | | | + | | 4 |0x04|CR-LSP |DoD | [[RFC3212]] | | |
− | | | | | | [RFC7358] | | | + | | | | | | [[RFC7358]] | | |
+-----+----+---------------+--------------+-----------+------------+ | +-----+----+---------------+--------------+-----------+------------+ | ||
− | | 5 |0x05|Typed Wildcard |Not applicable| [RFC5918] | | | + | | 5 |0x05|Typed Wildcard |Not applicable| [[RFC5918]] | | |
− | | | |FEC Element | | [RFC7358] | | | + | | | |FEC Element | | [[RFC7358]] | | |
+-----+----+---------------+--------------+-----------+------------+ | +-----+----+---------------+--------------+-----------+------------+ | ||
− | | 6 |0x06|P2MP |DU | [RFC6388] | | | + | | 6 |0x06|P2MP |DU | [[RFC6388]] | | |
− | | | | | | [RFC7358] | | | + | | | | | | [[RFC7358]] | | |
+-----+----+---------------+--------------+-----------+------------+ | +-----+----+---------------+--------------+-----------+------------+ | ||
− | | 7 |0x07|MP2MP-up |DU | [RFC6388] | | | + | | 7 |0x07|MP2MP-up |DU | [[RFC6388]] | | |
− | | | | | | [RFC7358] | | | + | | | | | | [[RFC7358]] | | |
+-----+----+---------------+--------------+-----------+------------+ | +-----+----+---------------+--------------+-----------+------------+ | ||
− | | 8 |0x08|MP2MP-down |DU | [RFC6388] | | | + | | 8 |0x08|MP2MP-down |DU | [[RFC6388]] | | |
− | | | | | | [RFC7358] | | | + | | | | | | [[RFC7358]] | | |
+-----+----+---------------+--------------+-----------+------------+ | +-----+----+---------------+--------------+-----------+------------+ | ||
− | | 9 |0x09|HSMP-upstream |DU | [RFC7140] | 2014-01-09 | | + | | 9 |0x09|HSMP-upstream |DU | [[RFC7140]] | 2014-01-09 | |
− | | | | | | [RFC7358] | | | + | | | | | | [[RFC7358]] | | |
+-----+----+---------------+--------------+-----------+------------+ | +-----+----+---------------+--------------+-----------+------------+ | ||
− | | 10 |0x0A|HSMP-downstream|DU, Upstream | [RFC7140] | 2014-01-09 | | + | | 10 |0x0A|HSMP-downstream|DU, Upstream | [[RFC7140]] | 2014-01-09 | |
− | | | | | | [RFC7358] | | | + | | | | | | [[RFC7358]] | | |
+-----+----+---------------+--------------+-----------+------------+ | +-----+----+---------------+--------------+-----------+------------+ | ||
− | | 128 |0x80|PWid |DU | [RFC4447] | | | + | | 128 |0x80|PWid |DU | [[RFC4447]] | | |
− | | | |FEC Element | | [RFC7358] | | | + | | | |FEC Element | | [[RFC7358]] | | |
+-----+----+---------------+--------------+-----------+------------+ | +-----+----+---------------+--------------+-----------+------------+ | ||
− | | 129 |0x81|Generalized |DU | [RFC4447] | | | + | | 129 |0x81|Generalized |DU | [[RFC4447]] | | |
− | | | |PWid | | [RFC7358] | | | + | | | |PWid | | [[RFC7358]] | | |
| | |FEC Element | | | | | | | |FEC Element | | | | | ||
+-----+----+---------------+--------------+-----------+------------+ | +-----+----+---------------+--------------+-----------+------------+ | ||
| 130 |0x82|P2MP PW |Upstream | [P2MP-PW] | 2009-06-03 | | | 130 |0x82|P2MP PW |Upstream | [P2MP-PW] | 2009-06-03 | | ||
− | | | |Upstream | | [RFC7358] | | | + | | | |Upstream | | [[RFC7358]] | | |
| | |FEC Element | | | | | | | |FEC Element | | | | | ||
+-----+----+---------------+--------------+-----------+------------+ | +-----+----+---------------+--------------+-----------+------------+ | ||
− | |||
− | |||
− | |||
− | |||
+-----+----+---------------+--------------+-----------+------------+ | +-----+----+---------------+--------------+-----------+------------+ | ||
| 131 |0x83|Protection |DU |[FAST-PROT]| 2010-02-26 | | | 131 |0x83|Protection |DU |[FAST-PROT]| 2010-02-26 | | ||
− | | | |FEC Element | | [RFC7358] | | | + | | | |FEC Element | | [[RFC7358]] | | |
+-----+----+---------------+--------------+-----------+------------+ | +-----+----+---------------+--------------+-----------+------------+ | ||
| 132 |0x84|P2MP PW |DU | [P2MP-PW] | 2014-04-04 | | | 132 |0x84|P2MP PW |DU | [P2MP-PW] | 2014-04-04 | | ||
− | | | |Downstream | | [RFC7358] | | | + | | | |Downstream | | [[RFC7358]] | | |
| | |FEC Element | | | | | | | |FEC Element | | | | | ||
+-----+----+---------------+--------------+-----------+------------+ | +-----+----+---------------+--------------+-----------+------------+ | ||
Line 260: | Line 213: | ||
=== Normative References === | === Normative References === | ||
− | [RFC3212] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R., | + | [[RFC3212]] Jamoussi, B., Ed., 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", [[RFC3212|RFC 3212]], | |
− | + | January 2002, <http://www.rfc-editor.org/info/rfc3212>. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | [[RFC4447]] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and | ||
+ | G. Heron, "Pseudowire Setup and Maintenance Using the | ||
+ | Label Distribution Protocol (LDP)", [[RFC4447|RFC 4447]], April 2006, | ||
+ | <http://www.rfc-editor.org/info/rfc4447>. | ||
+ | [[RFC5036]] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., | ||
+ | "LDP Specification", [[RFC5036|RFC 5036]], October 2007, | ||
+ | <http://www.rfc-editor.org/info/rfc5036>. | ||
+ | [[RFC5918]] Asati, R., Minei, I., and B. Thomas, "Label Distribution | ||
+ | Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class | ||
+ | (FEC)", [[RFC5918|RFC 5918]], August 2010, | ||
+ | <http://www.rfc-editor.org/info/rfc5918>. | ||
+ | [[RFC6388]] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. | ||
+ | Thomas, "Label Distribution Protocol Extensions for | ||
+ | Point-to-Multipoint and Multipoint-to-Multipoint Label | ||
+ | Switched Paths", [[RFC6388|RFC 6388]], November 2011, | ||
+ | <http://www.rfc-editor.org/info/rfc6388>. | ||
+ | [[RFC6389]] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label | ||
+ | Assignment for LDP", [[RFC6389|RFC 6389]], November 2011, | ||
+ | <http://www.rfc-editor.org/info/rfc6389>. | ||
+ | [[RFC7140]] Jin, L., Jounay, F., Wijnands, IJ., and N. Leymann, "LDP | ||
+ | Extensions for Hub and Spoke Multipoint Label Switched | ||
+ | Path", [[RFC7140|RFC 7140]], March 2014, | ||
+ | <http://www.rfc-editor.org/info/rfc7140>. | ||
+ | === Informative References === | ||
+ | [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 | ||
+ | We acknowledge Eric Rosen and Rajiv Asati for their initial review | ||
+ | and input on the document. | ||
− | |||
− | |||
Authors' Addresses | Authors' Addresses | ||
Line 327: | Line 275: | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
Sami Boutros | Sami Boutros | ||
Line 336: | Line 283: | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
Luca Martini | Luca Martini | ||
Line 345: | Line 291: | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
Nicolai Leymann | Nicolai Leymann | ||
Line 354: | Line 299: | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
[[Category:Standards Track]] | [[Category:Standards Track]] |
Latest revision as of 06:03, 2 October 2020
Internet Engineering Task Force (IETF) K. Raza Request for Comments: 7358 S. Boutros Updates: 3212, 4447, 5036, 5918, 6388, 7140 L. Martini Category: Standards Track Cisco Systems, Inc. ISSN: 2070-1721 N. Leymann
Deutsche Telekom October 2014
Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)
Abstract
The label advertising behavior of an LDP speaker for a given Forwarding Equivalence Class (FEC) is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode. This document updates RFC 5036 to make that fact clear. It also updates RFCs 3212, 4447, 5918, 6388, and 7140 by specifying the label advertisement mode for all currently defined LDP FEC types.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7358.
Copyright Notice
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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to 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 are provided without warranty as described in the Simplified BSD License.
Contents
Introduction
The Label Distribution Protocol (LDP) RFC5036 allows label advertisement mode negotiation at the time of session establishment. The LDP specification also dictates that only a single label advertisement mode be negotiated, agreed upon, and used for a given LDP session between two Label Switching Routers (LSRs).
The negotiated label advertisement mode defined in RFC 5036 and carried in the LDP Initialization message is only indicative. It indicates how the LDP speakers on a session will advertise labels for some Forwarding Equivalence Classes (FECs), but it is not a rule that restricts the speakers to behave in a specific way. Furthermore, for some FEC types the advertising behavior of the LDP speaker is governed by the FEC type and not by the negotiated behavior.
This document updates RFC5036 to make that fact clear. It also updates RFC3212, RFC4447, RFC5918, RFC6388, and RFC7140 to indicate, for each FEC type that has already been defined, whether
the label binding advertisements for the FEC are constrained by the negotiated label advertisement mode or not. Furthermore, this document specifies the label advertisement mode to be used for all currently defined FECs.
Label Advertisement Discipline
To remove any ambiguity and conflict regarding a label advertisement discipline among different FEC types sharing 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
Update to RFC 5036
Section 3.5.3 of RFC5036 is updated to add the following two 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) | +----------+----------+--------------------------------+
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 in which these FECs are introduced and defined.
Security Considerations
This document only clarifies the applicability of an LDP session's label advertisement mode and hence does not add any LDP security mechanics and considerations to those already defined in the LDP specification RFC5036.
IANA Considerations
This document mandates the specification of a label advertisement discipline for each defined FEC type and hence 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
the following possible values:
o DU o DoD o As negotiated (DU or DoD) o Upstream o Not applicable o Unknown
- Made this document an additional reference for the registry itself
and for all affected registrations.
- Kept other columns of the registry in place and populated as they
were.
For the currently assigned FEC types, the updated registry looks like:
+=====+====+===============+==============+===========+============+ |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 | | | | +-----+----+---------------+--------------+-----------+------------+
References
Normative References
RFC3212 Jamoussi, B., Ed., 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, <http://www.rfc-editor.org/info/rfc3212>.
RFC4447 Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006, <http://www.rfc-editor.org/info/rfc4447>.
RFC5036 Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
RFC5918 Asati, R., Minei, I., and B. Thomas, "Label Distribution
Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, August 2010, <http://www.rfc-editor.org/info/rfc5918>.
RFC6388 Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.
RFC6389 Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label
Assignment for LDP", RFC 6389, November 2011, <http://www.rfc-editor.org/info/rfc6389>.
RFC7140 Jin, L., Jounay, F., Wijnands, IJ., and N. Leymann, "LDP
Extensions for Hub and Spoke Multipoint Label Switched Path", RFC 7140, March 2014, <http://www.rfc-editor.org/info/rfc7140>.
Informative References
[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
We acknowledge Eric Rosen and Rajiv Asati for their initial review and input on the document.
Authors' Addresses
Kamran Raza Cisco Systems, Inc. 2000 Innovation Drive Ottawa, ON K2K-3E8 Canada
EMail: [email protected]
Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, CA 95134 United States
EMail: [email protected]
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 United States
EMail: [email protected]
Nicolai Leymann Deutsche Telekom AG Winterfeldtstrasse 21 Berlin 10781 Germany
EMail: [email protected]