draft-ijln-mpls-rfc5036bis-01.txt		draft-ijln-mpls-rfc5036bis-02.txt
	Network Working Group X. Chen		Network Working Group X. Chen
	Internet-Draft L. Andersson		Internet-Draft L. Andersson
	Intended status: Standards Track Huawei Technologies		Intended status: Standards Track Huawei Technologies
	Expires: September 19, 2016 N. Leymann		Expires: October 9, 2016 N. Leymann
	Deutsche Telekom		Deutsche Telekom
	I. Minei		I. Minei
	Google		Google
	K. Raza		K. Raza
	Cisco Systems, Inc.		Cisco Systems, Inc.
	March 18, 2016		April 7, 2016
	LDP Specification		LDP Specification
	draft-ijln-mpls-rfc5036bis-01.txt		draft-ijln-mpls-rfc5036bis-02.txt
	Abstract		Abstract
	The architecture for Multiprotocol Label Switching (MPLS) is		The architecture for Multiprotocol Label Switching (MPLS) is
	described in RFC 3031. A fundamental concept in MPLS is that two		described in RFC 3031. A fundamental concept in MPLS is that two
	Label Switching Routers (LSRs) must agree on the meaning of the		Label Switching Routers (LSRs) must agree on the meaning of the
	labels used to forward traffic between and through them. This common		labels used to forward traffic between and through them. This common
	understanding is achieved by using a set of procedures, called a		understanding is achieved by using a set of procedures, called a
	label distribution protocol, by which one LSR informs another of		label distribution protocol, by which one LSR informs another of
	label bindings it has made. This document defines a set of such		label bindings it has made. This document defines a set of such
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 19, 2016.		This Internet-Draft will expire on October 9, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	3.6.2.1. Conservative Label Retention Mode . . . . . . . . 23		3.6.2.1. Conservative Label Retention Mode . . . . . . . . 23
	3.6.2.2. Liberal Label Retention Mode . . . . . . . . . . 23		3.6.2.2. Liberal Label Retention Mode . . . . . . . . . . 23
	3.6.3. Label Advertisement Mode . . . . . . . . . . . . . . 24		3.6.3. Label Advertisement Mode . . . . . . . . . . . . . . 24
	3.7. LDP Identifiers and Next Hop Addresses . . . . . . . . . 24		3.7. LDP Identifiers and Next Hop Addresses . . . . . . . . . 24
	3.8. Loop Detection . . . . . . . . . . . . . . . . . . . . . 24		3.8. Loop Detection . . . . . . . . . . . . . . . . . . . . . 24
	3.8.1. Label Request Message . . . . . . . . . . . . . . . . 25		3.8.1. Label Request Message . . . . . . . . . . . . . . . . 25
	3.8.2. Label Mapping Message . . . . . . . . . . . . . . . . 26		3.8.2. Label Mapping Message . . . . . . . . . . . . . . . . 26
	3.8.3. Discussion . . . . . . . . . . . . . . . . . . . . . 28		3.8.3. Discussion . . . . . . . . . . . . . . . . . . . . . 28
	3.9. Authenticity and Integrity of LDP Messages . . . . . . . 29		3.9. Authenticity and Integrity of LDP Messages . . . . . . . 29
	3.9.1. TCP MD5 Signature Option . . . . . . . . . . . . . . 29		3.9.1. TCP MD5 Signature Option . . . . . . . . . . . . . . 29
	3.9.2. LDP Use of TCP MD5 Signature Option . . . . . . . . . 30		3.9.2. LDP Use of TCP MD5 Signature Option . . . . . . . . . 31
	4. Protocol Specification . . . . . . . . . . . . . . . . . . . 31		4. Protocol Specification . . . . . . . . . . . . . . . . . . . 31
	4.1. LDP PDUs . . . . . . . . . . . . . . . . . . . . . . . . 31		4.1. LDP PDUs . . . . . . . . . . . . . . . . . . . . . . . . 31
	4.2. LDP Procedures . . . . . . . . . . . . . . . . . . . . . 32		4.2. LDP Procedures . . . . . . . . . . . . . . . . . . . . . 32
	4.3. Type-Length-Value Encoding . . . . . . . . . . . . . . . 33		4.3. Type-Length-Value Encoding . . . . . . . . . . . . . . . 33
	4.4. TLV Encodings for Commonly Used Parameters . . . . . . . 35		4.4. TLV Encodings for Commonly Used Parameters . . . . . . . 35
	4.4.1. FEC TLV . . . . . . . . . . . . . . . . . . . . . . . 35		4.4.1. FEC TLV . . . . . . . . . . . . . . . . . . . . . . . 35
	4.4.1.1. FEC Procedures . . . . . . . . . . . . . . . . . 37		4.4.1.1. FEC Procedures . . . . . . . . . . . . . . . . . 37
	4.4.2. Label TLVs . . . . . . . . . . . . . . . . . . . . . 37		4.4.2. Label TLVs . . . . . . . . . . . . . . . . . . . . . 37
	4.4.2.1. Generic Label TLV . . . . . . . . . . . . . . . . 37		4.4.2.1. Generic Label TLV . . . . . . . . . . . . . . . . 37
	4.4.2.2. ATM Label TLV . . . . . . . . . . . . . . . . . . 38		4.4.2.2. ATM Label TLV . . . . . . . . . . . . . . . . . . 38
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	4.4.5.1. Path Vector Procedures . . . . . . . . . . . . . 44		4.4.5.1. Path Vector Procedures . . . . . . . . . . . . . 44
	4.4.6. Status TLV . . . . . . . . . . . . . . . . . . . . . 45		4.4.6. Status TLV . . . . . . . . . . . . . . . . . . . . . 45
	4.5. LDP Messages . . . . . . . . . . . . . . . . . . . . . . 47		4.5. LDP Messages . . . . . . . . . . . . . . . . . . . . . . 47
	4.5.1. Notification Message . . . . . . . . . . . . . . . . 49		4.5.1. Notification Message . . . . . . . . . . . . . . . . 49
	4.5.1.1. Notification Message Procedures . . . . . . . . . 50		4.5.1.1. Notification Message Procedures . . . . . . . . . 50
	4.5.1.2. Events Signaled by Notification Messages . . . . 51		4.5.1.2. Events Signaled by Notification Messages . . . . 51
	4.5.2. Hello Message . . . . . . . . . . . . . . . . . . . . 53		4.5.2. Hello Message . . . . . . . . . . . . . . . . . . . . 53
	4.5.2.1. Hello Message Procedures . . . . . . . . . . . . 56		4.5.2.1. Hello Message Procedures . . . . . . . . . . . . 56
	4.5.3. Initialization Message . . . . . . . . . . . . . . . 57		4.5.3. Initialization Message . . . . . . . . . . . . . . . 57
	4.5.3.1. Initialization Message Procedures . . . . . . . . 66		4.5.3.1. Initialization Message Procedures . . . . . . . . 66
	4.5.4. KeepAlive Message . . . . . . . . . . . . . . . . . . 66		4.5.4. KeepAlive Message . . . . . . . . . . . . . . . . . . 67
	4.5.4.1. KeepAlive Message Procedures . . . . . . . . . . 67		4.5.4.1. KeepAlive Message Procedures . . . . . . . . . . 67
	4.5.5. Address Message . . . . . . . . . . . . . . . . . . . 67		4.5.5. Address Message . . . . . . . . . . . . . . . . . . . 67
	4.5.5.1. Address Message Procedures . . . . . . . . . . . 68		4.5.5.1. Address Message Procedures . . . . . . . . . . . 68
	4.5.6. Address Withdraw Message . . . . . . . . . . . . . . 69		4.5.6. Address Withdraw Message . . . . . . . . . . . . . . 69
	4.5.6.1. Address Withdraw Message Procedures . . . . . . . 70		4.5.6.1. Address Withdraw Message Procedures . . . . . . . 70
	4.5.7. Label Mapping Message . . . . . . . . . . . . . . . . 70		4.5.7. Label Mapping Message . . . . . . . . . . . . . . . . 70
	4.5.7.1. Label Mapping Message Procedures . . . . . . . . 71		4.5.7.1. Label Mapping Message Procedures . . . . . . . . 71
	4.5.8. Label Request Message . . . . . . . . . . . . . . . . 74		4.5.8. Label Request Message . . . . . . . . . . . . . . . . 74
	4.5.8.1. Label Request Message Procedures . . . . . . . . 75		4.5.8.1. Label Request Message Procedures . . . . . . . . 75
	4.5.9. Label Abort Request Message . . . . . . . . . . . . . 77		4.5.9. Label Abort Request Message . . . . . . . . . . . . . 77
	skipping to change at page 4, line 46 ¶		skipping to change at page 4, line 46 ¶
	5.2. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 92		5.2. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 92
	5.3. FEC Type Name Space . . . . . . . . . . . . . . . . . . . 92		5.3. FEC Type Name Space . . . . . . . . . . . . . . . . . . . 92
	5.4. Status Code Name Space . . . . . . . . . . . . . . . . . 92		5.4. Status Code Name Space . . . . . . . . . . . . . . . . . 92
	5.5. Experiment ID Name Space . . . . . . . . . . . . . . . . 93		5.5. Experiment ID Name Space . . . . . . . . . . . . . . . . 93
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 93		6. Security Considerations . . . . . . . . . . . . . . . . . . . 93
	6.1. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 93		6.1. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 93
	6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 94		6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 94
	6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 95		6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 95
	7. Areas for Future Study . . . . . . . . . . . . . . . . . . . 96		7. Areas for Future Study . . . . . . . . . . . . . . . . . . . 96
	8. Changes from RFC 5036 . . . . . . . . . . . . . . . . . . . . 97		8. Changes from RFC 5036 . . . . . . . . . . . . . . . . . . . . 97
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 97		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 97
	10. Appendix A. LDP Label Distribution Procedures . . . . . . . 98		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 98
	10.1. A.1. Handling Label Distribution Events . . . . . . . . 101		10.1. Normative References . . . . . . . . . . . . . . . . . . 98
	10.1.1. A.1.1. Receive Label Request . . . . . . . . . . . 101		10.2. Informative References . . . . . . . . . . . . . . . . . 100
	10.1.2. A.1.2. Receive Label Mapping . . . . . . . . . . . 105		Appendix A. LDP Label Distribution Procedures . . . . . . . . . 101
	10.1.3. A.1.3 Receive Label Abort Request . . . . . . . . . 111		A.1. Handling Label Distribution Events . . . . . . . . . . . 104
	10.1.4. A.1.4 Receive Label Release . . . . . . . . . . . . 112		A.1.1. Receive Label Request . . . . . . . . . . . . . . . . 104
	10.1.5. A.1.5 Receive Label Withdraw . . . . . . . . . . . . 114		A.1.2. Receive Label Mapping . . . . . . . . . . . . . . . . 108
	10.1.6. A.1.6 Recognize New FEC . . . . . . . . . . . . . . 116		A.1.3. Receive Label Abort Request . . . . . . . . . . . . . 114
	10.1.7. A.1.7 Detect Change in FEC Next Hop . . . . . . . . 119		A.1.4. Receive Label Release . . . . . . . . . . . . . . . . 115
	10.1.8. A.1.8. Receive Notification / Label Request Aborted 121		A.1.5. Receive Label Withdraw . . . . . . . . . . . . . . . 117
	10.1.9. A.1.9. Receive Notification / No Label Resources . 122		A.1.6. Recognize New FEC . . . . . . . . . . . . . . . . . . 119
	10.1.10. A.1.10. Receive Notification / No Route . . . . . . 123		A.1.7. Detect Change in FEC Next Hop . . . . . . . . . . . . 122
	10.1.11. A.1.11. Receive Notification / Loop Detected . . . 124		A.1.8. Receive Notification / Label Request Aborted . . . . 124
	10.1.12. A.1.12. Receive Notification / Label Resources		A.1.9. Receive Notification / No Label Resources . . . . . . 125
	Available . . . . . . . . . . . . . . . . . . . . . 124		A.1.10. Receive Notification / No Route . . . . . . . . . . . 126
	10.1.13. A.1.13. Detect Local Label Resources Have Become		A.1.11. Receive Notification / Loop Detected . . . . . . . . 127
	Available . . . . . . . . . . . . . . . . . . . . . 125		A.1.12. Receive Notification / Label Resources Available . . 127
	10.1.14. A.1.14. LSR Decides to No Longer Label Switch a FEC 126		A.1.13. Detect Local Label Resources Have Become Available . 128
	10.1.15. A.1.15. Timeout of Deferred Label Request . . . . . 127		A.1.14. LSR Decides to No Longer Label Switch a FEC . . . . . 129
	10.2. A.2. Common Label Distribution Procedures . . . . . . . 127		A.1.15. Timeout of Deferred Label Request . . . . . . . . . . 130
	10.2.1. A.2.1. Send_Label . . . . . . . . . . . . . . . . . 127		A.2. Common Label Distribution Procedures . . . . . . . . . . 130
	10.2.2. A.2.2. Send_Label_Request . . . . . . . . . . . . . 129		A.2.1. Send_Label . . . . . . . . . . . . . . . . . . . . . 130
	10.2.3. A.2.3. Send_Label_Withdraw . . . . . . . . . . . . 130		A.2.2. Send_Label_Request . . . . . . . . . . . . . . . . . 132
	10.2.4. A.2.4. Send_Notification . . . . . . . . . . . . . 130		A.2.3. Send_Label_Withdraw . . . . . . . . . . . . . . . . . 133
	10.2.5. A.2.5. Send_Message . . . . . . . . . . . . . . . . 131		A.2.4. Send_Notification . . . . . . . . . . . . . . . . . . 133
	10.2.6. A.2.6. Check_Received_Attributes . . . . . . . . . 131		A.2.5. Send_Message . . . . . . . . . . . . . . . . . . . . 134
	10.2.7. A.2.7. Prepare_Label_Request_Attributes . . . . . . 133		A.2.6. Check_Received_Attributes . . . . . . . . . . . . . . 134
	10.2.8. A.2.8. Prepare_Label_Mapping_Attributes . . . . . . 134		A.2.7. Prepare_Label_Request_Attributes . . . . . . . . . . 136
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 137		A.2.8. Prepare_Label_Mapping_Attributes . . . . . . . . . . 137
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 137		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 140
	12.1. Normative References . . . . . . . . . . . . . . . . . . 137
	12.2. Informative References . . . . . . . . . . . . . . . . . 139
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141
	1. Editors notes - this section will be removed before publication		1. Editors notes - this section will be removed before publication
	This entire section will be removed before publication.		This entire section will be removed before publication.
	1.1. Scope of RFC5036bis work		1.1. Scope of RFC5036bis work
	The goal of this document is to take the LDP specification to		The goal of this document is to take the LDP specification to
	Internet Standard.		Internet Standard.
	skipping to change at page 90, line 35 ¶		skipping to change at page 90, line 35 ¶
	then forwards the resulting packet to Rd."		then forwards the resulting packet to Rd."
	The implicit NULL label is represented in LDP as a Generic Label TLV		The implicit NULL label is represented in LDP as a Generic Label TLV
	with a Label field value of 3, as defined in RFC 3032 [RFC3032].		with a Label field value of 3, as defined in RFC 3032 [RFC3032].
	5. RFC 5036 IANA Considerations		5. RFC 5036 IANA Considerations
	Note: In version -00 of this document does only minimal changes to		Note: In version -00 of this document does only minimal changes to
	the RFC 5036 IANA considerationns. The author believe that some		the RFC 5036 IANA considerationns. The author believe that some
	further minor changes will be made eventually. The "IANA		further minor changes will be made eventually. The "IANA
	consideration" section (see Section 11) is included to capture		consideration" section (see Section 9) is included to capture
	anything new that relates to IANA, Before publication the two section		anything new that relates to IANA, Before publication the two section
	will be merged.		will be merged.
	The LDP specification defines the following name spaces that are		The LDP specification defines the following name spaces that are
	managed by IANA and found at [LDP_NAME_SPACE]:		managed by IANA and found at [LDP_NAME_SPACE]:
	- Message Type Name Space, found at [MSG_TYPE_NAME_SPACE]		- Message Type Name Space, found at [MSG_TYPE_NAME_SPACE]
	- TLV Type Name Space, found at [TLV_TYPE_NAME_SPACE]		- TLV Type Name Space, found at [TLV_TYPE_NAME_SPACE]
	- FEC Type Name Space, found at [FEC_TYPE_NAME_SPACE]		- FEC Type Name Space, found at [FEC_TYPE_NAME_SPACE]
	- Status Code Name Space, found at [STATUS_CODE_NAME_SPACE]		- Status Code Name Space, found at [STATUS_CODE_NAME_SPACE]
	skipping to change at page 97, line 46 ¶		skipping to change at page 97, line 46 ¶
	1. Some editorial changes has been made, e.g. internal references is		1. Some editorial changes has been made, e.g. internal references is
	more frequently used, some implicit lists has been replaced by		more frequently used, some implicit lists has been replaced by
	tables, e.g. for Optional Parameters carried in LDP messages.		tables, e.g. for Optional Parameters carried in LDP messages.
	2. The refrence to CR-LDP has been removed.		2. The refrence to CR-LDP has been removed.
	3. References to the LDP registries create outside the LDP		3. References to the LDP registries create outside the LDP
	Specification has been added.		Specification has been added.
	9. Acknowledgments		9. IANA Considerations
	The editors of this document relies heavily on, and would like to		There are no requests for IANA actions in this document.
	thank, everyone that contributed to the develoment and improvement of
	the LDP Specification.
	This document is produced as part of advancing the LDP specification		Note to the RFC Editor - this section can be removed before
	to Internet Standard status. The predessor (RFC 5036) was published		publication.
	as Draft Standard October 2007. It was produced by the MPLS Working
	Group of the IETF and was jointly authored by Loa Andersson, Bob
	Thomas and Ina Minei.
	Since the Draft Standard version was published IETF has abandoned the		10. References
	3 steps standards ladder. Now there is only proposed standard (PS)
	and Internet Standard (IS). This is part of the motivation to make
	the effort to bring the LDP specification to Internet Standard.
	The LDP specification was originally published as RFC 3036 in January		10.1. Normative References
	2001. It was produced by the MPLS Working Group of the IETF and was
	jointly authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre
	Fredette, and Bob Thomas.
	The ideas and text in RFC 3036 were collected from a number of		[ASSIGNED_AF]
	sources. We would like to thank Rick Boivie, Ross Callon, Alex		"IANA Assigned Address Families",
	Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov		<http://www.iana.org/assignments/address-family-numbers>.
	Rekhter, and Arun Viswanathan for their input for RFC 3036.
	The authors would like to thank Eric Gray, David Black, and Sam		[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
	Hartman for their input to and review of RFC 5036. That input has		DOI 10.17487/RFC1321, April 1992,
	been of great help also for the current document.		<http://www.rfc-editor.org/info/rfc1321>.
	In addition, the authors would like to thank the members of the MPLS		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Working Group for their ideas and the support they have given to this		Requirement Levels", BCP 14, RFC 2119,
	document, and in particular, to Eric Rosen, Luca Martini, Markus		DOI 10.17487/RFC2119, March 1997,
	Jork, Mark Duffy, Vach Kompella, Kishore Tiruveedhula, Rama		<http://www.rfc-editor.org/info/rfc2119>.
	Ramakrishnan, Nick Weeds, Adrian Farrel, and Andy Malis.
	Editor note - this section is still work in progress.		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
			DOI 10.17487/RFC2328, April 1998,
			<http://www.rfc-editor.org/info/rfc2328>.
	10. Appendix A. LDP Label Distribution Procedures		[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
			Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
			1998, <http://www.rfc-editor.org/info/rfc2385>.
			[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", RFC 2434,
			DOI 10.17487/RFC2434, October 1998,
			<http://www.rfc-editor.org/info/rfc2434>.
			[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
			McManus, "Requirements for Traffic Engineering Over MPLS",
			RFC 2702, DOI 10.17487/RFC2702, September 1999,
			<http://www.rfc-editor.org/info/rfc2702>.
			[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
			Label Switching Architecture", RFC 3031,
			DOI 10.17487/RFC3031, January 2001,
			<http://www.rfc-editor.org/info/rfc3031>.
			[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
			Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
			Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
			<http://www.rfc-editor.org/info/rfc3032>.
			[RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label
			Switching on Frame Relay Networks Specification",
			RFC 3034, DOI 10.17487/RFC3034, January 2001,
			<http://www.rfc-editor.org/info/rfc3034>.
			[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
			Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP
			and ATM VC Switching", RFC 3035, DOI 10.17487/RFC3035,
			January 2001, <http://www.rfc-editor.org/info/rfc3035>.
			[RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037,
			DOI 10.17487/RFC3037, January 2001,
			<http://www.rfc-editor.org/info/rfc3037>.
			[RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit
			Signalling Extensions for the Label Distribution
			Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005,
			<http://www.rfc-editor.org/info/rfc3988>.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			DOI 10.17487/RFC5226, May 2008,
			<http://www.rfc-editor.org/info/rfc5226>.
			[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
			"Requirements for Operations, Administration, and
			Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
			DOI 10.17487/RFC5860, May 2010,
			<http://www.rfc-editor.org/info/rfc5860>.
			[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
			L., and L. Berger, "A Framework for MPLS in Transport
			Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
			<http://www.rfc-editor.org/info/rfc5921>.
			[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations,
			Administration, and Maintenance Framework for MPLS-Based
			Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
			September 2011, <http://www.rfc-editor.org/info/rfc6371>.
			[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
			Profile (MPLS-TP) Survivability Framework", RFC 6372,
			DOI 10.17487/RFC6372, September 2011,
			<http://www.rfc-editor.org/info/rfc6372>.
			10.2. Informative References
			[EXP_ID_NAME_SPACE]
			"Experiment ID Name Space",
			<http://www.iana.org/assignments/ldp-namespaces/
			ldp-namespaces.xhtml#ldp-namespaces-10>.
			[EXT_BASIC_OPAQUE]
			"LDP MP Opaque Value Element extended type",
			<http://www.iana.org/assignments/ldp-namespaces/
			ldp-namespaces.xhtml#ldp-namespaces-13>.
			[FEC_TYPE_NAME_SPACE]
			"Forwarding Equivalence Class (FEC) Type Name Space",
			<http://www.iana.org/assignments/ldp-namespaces/
			ldp-namespaces.xhtml#fec-type>.
			[LDP_NAME_SPACE]
			"Label Distribution Protocol (LDP) Parameters",
			<http://www.iana.org/assignments/ldp-namespaces/
			ldp-namespaces.xhtml>.
			[MAC_FLUSH]
			"MAC Flush Flags", <http://www.iana.org/assignments/ldp-
			namespaces/ldp-namespaces.xhtml#mac-flush-flags>.
			[MP_BASIC_OPAQUE]
			"LDP MP Opaque Value Element basic type",
			<http://www.iana.org/assignments/ldp-namespaces/
			ldp-namespaces.xhtml#ldp-namespaces-11>.
			[MP_STATUS_VALUE]
			"LDP MP Opaque Value Element extended type",
			<http://www.iana.org/assignments/ldp-namespaces/
			ldp-namespaces.xhtml#ldp-namespaces-14>.
			[MSG_TYPE_NAME_SPACE]
			"Message Type Name Space",
			<http://www.iana.org/assignments/ldp-namespaces/
			ldp-namespaces.xhtml#ldp-namespaces-2>.
			[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
			Border Gateway Protocol 4 (BGP-4)", RFC 4271,
			DOI 10.17487/RFC4271, January 2006,
			<http://www.rfc-editor.org/info/rfc4271>.
			[RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance
			Regarding the TCP MD5 Signature Option (RFC 2385) and the
			BGP-4 Specification", RFC 4278, DOI 10.17487/RFC4278,
			January 2006, <http://www.rfc-editor.org/info/rfc4278>.
			[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, DOI 10.17487/RFC6388, November 2011,
			<http://www.rfc-editor.org/info/rfc6388>.
			[RFC7361] Dutta, P., Balus, F., Stokes, O., Calvignac, G., and D.
			Fedyk, "LDP Extensions for Optimized MAC Address
			Withdrawal in a Hierarchical Virtual Private LAN Service
			(H-VPLS)", RFC 7361, DOI 10.17487/RFC7361, September 2014,
			<http://www.rfc-editor.org/info/rfc7361>.
			[STATUS_CODE_NAME_SPACE]
			"Status Code Name Space",
			<http://www.iana.org/assignments/ldp-namespaces/
			ldp-namespaces.xhtml#status-codes>.
			[TLV_TYPE_NAME_SPACE]
			"TLV Type Name Space", <http://www.iana.org/assignments/
			ldp-namespaces/ldp-namespaces.xhtml#ldp-namespaces-4>.
			Appendix A. LDP Label Distribution Procedures
	This section specifies label distribution behavior in terms of LSR		This section specifies label distribution behavior in terms of LSR
	response to the following events:		response to the following events:
	- Receive Label Request Message;		- Receive Label Request Message;
	- Receive Label Mapping Message;		- Receive Label Mapping Message;
	- Receive Label Abort Request Message;		- Receive Label Abort Request Message;
	- Receive Label Release Message;		- Receive Label Release Message;
	- Receive Label Withdraw Message;		- Receive Label Withdraw Message;
	- Recognize new FEC;		- Recognize new FEC;
	skipping to change at page 99, line 35 ¶		skipping to change at page 102, line 30 ¶
	The algorithms in this section use procedures defined in the MPLS		The algorithms in this section use procedures defined in the MPLS
	architecture specification RFC 3031 [RFC3031] for hop-by-hop routed		architecture specification RFC 3031 [RFC3031] for hop-by-hop routed
	traffic. These procedures are:		traffic. These procedures are:
	- Label Distribution procedure, which is performed by a downstream		- Label Distribution procedure, which is performed by a downstream
	LSR to determine when to distribute a label for a FEC to LDP		LSR to determine when to distribute a label for a FEC to LDP
	peers. The architecture defines four Label Distribution		peers. The architecture defines four Label Distribution
	procedures:		procedures:
	. Downstream Unsolicited Independent Control, called		o Downstream Unsolicited Independent Control, called
	PushUnconditional in RFC 3031 [RFC3031].		PushUnconditional in RFC 3031 [RFC3031].
	. Downstream Unsolicited Ordered Control, called PushConditional		o Downstream Unsolicited Ordered Control, called PushConditional
	in RFC 3031 [RFC3031].		in RFC 3031 [RFC3031].
	. Downstream On Demand Independent Control, called		o Downstream On Demand Independent Control, called
	PulledUnconditional in RFC 3031 [RFC3031].		PulledUnconditional in RFC 3031 [RFC3031].
	. Downstream On Demand Ordered Control, called PulledConditional		o Downstream On Demand Ordered Control, called PulledConditional
	in RFC 3031 [RFC3031].		in RFC 3031 [RFC3031].
	- Label Withdrawal procedure, which is performed by a downstream LSR		- Label Withdrawal procedure, which is performed by a downstream LSR
	to determine when to withdraw a FEC label mapping previously		to determine when to withdraw a FEC label mapping previously
	distributed to LDP peers. The architecture defines a single Label		distributed to LDP peers. The architecture defines a single Label
	Withdrawal procedure. Whenever an LSR breaks the binding between		Withdrawal procedure. Whenever an LSR breaks the binding between
	a label and a FEC, it MUST withdraw the FEC label mapping from all		a label and a FEC, it MUST withdraw the FEC label mapping from all
	LDP peers to which it has previously sent the mapping.		LDP peers to which it has previously sent the mapping.
	- Label Request procedure, which is performed by an upstream LSR to		- Label Request procedure, which is performed by an upstream LSR to
	determine when to explicitly request that a downstream LSR bind a		determine when to explicitly request that a downstream LSR bind a
	label to a FEC and send it the corresponding label mapping. The		label to a FEC and send it the corresponding label mapping. The
	architecture defines three Label Request procedures:		architecture defines three Label Request procedures:
	. Request Never. The LSR never requests a label.		o Request Never. The LSR never requests a label.
	. Request When Needed. The LSR requests a label whenever it		o Request When Needed. The LSR requests a label whenever it
	needs one.		needs one.
	. Request On Request. This procedure is used by non-label		o Request On Request. This procedure is used by non-label
	merging LSRs. The LSR requests a label when it receives a		merging LSRs. The LSR requests a label when it receives a
	request for one, in addition to whenever it needs one.		request for one, in addition to whenever it needs one.
	- Label Release procedure, which is performed by an upstream LSR to		- Label Release procedure, which is performed by an upstream LSR to
	determine when to release a previously received label mapping for		determine when to release a previously received label mapping for
	a FEC. The architecture defines two Label Release procedures:		a FEC. The architecture defines two Label Release procedures:
	. Conservative Label retention, called ReleaseOnChange in RFC		o Conservative Label retention, called ReleaseOnChange in RFC
	3031 [RFC3031].		3031 [RFC3031].
	. Liberal Label retention, called NoReleaseOnChange in RFC 3031		o Liberal Label retention, called NoReleaseOnChange in RFC 3031
	[RFC3031].		[RFC3031].
	- Label Use procedure, which is performed by an LSR to determine		- Label Use procedure, which is performed by an LSR to determine
	when to start using a FEC label for forwarding/switching. The		when to start using a FEC label for forwarding/switching. The
	architecture defines three Label Use procedures:		architecture defines three Label Use procedures:
	. Use Immediate. The LSR immediately uses a label received from		o Use Immediate. The LSR immediately uses a label received from
	a FEC next hop for forwarding/switching.		a FEC next hop for forwarding/switching.
	. Use If Loop Free. The LSR uses a FEC label received from a FEC		o Use If Loop Free. The LSR uses a FEC label received from a FEC
	next hop for forwarding/switching only if it has determined		next hop for forwarding/switching only if it has determined
	that by doing so it will not cause a forwarding loop.		that by doing so it will not cause a forwarding loop.
	. Use If Loop Not Detected. This procedure is the same as Use		o Use If Loop Not Detected. This procedure is the same as Use
	Immediate unless the LSR has detected a loop in the FEC LSP.		Immediate unless the LSR has detected a loop in the FEC LSP.
	Use of the FEC label for forwarding/switching will continue		Use of the FEC label for forwarding/switching will continue
	until the next hop for the FEC changes or the loop is no longer		until the next hop for the FEC changes or the loop is no longer
	detected.		detected.
	This version of LDP does not include a loop prevention mechanism;		This version of LDP does not include a loop prevention mechanism;
	therefore, the procedures below do not make use of the Use If Loop		therefore, the procedures below do not make use of the Use If Loop
	Free procedure.		Free procedure.
	- Label No Route procedure (called the NotAvailable procedure in RFC		- Label No Route procedure (called the NotAvailable procedure in RFC
	3031 [RFC3031]), which is performed by an upstream LSR to		3031 [RFC3031]), which is performed by an upstream LSR to
	determine how to respond to a No Route notification from a		determine how to respond to a No Route notification from a
	downstream LSR in response to a request for a FEC label mapping.		downstream LSR in response to a request for a FEC label mapping.
	The architecture specification defines two Label No Route		The architecture specification defines two Label No Route
	procedures:		procedures:
	. Request Retry. The LSR should issue the label request at a		o Request Retry. The LSR should issue the label request at a
	later time.		later time.
	. No Request Retry. The LSR should assume that the downstream		o No Request Retry. The LSR should assume that the downstream
	LSR will provide a label mapping when the downstream LSR has a		LSR will provide a label mapping when the downstream LSR has a
	next hop, and it should not reissue the request.		next hop, and it should not reissue the request.
	10.1. A.1. Handling Label Distribution Events		A.1. Handling Label Distribution Events
	This section defines LDP label distribution procedures by specifying		This section defines LDP label distribution procedures by specifying
	an algorithm for each label distribution event. The requirement on		an algorithm for each label distribution event. The requirement on
	an LDP implementation is that its event handling must have the effect		an LDP implementation is that its event handling must have the effect
	specified by the algorithms. That is, an implementation need not		specified by the algorithms. That is, an implementation need not
	follow exactly the steps specified by the algorithms as long as the		follow exactly the steps specified by the algorithms as long as the
	effect is identical.		effect is identical.
	The algorithms for handling label distribution events share common		The algorithms for handling label distribution events share common
	actions. The specifications below package these common actions into		actions. The specifications below package these common actions into
	procedure units. Specifications for these common procedures are in		procedure units. Specifications for these common procedures are in
	their own Section, "Common Label Distribution Procedures", which		their own Section, "Common Label Distribution Procedures", which
	follows this.		follows this.
	An implementation would use data structures to store information		An implementation would use data structures to store information
	about protocol activity. This appendix specifies the information to		about protocol activity. This appendix specifies the information to
	be stored in sufficient detail to describe the algorithms, and		be stored in sufficient detail to describe the algorithms, and
	assumes the ability to retrieve the information as needed. It does		assumes the ability to retrieve the information as needed. It does
	not specify the details of the data structures.		not specify the details of the data structures.
	10.1.1. A.1.1. Receive Label Request		A.1.1. Receive Label Request
	Summary:		Summary:
	The response by an LSR to receipt of a FEC label request from an		The response by an LSR to receipt of a FEC label request from an
	LDP peer may involve one or more of the following actions:		LDP peer may involve one or more of the following actions:
	- Transmission of a notification message to the requesting LSR		- Transmission of a notification message to the requesting LSR
	indicating why a label mapping for the FEC cannot be provided;		indicating why a label mapping for the FEC cannot be provided;
	- Transmission of a FEC label mapping to the requesting LSR;		- Transmission of a FEC label mapping to the requesting LSR;
	skipping to change at page 105, line 8 ¶		skipping to change at page 108, line 5 ¶
	A duplicate label request is considered a protocol error and		A duplicate label request is considered a protocol error and
	SHOULD be dropped by the receiving LSR (perhaps with a suitable		SHOULD be dropped by the receiving LSR (perhaps with a suitable
	notification returned to MsgSource).		notification returned to MsgSource).
	3. If the LSR is not merge-capable, this test will fail.		3. If the LSR is not merge-capable, this test will fail.
	4. The Send_Label procedure may fail due to lack of label resources,		4. The Send_Label procedure may fail due to lack of label resources,
	in which case the LSR SHOULD NOT perform the Label Use procedure.		in which case the LSR SHOULD NOT perform the Label Use procedure.
	10.1.2. A.1.2. Receive Label Mapping		A.1.2. Receive Label Mapping
	Summary:		Summary:
	The response by an LSR to receipt of a FEC label mapping from an LDP		The response by an LSR to receipt of a FEC label mapping from an LDP
	peer may involve one or more of the following actions:		peer may involve one or more of the following actions:
	- Transmission of a Label Release message for the FEC label to the		- Transmission of a Label Release message for the FEC label to the
	LDP peer;		LDP peer;
	- Transmission of Label Mapping messages for the FEC to one or more		- Transmission of Label Mapping messages for the FEC to one or more
	skipping to change at page 111, line 19 ¶		skipping to change at page 114, line 19 ¶
	requests, fall through into the Downstream on Demand procedures		requests, fall through into the Downstream on Demand procedures
	in order to satisfy the pending requests.		in order to satisfy the pending requests.
	12. As determined by step LMp.1.		12. As determined by step LMp.1.
	13. An LSR operating in Ordered Control mode may choose to skip at		13. An LSR operating in Ordered Control mode may choose to skip at
	this stage the peer from which it received the advertisement		this stage the peer from which it received the advertisement
	that caused it to generate the label-map message. Doing so will		that caused it to generate the label-map message. Doing so will
	in effect provide a form of split-horizon.		in effect provide a form of split-horizon.
	10.1.3. A.1.3 Receive Label Abort Request		A.1.3. Receive Label Abort Request
	Summary:		Summary:
	When an LSR receives a Label Abort Request message from a peer, it		When an LSR receives a Label Abort Request message from a peer, it
	checks whether it has already responded to the label request in		checks whether it has already responded to the label request in
	question. If it has, it silently ignores the message. If it has		question. If it has, it silently ignores the message. If it has
	not, it sends the peer a Label Request Aborted Notification. In		not, it sends the peer a Label Request Aborted Notification. In
	addition, if it has a label request outstanding for the LSP in		addition, if it has a label request outstanding for the LSP in
	question to a downstream peer, it sends a Label Abort Request to		question to a downstream peer, it sends a Label Abort Request to
	the downstream peer to abort the LSP.		the downstream peer to abort the LSP.
	skipping to change at page 112, line 46 ¶		skipping to change at page 115, line 46 ¶
	Notes:		Notes:
	1. LSR uses FEC and the Label Request message ID TLV carried by the		1. LSR uses FEC and the Label Request message ID TLV carried by the
	label abort request to locate its record (if any) for the		label abort request to locate its record (if any) for the
	previously received label request from MsgSource.		previously received label request from MsgSource.
	2. If LSR has received a label mapping from NextHop, it should		2. If LSR has received a label mapping from NextHop, it should
	behave as if it had advertised a label mapping to MsgSource and		behave as if it had advertised a label mapping to MsgSource and
	MsgSource has released it.		MsgSource has released it.
	10.1.4. A.1.4 Receive Label Release		A.1.4. Receive Label Release
	Summary:		Summary:
	When an LSR receives a Label Release message for a FEC from a		When an LSR receives a Label Release message for a FEC from a
	peer, it checks whether other peers hold the released label. If		peer, it checks whether other peers hold the released label. If
	none do, the LSR removes the label from forwarding/switching use,		none do, the LSR removes the label from forwarding/switching use,
	if it has not already done so, and if the LSR holds a label		if it has not already done so, and if the LSR holds a label
	mapping from the FEC next hop, it releases the label mapping.		mapping from the FEC next hop, it releases the label mapping.
	Context:		Context:
	skipping to change at page 114, line 37 ¶		skipping to change at page 117, line 37 ¶
	other upstream LSR send it a new Label Request for FEC.		other upstream LSR send it a new Label Request for FEC.
	Whether or not to propagate the release is not a protocol issue.		Whether or not to propagate the release is not a protocol issue.
	Label distribution will operate properly whether or not the		Label distribution will operate properly whether or not the
	release is propagated. The decision to propagate or not should		release is propagated. The decision to propagate or not should
	take into consideration factors such as, whether labels are a		take into consideration factors such as, whether labels are a
	scarce resource in the operating environment, the importance of		scarce resource in the operating environment, the importance of
	keeping LSP setup latency low by keeping the amount of signaling		keeping LSP setup latency low by keeping the amount of signaling
	required small, and whether LSP setup is ingress-controlled or		required small, and whether LSP setup is ingress-controlled or
	egress-controlled in the operating environment.		egress-controlled in the operating environment.
	10.1.5. A.1.5 Receive Label Withdraw		A.1.5. Receive Label Withdraw
	Summary:		Summary:
	When an LSR receives a Label Withdraw message for a FEC from an		When an LSR receives a Label Withdraw message for a FEC from an
	LDP peer, it responds with a Label Release message and it removes		LDP peer, it responds with a Label Release message and it removes
	the label from any forwarding/switching use. If Ordered Control		the label from any forwarding/switching use. If Ordered Control
	is in use, the LSR sends a Label Withdraw message to each LDP peer		is in use, the LSR sends a Label Withdraw message to each LDP peer
	to which it had previously sent a label mapping for the FEC. If		to which it had previously sent a label mapping for the FEC. If
	the LSR is using Downstream on Demand label advertisement with		the LSR is using Downstream on Demand label advertisement with
	independent control, it then acts as if it had just recognized the		independent control, it then acts as if it had just recognized the
	skipping to change at page 116, line 17 ¶		skipping to change at page 119, line 17 ¶
	2. LWd.7 handles the case where the LSR is using Downstream On		2. LWd.7 handles the case where the LSR is using Downstream On
	Demand label distribution with independent control. In this		Demand label distribution with independent control. In this
	situation, the LSR should send a label request to the FEC next		situation, the LSR should send a label request to the FEC next
	hop as if it had just recognized the FEC.		hop as if it had just recognized the FEC.
	3. LWd.10 handles both label merging (one or more incoming labels		3. LWd.10 handles both label merging (one or more incoming labels
	map to the same outgoing label) and no label merging (one label		map to the same outgoing label) and no label merging (one label
	maps to the outgoing label) cases.		maps to the outgoing label) cases.
	10.1.6. A.1.6 Recognize New FEC		A.1.6. Recognize New FEC
	Summary:		Summary:
	The response by an LSR to learning a new FEC via the routing table		The response by an LSR to learning a new FEC via the routing table
	may involve one or more of the following actions:		may involve one or more of the following actions:
	- Transmission of label mappings for the FEC to one or more LDP		- Transmission of label mappings for the FEC to one or more LDP
	peers;		peers;
	- Transmission of a label request for the FEC to the FEC next		- Transmission of a label request for the FEC to the FEC next
	skipping to change at page 119, line 9 ¶		skipping to change at page 122, line 9 ¶
	label only if it had a previously received label request marked		label only if it had a previously received label request marked
	as pending. The LSR would have no such pending requests because		as pending. The LSR would have no such pending requests because
	it responds to any label request for an unknown FEC by sending		it responds to any label request for an unknown FEC by sending
	the requesting LSR a No Route notification and discarding the		the requesting LSR a No Route notification and discarding the
	label request; see LRq.3		label request; see LRq.3
	3. If the LSR has a label for the FEC from the Next Hop, it should		3. If the LSR has a label for the FEC from the Next Hop, it should
	behave as if it had just received the label from the Next Hop.		behave as if it had just received the label from the Next Hop.
	This occurs in the case of Liberal Label retention mode.		This occurs in the case of Liberal Label retention mode.
	10.1.7. A.1.7 Detect Change in FEC Next Hop		A.1.7. Detect Change in FEC Next Hop
	Summary:		Summary:
	The response by an LSR to a change in the next hop for a FEC may		The response by an LSR to a change in the next hop for a FEC may
	involve one or more of the following actions:		involve one or more of the following actions:
	- Removal of the label from the FEC's old next hop from		- Removal of the label from the FEC's old next hop from
	forwarding/switching use;		forwarding/switching use;
	- Transmission of label mapping messages for the FEC to one or		- Transmission of label mapping messages for the FEC to one or
	skipping to change at page 121, line 46 ¶		skipping to change at page 124, line 46 ¶
	Label Mapping message where the LSR operating in Conservative		Label Mapping message where the LSR operating in Conservative
	Label retention mode may have released a label mapping received		Label retention mode may have released a label mapping received
	from the New Next Hop before it detected that the FEC next hop had		from the New Next Hop before it detected that the FEC next hop had
	changed.		changed.
	- Regardless of the Label Request procedure in use by the LSR, it		- Regardless of the Label Request procedure in use by the LSR, it
	MUST send a label request if the conditions in NH.13 hold.		MUST send a label request if the conditions in NH.13 hold.
	Therefore, it executes the Send_Label_Request procedure directly		Therefore, it executes the Send_Label_Request procedure directly
	rather than perform the LSR Label Request procedure.		rather than perform the LSR Label Request procedure.
	10.1.8. A.1.8. Receive Notification / Label Request Aborted		A.1.8. Receive Notification / Label Request Aborted
	Summary:		Summary:
	When an LSR receives a Label Request Aborted notification from an LDP		When an LSR receives a Label Request Aborted notification from an LDP
	peer, it records that the corresponding label request transaction, if		peer, it records that the corresponding label request transaction, if
	any, has completed.		any, has completed.
	Context:		Context:
	- LSR. The LSR handling the event.		- LSR. The LSR handling the event.
	skipping to change at page 122, line 32 ¶		skipping to change at page 125, line 32 ¶
	LRqA.b Record that the label request for FEC has been aborted.		LRqA.b Record that the label request for FEC has been aborted.
	LRqA.c DONE.		LRqA.c DONE.
	Note:		Note:
	1. The LSR uses the FEC and RequestMessageID to locate its record,		1. The LSR uses the FEC and RequestMessageID to locate its record,
	if any, of the outstanding label request abort.		if any, of the outstanding label request abort.
	10.1.9. A.1.9. Receive Notification / No Label Resources		A.1.9. Receive Notification / No Label Resources
	Summary:		Summary:
	When an LSR receives a No Label Resources notification from an LDP		When an LSR receives a No Label Resources notification from an LDP
	peer, it stops sending label request messages to the peer until it		peer, it stops sending label request messages to the peer until it
	receives a Label Resources Available Notification from the peer.		receives a Label Resources Available Notification from the peer.
	Context:		Context:
	LSR. The LSR handling the event.		LSR. The LSR handling the event.
	skipping to change at page 123, line 13 ¶		skipping to change at page 126, line 13 ¶
	MsgSource.		MsgSource.
	NoRes.2 Record that label mapping for FEC from MsgSource is needed		NoRes.2 Record that label mapping for FEC from MsgSource is needed
	but that no label resources are available.		but that no label resources are available.
	NoRes.3 Set status record indicating it is not OK to send label		NoRes.3 Set status record indicating it is not OK to send label
	requests to MsgSource.		requests to MsgSource.
	NoRes.4 DONE.		NoRes.4 DONE.
	10.1.10. A.1.10. Receive Notification / No Route		A.1.10. Receive Notification / No Route
	Summary:		Summary:
	When an LSR receives a No Route notification from an LDP peer in		When an LSR receives a No Route notification from an LDP peer in
	response to a Label Request message, the Label No Route procedure		response to a Label Request message, the Label No Route procedure
	in use dictates its response. The LSR either will take no further		in use dictates its response. The LSR either will take no further
	action, or it will defer the label request by starting a timer and		action, or it will defer the label request by starting a timer and
	send another Label Request message to the peer when the timer		send another Label Request message to the peer when the timer
	later expires.		later expires.
	skipping to change at page 124, line 5 ¶		skipping to change at page 127, line 5 ¶
	For Request Retry		For Request Retry
	1. Record deferred label request for FEC and Attributes		1. Record deferred label request for FEC and Attributes
	to be sent to MsgSource.		to be sent to MsgSource.
	2. Start timeout. Goto NoNH.3.		2. Start timeout. Goto NoNH.3.
	NoNH.3 DONE.		NoNH.3 DONE.
	10.1.11. A.1.11. Receive Notification / Loop Detected		A.1.11. Receive Notification / Loop Detected
	Summary:		Summary:
	When an LSR receives a Loop Detected Status Code from an LDP peer		When an LSR receives a Loop Detected Status Code from an LDP peer
	in response to a Label Request message or a Label Mapping message,		in response to a Label Request message or a Label Mapping message,
	it behaves as if it had received a No Route notification.		it behaves as if it had received a No Route notification.
	Context:		Context:
	See "Receive Notification / No Route".		See "Receive Notification / No Route".
	skipping to change at page 124, line 29 ¶		skipping to change at page 127, line 29 ¶
	See "Receive Notification / No Route".		See "Receive Notification / No Route".
	Note:		Note:
	1. When the Loop Detected notification is in response to a Label		1. When the Loop Detected notification is in response to a Label
	Request message, it arrives in a Status Code TLV in a		Request message, it arrives in a Status Code TLV in a
	Notification message. When it is in response to a Label Mapping		Notification message. When it is in response to a Label Mapping
	message, it arrives in a Status Code TLV in a Label Release		message, it arrives in a Status Code TLV in a Label Release
	message.		message.
	10.1.12. A.1.12. Receive Notification / Label Resources Available		A.1.12. Receive Notification / Label Resources Available
	Summary:		Summary:
	When an LSR receives a Label Resources Available notification from		When an LSR receives a Label Resources Available notification from
	an LDP peer, it resumes sending label requests to the peer.		an LDP peer, it resumes sending label requests to the peer.
	Context:		Context:
	- LSR. The LSR handling the event.		- LSR. The LSR handling the event.
	skipping to change at page 125, line 19 ¶		skipping to change at page 128, line 19 ¶
	Res.4 Execute procedure Send_Label_Request (MsgSource, FEC,		Res.4 Execute procedure Send_Label_Request (MsgSource, FEC,
	SAttributes). If the procedure fails, terminate iteration.		SAttributes). If the procedure fails, terminate iteration.
	Res.5 Delete record that no resources are available for a label		Res.5 Delete record that no resources are available for a label
	mapping for FEC needed from MsgSource.		mapping for FEC needed from MsgSource.
	Res.6 Res.6 End iteration from Res.2.		Res.6 Res.6 End iteration from Res.2.
	Res.7 DONE.		Res.7 DONE.
	10.1.13. A.1.13. Detect Local Label Resources Have Become Available		A.1.13. Detect Local Label Resources Have Become Available
	Summary:		Summary:
	After an LSR has sent a No Label Resources notification to an LDP		After an LSR has sent a No Label Resources notification to an LDP
	peer, when label resources later become available it sends a Label		peer, when label resources later become available it sends a Label
	Resources Available notification to each such peer.		Resources Available notification to each such peer.
	Context:		Context:
	- LSR. The LSR handling the event.		- LSR. The LSR handling the event.
	skipping to change at page 126, line 18 ¶		skipping to change at page 129, line 18 ¶
	ResA.8 End iteration from ResA.5		ResA.8 End iteration from ResA.5
	ResA.9 DONE.		ResA.9 DONE.
	Note:		Note:
	1. Iteration ResA.5 through ResA.8 handles the situation where the		1. Iteration ResA.5 through ResA.8 handles the situation where the
	LSR is using Downstream Unsolicited label distribution and was		LSR is using Downstream Unsolicited label distribution and was
	previously unable to allocate a label for a FEC.		previously unable to allocate a label for a FEC.
	10.1.14. A.1.14. LSR Decides to No Longer Label Switch a FEC		A.1.14. LSR Decides to No Longer Label Switch a FEC
	Summary:		Summary:
	An LSR may unilaterally decide to no longer label switch a FEC for		An LSR may unilaterally decide to no longer label switch a FEC for
	an LDP peer. An LSR that does so MUST send a Label Withdraw		an LDP peer. An LSR that does so MUST send a Label Withdraw
	message for the FEC to the peer.		message for the FEC to the peer.
	Context:		Context:
	- Peer. The peer.		- Peer. The peer.
	skipping to change at page 127, line 5 ¶		skipping to change at page 130, line 5 ¶
	DONE.		DONE.
	Note:		Note:
	1. The LSR may remove the label from forwarding/switching use as		1. The LSR may remove the label from forwarding/switching use as
	part of this event or as part of processing the Label Release		part of this event or as part of processing the Label Release
	from the peer in response to the label withdraw. If the LSR		from the peer in response to the label withdraw. If the LSR
	doesn't wait for the Label Release message from the peer, it		doesn't wait for the Label Release message from the peer, it
	SHOULD NOT reuse the label until it receives the Label Release.		SHOULD NOT reuse the label until it receives the Label Release.
	10.1.15. A.1.15. Timeout of Deferred Label Request		A.1.15. Timeout of Deferred Label Request
	Summary:		Summary:
	Label requests are deferred in response to No Route and Loop		Label requests are deferred in response to No Route and Loop
	Detected notifications. When a deferred FEC label request for a		Detected notifications. When a deferred FEC label request for a
	peer times out, the LSR sends the label request.		peer times out, the LSR sends the label request.
	Context:		Context:
	- LSR. The LSR handling the event.		- LSR. The LSR handling the event.
	skipping to change at page 127, line 36 ¶		skipping to change at page 130, line 36 ¶
	TO.1 Retrieve the record of the deferred label request.		TO.1 Retrieve the record of the deferred label request.
	TO.2 Is Peer the next hop for FEC?		TO.2 Is Peer the next hop for FEC?
	If not, goto TO.4.		If not, goto TO.4.
	TO.3 Execute procedure Send_Label_Request (Peer, FEC).		TO.3 Execute procedure Send_Label_Request (Peer, FEC).
	TO.4 DONE.		TO.4 DONE.
	10.2. A.2. Common Label Distribution Procedures		A.2. Common Label Distribution Procedures
	This section specifies utility procedures used by the algorithms that		This section specifies utility procedures used by the algorithms that
	handle label distribution events.		handle label distribution events.
	10.2.1. A.2.1. Send_Label		A.2.1. Send_Label
	Summary:		Summary:
	The Send_Label procedure allocates a label for a FEC for an LDP		The Send_Label procedure allocates a label for a FEC for an LDP
	peer, if possible, and sends a label mapping for the FEC to the		peer, if possible, and sends a label mapping for the FEC to the
	peer. If the LSR is unable to allocate the label and if it has a		peer. If the LSR is unable to allocate the label and if it has a
	pending label request from the peer, it sends the LDP peer a No		pending label request from the peer, it sends the LDP peer a No
	Label Resources notification.		Label Resources notification.
	Parameters:		Parameters:
	skipping to change at page 129, line 16 ¶		skipping to change at page 132, line 16 ¶
	but no-label-resources. (See Note 1.)		but no-label-resources. (See Note 1.)
	SL.14 Return failure.		SL.14 Return failure.
	Note:		Note:
	1. SL.13 handles the case of Downstream Unsolicited label		1. SL.13 handles the case of Downstream Unsolicited label
	distribution when the LSR is unable to allocate a label for a FEC		distribution when the LSR is unable to allocate a label for a FEC
	to send to a Peer.		to send to a Peer.
	10.2.2. A.2.2. Send_Label_Request		A.2.2. Send_Label_Request
	Summary:		Summary:
	An LSR uses the Send_Label_Request procedure to send a request for		An LSR uses the Send_Label_Request procedure to send a request for
	a label for a FEC to an LDP peer if currently permitted to do so.		a label for a FEC to an LDP peer if currently permitted to do so.
	Parameters:		Parameters:
	- Peer. The LDP peer to which the label request is to be sent.		- Peer. The LDP peer to which the label request is to be sent.
	skipping to change at page 130, line 18 ¶		skipping to change at page 133, line 18 ¶
	SLRq.7 Return failure.		SLRq.7 Return failure.
	Note:		Note:
	1. If the LSR is a non-merging LSR, it must distinguish between		1. If the LSR is a non-merging LSR, it must distinguish between
	attempts to send label requests for a FEC triggered by different		attempts to send label requests for a FEC triggered by different
	upstream LDP peers from duplicate requests. This procedure will		upstream LDP peers from duplicate requests. This procedure will
	not send a duplicate label request.		not send a duplicate label request.
	10.2.3. A.2.3. Send_Label_Withdraw		A.2.3. Send_Label_Withdraw
	Summary:		Summary:
	An LSR uses the Send_Label_Withdraw procedure to withdraw a label		An LSR uses the Send_Label_Withdraw procedure to withdraw a label
	for a FEC from an LDP peer. To do this, the LSR sends a Label		for a FEC from an LDP peer. To do this, the LSR sends a Label
	Withdraw message to the peer.		Withdraw message to the peer.
	Parameters:		Parameters:
	- Peer. The LDP peer to which the label withdraw is to be sent.		- Peer. The LDP peer to which the label withdraw is to be sent.
	skipping to change at page 130, line 46 ¶		skipping to change at page 133, line 46 ¶
	- LSR. The LSR executing the procedure.		- LSR. The LSR executing the procedure.
	Algorithm:		Algorithm:
	SWd.1 Execute procedure Send_Message (Peer, Label Withdraw, FEC,		SWd.1 Execute procedure Send_Message (Peer, Label Withdraw, FEC,
	Label).		Label).
	SWd.2 Record that label withdraw for FEC has been sent to Peer and		SWd.2 Record that label withdraw for FEC has been sent to Peer and
	mark it as outstanding.		mark it as outstanding.
	10.2.4. A.2.4. Send_Notification		A.2.4. Send_Notification
	Summary:		Summary:
	An LSR uses the Send_Notification procedure to send an LDP peer a		An LSR uses the Send_Notification procedure to send an LDP peer a
	Notification message.		Notification message.
	Parameters		Parameters
	- Peer. The LDP peer to which the Notification message is to be		- Peer. The LDP peer to which the Notification message is to be
	sent.		sent.
	skipping to change at page 131, line 20 ¶		skipping to change at page 134, line 20 ¶
	- Status. Status code to be included in the Notification message.		- Status. Status code to be included in the Notification message.
	Additional Context:		Additional Context:
	None.		None.
	Algorithm:		Algorithm:
	SNt.1 Execute procedure Send_Message (Peer, Notification, Status)		SNt.1 Execute procedure Send_Message (Peer, Notification, Status)
	10.2.5. A.2.5. Send_Message		A.2.5. Send_Message
	Summary:		Summary:
	An LSR uses the Send_Message procedure to send an LDP peer an LDP		An LSR uses the Send_Message procedure to send an LDP peer an LDP
	message.		message.
	Parameters:		Parameters:
	Peer. The LDP peer to which the message is to be sent.		Peer. The LDP peer to which the message is to be sent.
	skipping to change at page 131, line 44 ¶		skipping to change at page 134, line 44 ¶
	Additional Context:		Additional Context:
	None.		None.
	Algorithm:		Algorithm:
	This procedure is the means by which an LSR sends an LDP message		This procedure is the means by which an LSR sends an LDP message
	of the specified type to the specified LDP peer.		of the specified type to the specified LDP peer.
	10.2.6. A.2.6. Check_Received_Attributes		A.2.6. Check_Received_Attributes
	Summary:		Summary:
	Check the attributes received in a Label Mapping or Label Request		Check the attributes received in a Label Mapping or Label Request
	message. If the attributes include a Hop Count or Path Vector,		message. If the attributes include a Hop Count or Path Vector,
	perform a Loop Detection check. If a loop is detected, cause a		perform a Loop Detection check. If a loop is detected, cause a
	Loop Detected Notification message to be sent to MsgSource.		Loop Detected Notification message to be sent to MsgSource.
	Parameters:		Parameters:
	skipping to change at page 133, line 7 ¶		skipping to change at page 136, line 7 ¶
	CRa.9 DONE.		CRa.9 DONE.
	Note:		Note:
	1. When the attributes being checked were received in a Label		1. When the attributes being checked were received in a Label
	Mapping message, the LSR sends the Loop Detected notification in		Mapping message, the LSR sends the Loop Detected notification in
	a Status Code TLV in a Label Release message. (See		a Status Code TLV in a Label Release message. (See
	Section "Receive Label Mapping".)		Section "Receive Label Mapping".)
	10.2.7. A.2.7. Prepare_Label_Request_Attributes		A.2.7. Prepare_Label_Request_Attributes
	Summary:		Summary:
	This procedure is used whenever a Label Request is to be sent to a		This procedure is used whenever a Label Request is to be sent to a
	Peer to compute the Hop Count and Path Vector, if any, to include		Peer to compute the Hop Count and Path Vector, if any, to include
	in the message.		in the message.
	Parameters:		Parameters:
	Peer. The LDP peer to which the message is to be sent.		Peer. The LDP peer to which the message is to be sent.
	skipping to change at page 134, line 38 ¶		skipping to change at page 137, line 38 ¶
	PRqA.14 DONE.		PRqA.14 DONE.
	Notes:		Notes:
	1. The link with Peer may require that Hop Count be included in		1. The link with Peer may require that Hop Count be included in
	Label Request messages; for example, see RFC 3035 [RFC3034] and		Label Request messages; for example, see RFC 3035 [RFC3034] and
	RFC 3034 [RFC3034].		RFC 3034 [RFC3034].
	2. For hop count arithmetic, unknown + 1 = unknown.		2. For hop count arithmetic, unknown + 1 = unknown.
	10.2.8. A.2.8. Prepare_Label_Mapping_Attributes		A.2.8. Prepare_Label_Mapping_Attributes
	Summary:		Summary:
	This procedure is used whenever a Label Mapping is to be sent to a		This procedure is used whenever a Label Mapping is to be sent to a
	Peer to compute the Hop Count and Path Vector, if any, to include		Peer to compute the Hop Count and Path Vector, if any, to include
	in the message.		in the message.
	Parameters:		Parameters:
	- Peer. The LDP peer to which the message is to be sent.		- Peer. The LDP peer to which the message is to be sent.
	skipping to change at page 137, line 18 ¶		skipping to change at page 140, line 18 ¶
	2. If the LSR is at the edge of a cloud of LSRs that do not perform		2. If the LSR is at the edge of a cloud of LSRs that do not perform
	TTL-decrement and it is propagating the Label Mapping message		TTL-decrement and it is propagating the Label Mapping message
	upstream into the cloud, it sets the Hop Count to 1 so that Hop		upstream into the cloud, it sets the Hop Count to 1 so that Hop
	Count across the cloud is calculated properly. This ensures		Count across the cloud is calculated properly. This ensures
	proper TTL management for packets forwarded across the part of		proper TTL management for packets forwarded across the part of
	the LSP that passes through the cloud.		the LSP that passes through the cloud.
	3. For hop count arithmetic, unknown + 1 = unknown.		3. For hop count arithmetic, unknown + 1 = unknown.
	11. IANA Considerations		Acknowledgments
	There are no requests for IANA actions in this document.
	Note to the RFC Editor - this section can be removed before
	publication.
	12. References
	12.1. Normative References
	[ASSIGNED_AF]
	"IANA Assigned Address Families",
	<http://www.iana.org/assignments/address-family-numbers>.
	[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
	DOI 10.17487/RFC1321, April 1992,
	<http://www.rfc-editor.org/info/rfc1321>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
	DOI 10.17487/RFC2328, April 1998,
	<http://www.rfc-editor.org/info/rfc2328>.
	[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
	Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
	1998, <http://www.rfc-editor.org/info/rfc2385>.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", RFC 2434,
	DOI 10.17487/RFC2434, October 1998,
	<http://www.rfc-editor.org/info/rfc2434>.
	[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
	McManus, "Requirements for Traffic Engineering Over MPLS",
	RFC 2702, DOI 10.17487/RFC2702, September 1999,
	<http://www.rfc-editor.org/info/rfc2702>.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031,
	DOI 10.17487/RFC3031, January 2001,
	<http://www.rfc-editor.org/info/rfc3031>.
	[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
	Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
	Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
	<http://www.rfc-editor.org/info/rfc3032>.
	[RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label
	Switching on Frame Relay Networks Specification",
	RFC 3034, DOI 10.17487/RFC3034, January 2001,
	<http://www.rfc-editor.org/info/rfc3034>.
	[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
	Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP
	and ATM VC Switching", RFC 3035, DOI 10.17487/RFC3035,
	January 2001, <http://www.rfc-editor.org/info/rfc3035>.
	[RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037,
	DOI 10.17487/RFC3037, January 2001,
	<http://www.rfc-editor.org/info/rfc3037>.
	[RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit
	Signalling Extensions for the Label Distribution
	Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005,
	<http://www.rfc-editor.org/info/rfc3988>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.
	[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
	"Requirements for Operations, Administration, and
	Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
	DOI 10.17487/RFC5860, May 2010,
	<http://www.rfc-editor.org/info/rfc5860>.
	[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
	L., and L. Berger, "A Framework for MPLS in Transport
	Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
	<http://www.rfc-editor.org/info/rfc5921>.
	[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations,
	Administration, and Maintenance Framework for MPLS-Based
	Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
	September 2011, <http://www.rfc-editor.org/info/rfc6371>.
	[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
	Profile (MPLS-TP) Survivability Framework", RFC 6372,
	DOI 10.17487/RFC6372, September 2011,
	<http://www.rfc-editor.org/info/rfc6372>.
	12.2. Informative References
	[EXP_ID_NAME_SPACE]
	"Experiment ID Name Space",
	<http://www.iana.org/assignments/ldp-namespaces/
	ldp-namespaces.xhtml#ldp-namespaces-10>.
	[EXT_BASIC_OPAQUE]
	"LDP MP Opaque Value Element extended type",
	<http://www.iana.org/assignments/ldp-namespaces/
	ldp-namespaces.xhtml#ldp-namespaces-13>.
	[FEC_TYPE_NAME_SPACE]
	"Forwarding Equivalence Class (FEC) Type Name Space",
	<http://www.iana.org/assignments/ldp-namespaces/
	ldp-namespaces.xhtml#fec-type>.
	[LDP_NAME_SPACE]
	"Label Distribution Protocol (LDP) Parameters",
	<http://www.iana.org/assignments/ldp-namespaces/
	ldp-namespaces.xhtml>.
	[MAC_FLUSH]
	"MAC Flush Flags", <http://www.iana.org/assignments/ldp-
	namespaces/ldp-namespaces.xhtml#mac-flush-flags>.
	[MP_BASIC_OPAQUE]
	"LDP MP Opaque Value Element basic type",
	<http://www.iana.org/assignments/ldp-namespaces/
	ldp-namespaces.xhtml#ldp-namespaces-11>.
	[MP_STATUS_VALUE]		The editors of this document relies heavily on, and would like to
	"LDP MP Opaque Value Element extended type",		thank, everyone that contributed to the develoment and improvement of
	<http://www.iana.org/assignments/ldp-namespaces/		the LDP Specification.
	ldp-namespaces.xhtml#ldp-namespaces-14>.
	[MSG_TYPE_NAME_SPACE]		This document is produced as part of advancing the LDP specification
	"Message Type Name Space",		to Internet Standard status. The predessor (RFC 5036) was published
	<http://www.iana.org/assignments/ldp-namespaces/		as Draft Standard October 2007. It was produced by the MPLS Working
	ldp-namespaces.xhtml#ldp-namespaces-2>.		Group of the IETF and was jointly authored by Loa Andersson, Bob
			Thomas and Ina Minei.
	[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A		Since the Draft Standard version was published IETF has abandoned the
	Border Gateway Protocol 4 (BGP-4)", RFC 4271,		3 steps standards ladder. Now there is only proposed standard (PS)
	DOI 10.17487/RFC4271, January 2006,		and Internet Standard (IS). This is part of the motivation to make
	<http://www.rfc-editor.org/info/rfc4271>.		the effort to bring the LDP specification to Internet Standard.
	[RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance		The LDP specification was originally published as RFC 3036 in January
	Regarding the TCP MD5 Signature Option (RFC 2385) and the		2001. It was produced by the MPLS Working Group of the IETF and was
	BGP-4 Specification", RFC 4278, DOI 10.17487/RFC4278,		jointly authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre
	January 2006, <http://www.rfc-editor.org/info/rfc4278>.		Fredette, and Bob Thomas.
	[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.		The ideas and text in RFC 3036 were collected from a number of
	Thomas, "Label Distribution Protocol Extensions for Point-		sources. We would like to thank Rick Boivie, Ross Callon, Alex
	to-Multipoint and Multipoint-to-Multipoint Label Switched		Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov
	Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,		Rekhter, and Arun Viswanathan for their input for RFC 3036.
	<http://www.rfc-editor.org/info/rfc6388>.
	[RFC7361] Dutta, P., Balus, F., Stokes, O., Calvignac, G., and D.		The authors would like to thank Eric Gray, David Black, and Sam
	Fedyk, "LDP Extensions for Optimized MAC Address		Hartman for their input to and review of RFC 5036. That input has
	Withdrawal in a Hierarchical Virtual Private LAN Service		been of great help also for the current document.
	(H-VPLS)", RFC 7361, DOI 10.17487/RFC7361, September 2014,
	<http://www.rfc-editor.org/info/rfc7361>.
	[STATUS_CODE_NAME_SPACE]		In addition, the authors would like to thank the members of the MPLS
	"Status Code Name Space",		Working Group for their ideas and the support they have given to this
	<http://www.iana.org/assignments/ldp-namespaces/		document, and in particular, to Eric Rosen, Luca Martini, Markus
	ldp-namespaces.xhtml#status-codes>.		Jork, Mark Duffy, Vach Kompella, Kishore Tiruveedhula, Rama
			Ramakrishnan, Nick Weeds, Adrian Farrel, and Andy Malis.
	[TLV_TYPE_NAME_SPACE]		Editor note - this section is still work in progress.
	"TLV Type Name Space", <http://www.iana.org/assignments/
	ldp-namespaces/ldp-namespaces.xhtml#ldp-namespaces-4>.
	Authors' Addresses		Authors' Addresses
	Xia Chen		Xia Chen
	Huawei Technologies		Huawei Technologies
	Email: jescia.chenxia@huawei.com		Email: jescia.chenxia@huawei.com
	Loa Andersson		Loa Andersson
	Huawei Technologies		Huawei Technologies
End of changes. 66 change blocks.
	270 lines changed or deleted		268 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/