draft-ietf-mpls-app-aware-tldp-09v3.original		draft-ietf-mpls-app-aware-tldp-09v3.txt
	MPLS Working Group Santosh Esale		MPLS Working Group S. Esale
	INTERNET-DRAFT Raveendra Torvi		Internet-Draft R. Torvi
	Updates: 7473 (if approved) Juniper Networks		Updates: 7473 (if approved) Juniper Networks
	Intended Status: Proposed Standard Luay Jalil		Intended status: Standards Track L. Jalil
	Expires: December 29, 2017 Verizon		Expires: December 29, 2017 Verizon
	Uma Chunduri		U. Chunduri
	Huawei		Huawei
	Kamran Raza		K. Raza
	Cisco Systems, Inc.		Cisco Systems, Inc.
	June 27, 2017		June 27, 2017
	Application-aware Targeted LDP		Application-aware Targeted LDP
	draft-ietf-mpls-app-aware-tldp-09		draft-ietf-mpls-app-aware-tldp-09
	Abstract		Abstract
	Recent targeted Label Distribution Protocol (tLDP) applications such		Recent targeted Label Distribution Protocol (tLDP) applications such
	as remote loop-free alternate (LFA) and BGP auto discovered		as remote loop-free alternate (LFA) and BGP auto discovered
	pseudowire may automatically establish a tLDP session to any Label		pseudowire may automatically establish a tLDP session to any Label
	Switching Router (LSR) in a network. The initiating LSR has		Switching Router (LSR) in a network. The initiating LSR has
	information about the targeted applications to administratively		information about the targeted applications to administratively
	control initiation of the session. However, the responding LSR has no		control initiation of the session. However, the responding LSR has
	such information to control acceptance of this session. This document		no such information to control acceptance of this session. This
	defines a mechanism to advertise and negotiate Targeted Applications		document defines a mechanism to advertise and negotiate Targeted
	Capability (TAC) during LDP session initialization. As the		Applications Capability (TAC) during LDP session initialization. As
	responding LSR becomes aware of targeted applications, it may		the responding LSR becomes aware of targeted applications, it may
	establish a limited number of tLDP sessions for certain applications.		establish a limited number of tLDP sessions for certain applications.
	In addition, each targeted application is mapped to LDP Forwarding		In addition, each targeted application is mapped to LDP Forwarding
	Equivalence Class (FEC) Elements to advertise only necessary LDP FEC-		Equivalence Class (FEC) Elements to advertise only necessary LDP FEC-
	label bindings over the session. This document updates RFC 7473 for		label bindings over the session. This document updates RFC 7473 for
	enabling advertisement of LDP FEC-label bindings over the session.		enabling advertisement of LDP FEC-label bindings over the session.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as		working documents as Internet-Drafts. The list of current Internet-
	Internet-Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on December 29, 2017.
	http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html
	Copyright and License Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Conventions Used in This Document . . . . . . . . . . . . . 4		1.1. Conventions Used in This Document . . . . . . . . . . . . 4
	1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Targeted Application Capability . . . . . . . . . . . . . . . . 5		2. Targeted Application Capability . . . . . . . . . . . . . . . 4
	2.1 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6		2.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3 LDP message procedures . . . . . . . . . . . . . . . . . . . 8		2.3. LDP message procedures . . . . . . . . . . . . . . . . . 8
	2.3.1 Initialization message . . . . . . . . . . . . . . . . . 8		2.3.1. Initialization message . . . . . . . . . . . . . . . 8
	2.3.2 Capability message . . . . . . . . . . . . . . . . . . . 9		2.3.2. Capability message . . . . . . . . . . . . . . . . . 8
	3. Targeted Application FEC Advertisement Procedures . . . . . . . 9		3. Targeted Application FEC Advertisement Procedures . . . . . . 8
	4. Interaction of Targeted Application Capabilities and State		4. Interaction of Targeted Application Capabilities and State
	Advertisement Control Capabilities . . . . . . . . . . . . . . 10		Advertisement Control Capabilities . . . . . . . . . . . . . 10
	5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.1 Remote LFA Automatic Targeted session . . . . . . . . . . . 12		5.1. Remote LFA Automatic Targeted session . . . . . . . . . . 12
	5.2 FEC 129 Auto Discovery Targeted session . . . . . . . . . . 13		5.2. FEC 129 Auto Discovery Targeted session . . . . . . . . . 12
	5.3 LDP over RSVP and Remote LFA targeted session . . . . . . . 13		5.3. LDP over RSVP and Remote LFA targeted session . . . . . . 13
	5.4 mLDP node protection targeted session . . . . . . . . . . . 13		5.4. mLDP node protection targeted session . . . . . . . . . . 13
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 15		8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15
	9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 15		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.1 Normative References . . . . . . . . . . . . . . . . . . . 16		10.1. Normative References . . . . . . . . . . . . . . . . . . 16
	10.2 Informative References . . . . . . . . . . . . . . . . . . 16		10.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1 Introduction		1. Introduction
	LDP uses the extended discovery mechanism to establish the tLDP		LDP uses the extended discovery mechanism to establish the tLDP
	adjacency and subsequent session as described in [RFC5036]. A LSR		adjacency and subsequent session as described in [RFC5036]. A LSR
	initiates extended discovery by sending tLDP Hello to specific		initiates extended discovery by sending tLDP Hello to specific
	address. The remote LSR decides to either accept or ignore the tLDP		address. The remote LSR decides to either accept or ignore the tLDP
	Hello based on local configuration only. Targeted LDP application is		Hello based on local configuration only. Targeted LDP application is
	an application that uses tLDP session to exchange information such as		an application that uses tLDP session to exchange information such as
	FEC-Label bindings with a peer LSR in the network. For an application		FEC-Label bindings with a peer LSR in the network. For an
	such as FEC 128 pseudowire, the remote LSR is configured with the		application such as FEC 128 pseudowire, the remote LSR is configured
	source LSR address so that it can use that information to accept or		with the source LSR address so that it can use that information to
	ignore given tLDP Hello.		accept or ignore given tLDP Hello.
	However, applications such as Remote LFA and BGP auto discovered		However, applications such as Remote LFA and BGP auto discovered
	pseudowire automatically initiate asymmetric extended discovery to		pseudowire automatically initiate asymmetric extended discovery to
	any LSR in a network based on local state only. With these		any LSR in a network based on local state only. With these
	applications, the remote LSR is not explicitly configured with the		applications, the remote LSR is not explicitly configured with the
	source LSR address. So the remote LSR either responds or ignores all		source LSR address. So the remote LSR either responds or ignores all
	tLDP Hellos.		tLDP Hellos.
	In addition, since the session is initiated and established after		In addition, since the session is initiated and established after
	adjacency formation, the responding LSR has no targeted applications		adjacency formation, the responding LSR has no targeted applications
	information available to choose a session with targeted application		information available to choose a session with targeted application
	that it is configured to support. Also, the initiating LSR may employ		that it is configured to support. Also, the initiating LSR may
	a limit per application on locally initiated automatic tLDP sessions,		employ a limit per application on locally initiated automatic tLDP
	however the responding LSR has no such information to employ a		sessions, however the responding LSR has no such information to
	similar limit on the incoming tLDP sessions. Further, the responding		employ a similar limit on the incoming tLDP sessions. Further, the
	LSR does not know whether the source LSR is establishing a tLDP		responding LSR does not know whether the source LSR is establishing a
	session for configured, automatic or both applications.		tLDP session for configured, automatic or both applications.
	This document proposes and describes a solution to advertise Targeted		This document proposes and describes a solution to advertise Targeted
	Application Capability (TAC), consisting of a targeted application		Application Capability (TAC), consisting of a targeted application
	list, during initialization of a tLDP session. It also defines a		list, during initialization of a tLDP session. It also defines a
	mechanism to enable an new application and disable an old application		mechanism to enable an new application and disable an old application
	after session establishment. This capability advertisement provides		after session establishment. This capability advertisement provides
	the responding LSR with the necessary information to control the		the responding LSR with the necessary information to control the
	acceptance of tLDP sessions per application. For instance, an LSR may		acceptance of tLDP sessions per application. For instance, an LSR
	accept all BGP auto discovered tLDP sessions as defined in [RFC6074]		may accept all BGP auto discovered tLDP sessions as defined in
	but may only accept limited number of Remote LFA tLDP sessions as		[RFC6074] but may only accept limited number of Remote LFA tLDP
	defined in [RFC7490]		sessions as defined in [RFC7490]
	Also, the targeted LDP application is mapped to LDP FEC element type		Also, the targeted LDP application is mapped to LDP FEC element type
	to advertise specific application FECs only, avoiding the		to advertise specific application FECs only, avoiding the
	advertisement of other unnecessary FECs over a tLDP session.		advertisement of other unnecessary FECs over a tLDP session.
	1.1 Conventions Used in This Document		1.1. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in RFC		"OPTIONAL" in this document are to be interpreted as described in RFC
	2119 [RFC2119] and RFC 8174 [RFC8174] when, and only when, they		2119 [RFC2119] and RFC 8174 [RFC8174] when, and only when, they
	appear in all capitals, as shown here.		appear in all capitals, as shown here.
	1.2 Terminology		1.2. Terminology
	In addition to the terminology defined in [RFC7473], this document		In addition to the terminology defined in [RFC7473], this document
	uses the following terms:		uses the following terms:
	tLDP : Targeted LDP		tLDP : Targeted LDP
	TAC : Targeted Application Capability		TAC : Targeted Application Capability
	TAE : Targeted Application Element		TAE : Targeted Application Element
	TA-Id : Targeted Application Identifier		TA-Id : Targeted Application Identifier
	SAC : State Advertisement Control Capability		SAC : State Advertisement Control Capability
	LSR : Label Switching Router		LSR : Label Switching Router
	skipping to change at page 5, line 32		skipping to change at page 4, line 36
	RSVP-TE : RSVP Traffic Engineering		RSVP-TE : RSVP Traffic Engineering
	P2MP : Point-to-Multipoint		P2MP : Point-to-Multipoint
	PW : Pseudowire		PW : Pseudowire
	P2P-PW : Point-to-point Psuedowire		P2P-PW : Point-to-point Psuedowire
	MP2MP : Multipoint-to-Multipoint		MP2MP : Multipoint-to-Multipoint
	HSMP LSP: Hub and Spoke Multipoint Label Switched Path		HSMP LSP: Hub and Spoke Multipoint Label Switched Path
	LSP : Label Switched Path		LSP : Label Switched Path
	MP2P : Multipoint-to-point		MP2P : Multipoint-to-point
	MPT : Merge Point		MPT : Merge Point
	2. Targeted Application Capability		2. Targeted Application Capability
	2.1 Encoding		2.1. Encoding
	An LSR MAY advertise that it is capable of negotiating a targeted LDP		An LSR MAY advertise that it is capable of negotiating a targeted LDP
	application list over a tLDP session by using the Capability		application list over a tLDP session by using the Capability
	Advertisement as defined in [RFC5561] and encoded as follows:		Advertisement as defined in [RFC5561] and encoded as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|U|F| TLV Code Point | Length |		|U|F| TLV Code Point | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 6, line 4		skipping to change at page 5, line 15
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|U|F| TLV Code Point | Length |		|U|F| TLV Code Point | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S| Reserved | |		|S| Reserved | |
	+-+-+-+-+-+-+-+-+ Capability Data |		+-+-+-+-+-+-+-+-+ Capability Data |
	| +-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	This document defines a new optional capability TLV of type TBD1		This document defines a new optional capability TLV of type TBD1
	called 'Targeted Application Capability (TAC)'. Flag "U" MUST be		called 'Targeted Application Capability (TAC)'. Flag "U" MUST be
	set to 1 to indicate that this capability must be silently ignored		set to 1 to indicate that this capability must be silently ignored
	if unknown. The TAC's Capability Data contains the Targeted		if unknown. The TAC's Capability Data contains the Targeted
	Application Element (TAE) information encoded as follows:		Application Element (TAE) information encoded as follows:
	Targeted Application Element(TAE)		Targeted Application Element(TAE)
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Targ. Appl. Id |E| Reserved |		| Targ. Appl. Id |E| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Targeted Application Identifier (TA-Id):		Targeted Application Identifier (TA-Id):
	a 16 bit Targeted Application Identifier value.		a 16 bit Targeted Application Identifier value.
	E-bit: The enable bit indicates whether the sender is		E-bit: The enable bit indicates whether the sender is advertising
	advertising or withdrawing the TAE. The E-bit value is used as		or withdrawing the TAE. The E-bit value is used as follows:
	follows:
	1 - The TAE is advertising the targeted application.		1 - The TAE is advertising the targeted application. 0 - The
	0 - The TAE is withdrawing the targeted application.		TAE is withdrawing the targeted application.
	2.2 Procedures		2.2. Procedures
	At tLDP session establishment time, a LSR MAY include a new		At tLDP session establishment time, a LSR MAY include a new
	capability TLV, TAC TLV, as an optional TLV in the LDP Initialization		capability TLV, TAC TLV, as an optional TLV in the LDP Initialization
	message. The TAC TLV's Capability data MAY consist of zero or more		message. The TAC TLV's Capability data MAY consist of zero or more
	TAEs each pertaining to a unique TA-Id that a LSR supports over the		TAEs each pertaining to a unique TA-Id that a LSR supports over the
	session. If the receiver LSR receives the same TA-Id in more than one		session. If the receiver LSR receives the same TA-Id in more than
	TAE, it MUST process the first element and ignore the duplicate		one TAE, it MUST process the first element and ignore the duplicate
	elements. If the receiver LSR receives an unknown TA-Id in the TAE,		elements. If the receiver LSR receives an unknown TA-Id in the TAE,
	it MUST silently ignore such a TAE and continue processing the rest		it MUST silently ignore such a TAE and continue processing the rest
	of the TLV.		of the TLV.
	If the receiver LSR does not receive the TAC TLV in the		If the receiver LSR does not receive the TAC TLV in the
	Initialization message or it does not understand the TAC TLV, the TAC		Initialization message or it does not understand the TAC TLV, the TAC
	negotiation is considered unsuccessful and the session establishment		negotiation is considered unsuccessful and the session establishment
	proceeds as per [RFC5036]. On the receipt of a valid TAC TLV, an LSR		proceeds as per [RFC5036]. On the receipt of a valid TAC TLV, an LSR
	MUST generate its own TAC TLV with TAEs consisting of unique TA-Ids		MUST generate its own TAC TLV with TAEs consisting of unique TA-Ids
	that it supports over the tLDP session. If there is at least one TAE		that it supports over the tLDP session. If there is at least one TAE
	common between the TAC TLV it has received and its own, the session		common between the TAC TLV it has received and its own, the session
	MUST proceed to establishment as per [RFC5036]. If not, A LSR MUST		MUST proceed to establishment as per [RFC5036]. If not, A LSR MUST
	send a 'Session Rejected/Targeted Application Capability Mis-Match'		send a 'Session Rejected/Targeted Application Capability Mis-Match'
	Notification message to the peer and close the session. The		Notification message to the peer and close the session. The
	initiating LSR SHOULD tear down the corresponding tLDP adjacency		initiating LSR SHOULD tear down the corresponding tLDP adjacency
	after sent or receipt of a 'Session Rejected/Targeted Application		after sent or receipt of a 'Session Rejected/Targeted Application
	Capability Mis-Match' Notification message to or from the responding		Capability Mis-Match' Notification message to or from the responding
	LSR respectively.		LSR respectively.
	If both the peers support TAC TLV, an LSR decides to establish or		If both the peers support TAC TLV, an LSR decides to establish or
	close a tLDP session based on the negotiated targeted application		close a tLDP session based on the negotiated targeted application
	list. For example, an initiating LSR advertises A, B and C as TA-Ids,		list. For example, an initiating LSR advertises A, B and C as TA-
	and the responding LSR advertises C, D and E as TA-Ids. Then the		Ids, and the responding LSR advertises C, D and E as TA-Ids. Then the
	negotiated TA-Id as per both the LSRs is C. Another example, an		negotiated TA-Id as per both the LSRs is C. Another example, an
	initiating LSR advertises A, B and C as TA-Ids, and the responding		initiating LSR advertises A, B and C as TA-Ids, and the responding
	LSR, which acts as a passive LSR, advertises all the applications -		LSR, which acts as a passive LSR, advertises all the applications -
	A, B, C, D and E - as TA-Ids that it supports over this session. Then		A, B, C, D and E - as TA-Ids that it supports over this session.
	the negotiated targeted applications as per both the LSRs are A, B		Then the negotiated targeted applications as per both the LSRs are A,
	and C. Finally, If the initiating LSR advertises A, B and C as a TA-		B and C. Finally, If the initiating LSR advertises A, B and C as a
	Ids and the responding LSR advertises D and E as TA-Ids, then the		TA- Ids and the responding LSR advertises D and E as TA-Ids, then the
	negotiated targeted applications as per both the LSRs are none.		negotiated targeted applications as per both the LSRs are none.
	Therefore, if the intersection of the sets of received and sent TA-Id		Therefore, if the intersection of the sets of received and sent TA-Id
	is null, then LSR sends 'Session Rejected/Targeted Application		is null, then LSR sends 'Session Rejected/Targeted Application
	Capability Mis-Match' Notification message to the peer LSR and closes		Capability Mis-Match' Notification message to the peer LSR and closes
	the session.		the session.
	When the responding LSR playing the active role [RFC5036] in LDP		When the responding LSR playing the active role [RFC5036] in LDP
	session establishment receives a 'Session Rejected/Targeted		session establishment receives a 'Session Rejected/Targeted
	Application Capability Mis-Match' Notification message, it MUST set		Application Capability Mis-Match' Notification message, it MUST set
	its session setup retry interval to a maximum value, as such 0xffff.		its session setup retry interval to a maximum value, as such 0xffff.
	The session MAY stay in NON EXISTENT state. When it detects a change		The session MAY stay in NON EXISTENT state. When it detects a change
	in the initiating LSR or local LSR configuration pertaining to TAC		in the initiating LSR or local LSR configuration pertaining to TAC
	TLV, it MUST clear the session setup back off delay associated with		TLV, it MUST clear the session setup back off delay associated with
	the session to re-attempt the session establishment. A LSR detects		the session to re-attempt the session establishment. A LSR detects
	configuration change on the other LSR with the receipt of tLDP Hello		configuration change on the other LSR with the receipt of tLDP Hello
	message that has a higher configuration sequence number than the		message that has a higher configuration sequence number than the
	earlier tLDP Hello message.		earlier tLDP Hello message.
	When the initiating LSR playing the active role in LDP session		When the initiating LSR playing the active role in LDP session
	establishment receives a 'Session Rejected/Targeted Application		establishment receives a 'Session Rejected/Targeted Application
	Capability Mis-Match' Notification message, either it MUST close the		Capability Mis-Match' Notification message, either it MUST close the
	session and tear down the corresponding tLDP adjacency or it MUST set		session and tear down the corresponding tLDP adjacency or it MUST set
	its session setup retry interval to a maximum value, as such 0xffff.		its session setup retry interval to a maximum value, as such 0xffff.
	If the initiating LSR decides to tear down the associated tLDP		If the initiating LSR decides to tear down the associated tLDP
	adjacency, the session is closed on the initiating as well as the		adjacency, the session is closed on the initiating as well as the
	responding LSR. It MAY also take appropriate actions. For instance,		responding LSR. It MAY also take appropriate actions. For instance,
	if an automatic session intended to support the Remote LFA		if an automatic session intended to support the Remote LFA
	application is rejected by the responding LSR, the initiating LSR may		application is rejected by the responding LSR, the initiating LSR may
	inform the IGP to calculate another PQ node [RFC7490] for the route		inform the IGP to calculate another PQ node [RFC7490] for the route
	or set of routes. More specific actions are a local matter and		or set of routes. More specific actions are a local matter and
	outside the scope of this document.		outside the scope of this document.
	If the initiating LSR sets the session setup retry interval to		If the initiating LSR sets the session setup retry interval to
	maximum, the session MAY stay in a non-existent state. When this LSR		maximum, the session MAY stay in a non-existent state. When this LSR
	detects a change in the responding LSR configuration or its own		detects a change in the responding LSR configuration or its own
	configuration pertaining to TAC TLV, it MUST clear the session setup		configuration pertaining to TAC TLV, it MUST clear the session setup
	back off delay associated with the session in order to re-attempt the		back off delay associated with the session in order to re-attempt the
	session establishment.		session establishment.
	After a tLDP session has been established with TAC capability, the		After a tLDP session has been established with TAC capability, the
	initiating and responding LSR MUST distribute FEC-label bindings for		initiating and responding LSR MUST distribute FEC-label bindings for
	the negotiated applications only. For instance, if the tLDP session		the negotiated applications only. For instance, if the tLDP session
	is established for BGP auto discovered pseudowire, only FEC 129 label		is established for BGP auto discovered pseudowire, only FEC 129 label
	bindings MUST be distributed over the session. Similarly, a LSR		bindings MUST be distributed over the session. Similarly, a LSR
	operating in downstream on demand mode MUST request FEC-label		operating in downstream on demand mode MUST request FEC-label
	bindings for the negotiated applications only.		bindings for the negotiated applications only.
	If the Targeted Application Capability and Dynamic Capability,		If the Targeted Application Capability and Dynamic Capability,
	described in [RFC5561], are negotiated during session initialization,		described in [RFC5561], are negotiated during session initialization,
	TAC MAY be re-negotiated after session establishment by sending an		TAC MAY be re-negotiated after session establishment by sending an
	updated TAC TLV in LDP Capability message. The updated TAC TLV		updated TAC TLV in LDP Capability message. The updated TAC TLV
	carries TA-Ids with incremental update only. The updated TLV MUST		carries TA-Ids with incremental update only. The updated TLV MUST
	consist of one or more TAEs with E-bit set or E-bit off to advertise		consist of one or more TAEs with E-bit set or E-bit off to advertise
	or withdraw the new and old application respectively. This may lead		or withdraw the new and old application respectively. This may lead
	to advertisements or withdrawals of certain types of FEC-Label		to advertisements or withdrawals of certain types of FEC-Label
	bindings over the session or tear down of the tLDP adjacency and		bindings over the session or tear down of the tLDP adjacency and
	subsequently the session.		subsequently the session.
	The Targeted Application Capability is advertised on tLDP session		The Targeted Application Capability is advertised on tLDP session
	only. If the tLDP session changes to link session, a LSR SHOULD		only. If the tLDP session changes to link session, a LSR SHOULD
	withdraw it with S bit set to 0. Similarly, if the link session		withdraw it with S bit set to 0. Similarly, if the link session
	changes to tLDP, a LSR SHOULD advertise it via the Capability		changes to tLDP, a LSR SHOULD advertise it via the Capability
	message. If the capability negotiation fails, this may lead to		message. If the capability negotiation fails, this may lead to
	destruction of the tLDP session.		destruction of the tLDP session.
	By default, LSR SHOULD accept tLDP hellos in order to then accept or		By default, LSR SHOULD accept tLDP hellos in order to then accept or
	reject the tLDP session based on the application information.		reject the tLDP session based on the application information.
	In addition, LSR SHOULD allow the configuration of any TA-Id in order		In addition, LSR SHOULD allow the configuration of any TA-Id in order
	to facilitate private TA-Id's usage by a network operator.		to facilitate private TA-Id's usage by a network operator.
	2.3 LDP message procedures		2.3. LDP message procedures
	2.3.1 Initialization message		2.3.1. Initialization message
	1. The S-bit of the Targeted Application Capability TLV MUST be		1. The S-bit of the Targeted Application Capability TLV MUST be
	set to 1 to advertise Targeted Application Capability and		set to 1 to advertise Targeted Application Capability and
	SHOULD be ignored on the receipt as defined in [RFC5561]		SHOULD be ignored on the receipt as defined in [RFC5561]
	2. The E-bit of the Targeted Application Element MUST be set to 1 to		2. The E-bit of the Targeted Application Element MUST be set to 1 to
	enable Targeted application and SHOULD be ignored on the receipt.		enable Targeted application and SHOULD be ignored on the receipt.
	3. An LSR MAY add State Control Capability by mapping Targeted		3. An LSR MAY add State Control Capability by mapping Targeted
	Application Element to State Advertisement Control (SAC) Elements		Application Element to State Advertisement Control (SAC) Elements
	as defined in Section 4.		as defined in Section 4.
	2.3.2 Capability message		2.3.2. Capability message
	The initiating or responding LSR may re-negotiate the TAC after local		The initiating or responding LSR may re-negotiate the TAC after local
	configuration change with the Capability message.		configuration change with the Capability message.
	1. The S-bit of TAC is set to 1 or 0 to advertise or withdraw it.		1. The S-bit of TAC is set to 1 or 0 to advertise or withdraw it.
	2. After configuration change, If there is no common TAE between		2. After configuration change, If there is no common TAE between
	its new TAE list and peers TAE list, the LSR MUST send a		its new TAE list and peers TAE list, the LSR MUST send a
	'Session Rejected/Targeted Application Capability Mis-Match'		'Session Rejected/Targeted Application Capability Mis-Match'
	Notification message and close the session.		Notification message and close the session.
	3. If there is a common TAE, a LSR MAY also update SAC Capability		3. If there is a common TAE, a LSR MAY also update SAC Capability
	based on updated TAC as described in section 4 and send the		based on updated TAC as described in section 4 and send the
	updated TAC and SAC capabilities in a Capability message to		updated TAC and SAC capabilities in a Capability message to
	the peer.		the peer.
	4. A receiving LSR processes the Capability message with TAC TLV.		4. A receiving LSR processes the Capability message with TAC TLV.
	If the S-bit is set to 0, the TAC is disabled for the session.		If the S-bit is set to 0, the TAC is disabled for the session.
	5. If the S-bit is set to 1, a LSR process a list of TAEs from		5. If the S-bit is set to 1, a LSR process a list of TAEs from
	TACs capability data with E-bit set to 1 or 0 to update the		TACs capability data with E-bit set to 1 or 0 to update the
	peer's TAE.		peer's TAE.
	3. Targeted Application FEC Advertisement Procedures		3. Targeted Application FEC Advertisement Procedures
	The targeted LDP application MUST be mapped to LDP FEC element types		The targeted LDP application MUST be mapped to LDP FEC element types
	as follows to advertise only necessary LDP FEC-Label bindings over		as follows to advertise only necessary LDP FEC-Label bindings over
	the tLDP session.		the tLDP session.
	Targeted Application Description FEC mappings		Targeted Application Description FEC mappings
	+----------------------+------------------------+------------------+		+----------------------+------------------------+------------------+
	|LDPv4 Tunneling | LDP IPv4 over RSVP-TE | IPv4 prefix |		|LDPv4 Tunneling | LDP IPv4 over RSVP-TE | IPv4 prefix |
	| | or other MPLS tunnel | |		| | or other MPLS tunnel | |
	+----------------------+------------------------+------------------+		+----------------------+------------------------+------------------+
	skipping to change at page 10, line 49		skipping to change at page 10, line 12
	| | | |		| | | |
	|IPv4 intra-area FECs | IPv4 intra-area FECs | IPv4 prefix |		|IPv4 intra-area FECs | IPv4 intra-area FECs | IPv4 prefix |
	+----------------------+------------------------+------------------+		+----------------------+------------------------+------------------+
	| | | |		| | | |
	|IPv6 intra-area FECs | IPv6 intra-area FECs | IPv6 prefix |		|IPv6 intra-area FECs | IPv6 intra-area FECs | IPv6 prefix |
	+----------------------+------------------------+------------------+		+----------------------+------------------------+------------------+
	Intra-area FECs : FECs that are on the shortest path tree and not		Intra-area FECs : FECs that are on the shortest path tree and not
	leafs of the shortest path tree.		leafs of the shortest path tree.
	4. Interaction of Targeted Application Capabilities and State		4. Interaction of Targeted Application Capabilities and State
	Advertisement Control Capabilities		Advertisement Control Capabilities
	As described in this document, the set of TAEs negotiated between two		As described in this document, the set of TAEs negotiated between two
	LDP peers advertising TAC represents the willingness of both peers to		LDP peers advertising TAC represents the willingness of both peers to
	advertise state information for a set of applications. The set of		advertise state information for a set of applications. The set of
	applications negotiated by the TAC mechanism is symmetric between the		applications negotiated by the TAC mechanism is symmetric between the
	two LDP peers. In the absence of further mechanisms, two LDP peers		two LDP peers. In the absence of further mechanisms, two LDP peers
	will both advertise state information for the same set of		will both advertise state information for the same set of
	applications.		applications.
	As described in [RFC7473], State Advertisement Control(SAC) TLV can		As described in [RFC7473], State Advertisement Control(SAC) TLV can
	be used by an LDP speaker to communicate its interest or disinterest		be used by an LDP speaker to communicate its interest or disinterest
	in receiving state information from a given peer for a particular		in receiving state information from a given peer for a particular
	application. Two LDP peers can use the SAC mechanism to create		application. Two LDP peers can use the SAC mechanism to create
	asymmetric advertisement of state information between the two peers.		asymmetric advertisement of state information between the two peers.
	The TAC negotiation facilitates the awareness of targeted		The TAC negotiation facilitates the awareness of targeted
	applications to both the peers. It enables them to advertise only		applications to both the peers. It enables them to advertise only
	necessary LDP FEC-label bindings corresponding to negotiated		necessary LDP FEC-label bindings corresponding to negotiated
	applications. With the SAC, the responding LSR is not aware of		applications. With the SAC, the responding LSR is not aware of
	targeted applications. Thus it may be unable to communicate its		targeted applications. Thus it may be unable to communicate its
	interest or disinterest to receive state information from the peer.		interest or disinterest to receive state information from the peer.
	Therefore, when the responding LSR is not aware of targeted		Therefore, when the responding LSR is not aware of targeted
	applications such a remote LFA and BGP auto discovered pseudowires,		applications such a remote LFA and BGP auto discovered pseudowires,
	TAC mechanism should be used and when the responding LSR is aware		TAC mechanism should be used and when the responding LSR is aware
	(with appropriate configuration) of targeted applications such as FEC		(with appropriate configuration) of targeted applications such as FEC
	128 pseudowire, SAC mechanism should be used. Also after TAC		128 pseudowire, SAC mechanism should be used. Also after TAC
	mechanism makes the responding LSR aware of targeted application, the		mechanism makes the responding LSR aware of targeted application, the
	SAC mechanism may be used to communicate its disinterest in receiving		SAC mechanism may be used to communicate its disinterest in receiving
	state information from the peer for a particular negotiated		state information from the peer for a particular negotiated
	application, creating asymmetric advertisements.		application, creating asymmetric advertisements.
	Thus, the TAC mechanism enables two LDP peers to symmetrically		Thus, the TAC mechanism enables two LDP peers to symmetrically
	advertise state information for negotiated targeted applications.		advertise state information for negotiated targeted applications.
	Further, the SAC mechanism enables both of them to asymmetrically		Further, the SAC mechanism enables both of them to asymmetrically
	disable receipt of state information for some of the already		disable receipt of state information for some of the already
	negotiated targeted applications. Collectively, both TAC and SAC		negotiated targeted applications. Collectively, both TAC and SAC
	mechanisms can be used to control the FEC-label bindings that are		mechanisms can be used to control the FEC-label bindings that are
	advertised over the tLDP session. For instance, suppose the		advertised over the tLDP session. For instance, suppose the
	initiating LSR establishes a tLDP session to the responding LSR for		initiating LSR establishes a tLDP session to the responding LSR for
	Remote LFA and FEC 129 PW targeted applications with TAC. So each LSR		Remote LFA and FEC 129 PW targeted applications with TAC. So each
	advertises the corresponding FEC-Label bindings. Further, suppose		LSR advertises the corresponding FEC-Label bindings. Further,
	the initiating LSR is not the PQ node for responding LSRs Remote LFA		suppose the initiating LSR is not the PQ node for responding LSRs
	IGP calculations. In such a case, the responding LSR may use the SAC		Remote LFA IGP calculations. In such a case, the responding LSR may
	mechanism to convey its disinterest in receiving state information		use the SAC mechanism to convey its disinterest in receiving state
	for Remote LFA targeted LDP application.		information for Remote LFA targeted LDP application.
	For a given tLDP session, the TAC mechanism can be used without the		For a given tLDP session, the TAC mechanism can be used without the
	SAC mechanism, and the SAC mechanism can be used without the TAC		SAC mechanism, and the SAC mechanism can be used without the TAC
	mechanism. It is useful to discuss the behavior when TAC and SAC		mechanism. It is useful to discuss the behavior when TAC and SAC
	mechanisms are used on the same tLDP session. The TAC mechanism MUST		mechanisms are used on the same tLDP session. The TAC mechanism MUST
	take precedence over the SAC mechanism with respect to enabling		take precedence over the SAC mechanism with respect to enabling
	applications for which state information will be advertised. For a		applications for which state information will be advertised. For a
	tLDP session using the TAC mechanism, the LDP peers MUST NOT		tLDP session using the TAC mechanism, the LDP peers MUST NOT
	advertise state information for an application that has not been		advertise state information for an application that has not been
	negotiated in the most recent TAE list (referred to as an un-		negotiated in the most recent TAE list (referred to as an un-
	negotiated application). This is true even if one of the peers		negotiated application). This is true even if one of the peers
	announces its interest in receiving state information that		announces its interest in receiving state information that
	corresponds to the un-negotiated application by sending a SAC TLV.		corresponds to the un-negotiated application by sending a SAC TLV.
	In other words, when TAC is being used, SAC cannot and should not		In other words, when TAC is being used, SAC cannot and should not
	enable state information advertisement for applications that have not		enable state information advertisement for applications that have not
	been enabled by TAC.		been enabled by TAC.
	On the other hand, the SAC mechanism MUST take precedence over the		On the other hand, the SAC mechanism MUST take precedence over the
	TAC mechanism with respect to disabling state information		TAC mechanism with respect to disabling state information
	advertisements. If an LDP speaker has announced its disinterest in		advertisements. If an LDP speaker has announced its disinterest in
	receiving state information for a given application to a given peer		receiving state information for a given application to a given peer
	using the SAC mechanism, its peer MUST NOT send state information for		using the SAC mechanism, its peer MUST NOT send state information for
	that application, even if the two peers have negotiated that the		that application, even if the two peers have negotiated that the
	corresponding application via the TAC mechanism.		corresponding application via the TAC mechanism.
	For the purposes of determining the correspondence between targeted		For the purposes of determining the correspondence between targeted
	applications defined in this document and application state as		applications defined in this document and application state as
	defined in [RFC7473] an LSR MUST use the following mappings:		defined in [RFC7473] an LSR MUST use the following mappings:
	LDPv4 Tunneling - IPv4 Prefix-LSPs		LDPv4 Tunneling - IPv4 Prefix-LSPs
	skipping to change at page 12, line 43		skipping to change at page 12, line 8
	LDP FEC 128 PW - FEC128 P2P-PW		LDP FEC 128 PW - FEC128 P2P-PW
	LDP FEC 129 PW - FEC129 P2P-PW		LDP FEC 129 PW - FEC129 P2P-PW
	An LSR MUST map Targeted Application to LDP capability as follows:		An LSR MUST map Targeted Application to LDP capability as follows:
	mLDP Tunneling - P2MP Capability, MP2MP Capability		mLDP Tunneling - P2MP Capability, MP2MP Capability
	and HSMP LSP Capability TLV		and HSMP LSP Capability TLV
	mLDP node protection - P2MP Capability, MP2MP Capability		mLDP node protection - P2MP Capability, MP2MP Capability
	and HSMP LSP Capability TLV		and HSMP LSP Capability TLV
	5. Use cases		5. Use cases
	5.1 Remote LFA Automatic Targeted session		5.1. Remote LFA Automatic Targeted session
	The LSR determines that it needs to form an automatic tLDP session to		The LSR determines that it needs to form an automatic tLDP session to
	remote LSR based on IGP calculation as described in [RFC7490] or some		remote LSR based on IGP calculation as described in [RFC7490] or some
	other mechanism, which is outside the scope of this document. The LSR		other mechanism, which is outside the scope of this document. The
	forms the tLDP adjacency and constructs an Initialization message		LSR forms the tLDP adjacency and constructs an Initialization message
	with TAC TLV with TAE as Remote LFA during session establishment. The		with TAC TLV with TAE as Remote LFA during session establishment.
	receiver LSR processes the LDP Initialization message and verifies		The receiver LSR processes the LDP Initialization message and
	whether it is configured to accept a Remote LFA tLDP session. If it		verifies whether it is configured to accept a Remote LFA tLDP
	is, it may further verify that establishing such a session does not		session. If it is, it may further verify that establishing such a
	exceed the configured limit for Remote LFA sessions. If all these		session does not exceed the configured limit for Remote LFA sessions.
	conditions are met, the receiver LSR may respond back with an		If all these conditions are met, the receiver LSR may respond back
	Initialization message with TAC corresponding to Remote LFA, and		with an Initialization message with TAC corresponding to Remote LFA,
	subsequently the session may be established.		and subsequently the session may be established.
	After the session has been established with TAC capability, the		After the session has been established with TAC capability, the
	sender and receiver LSR distribute IPv4 or IPv6 FEC label bindings		sender and receiver LSR distribute IPv4 or IPv6 FEC label bindings
	over the session. Further, the receiver LSR may determine that it		over the session. Further, the receiver LSR may determine that it
	does not need these FEC label bindings. So it may disable the receipt		does not need these FEC label bindings. So it may disable the
	of these FEC label bindings by mapping targeted application element		receipt of these FEC label bindings by mapping targeted application
	to state control capability as described in section 4.		element to state control capability as described in section 4.
	5.2 FEC 129 Auto Discovery Targeted session		5.2. FEC 129 Auto Discovery Targeted session
	BGP auto discovery may determine whether the LSR needs to initiate an		BGP auto discovery may determine whether the LSR needs to initiate an
	auto-discovery tLDP session with a border LSR. Multiple LSRs may try		auto-discovery tLDP session with a border LSR. Multiple LSRs may try
	to form an auto discovered tLDP session with a border LSR. So, a		to form an auto discovered tLDP session with a border LSR. So, a
	service provider may want to limit the number of auto discovered tLDP		service provider may want to limit the number of auto discovered tLDP
	sessions a border LSR can accept. As described in Section 2, LDP may		sessions a border LSR can accept. As described in Section 2, LDP may
	convey targeted applications with TAC TLV to border LSR. A border LSR		convey targeted applications with TAC TLV to border LSR. A border
	may establish or reject the tLDP session based on local		LSR may establish or reject the tLDP session based on local
	administrative policy. Also, as the receiver LSR becomes aware of		administrative policy. Also, as the receiver LSR becomes aware of
	targeted applications, it can also employ an administrative policy		targeted applications, it can also employ an administrative policy
	for security. For instance, it can employ a policy to accept all		for security. For instance, it can employ a policy to accept all
	auto-discovered session from source-list.		auto-discovered session from source-list.
	Moreover, the sender and receiver LSR must exchange FEC 129 label		Moreover, the sender and receiver LSR must exchange FEC 129 label
	bindings only over the tLDP session.		bindings only over the tLDP session.
	5.3 LDP over RSVP and Remote LFA targeted session		5.3. LDP over RSVP and Remote LFA targeted session
	A LSR may want to establish a tLDP session to a remote LSR for LDP		A LSR may want to establish a tLDP session to a remote LSR for LDP
	over RSVP tunneling and Remote LFA applications. The sender LSR may		over RSVP tunneling and Remote LFA applications. The sender LSR may
	add both these applications as a unique Targeted Application Element		add both these applications as a unique Targeted Application Element
	in the Targeted Application Capability data of a TAC TLV. The		in the Targeted Application Capability data of a TAC TLV. The
	receiver LSR may have reached a configured limit for accepting Remote		receiver LSR may have reached a configured limit for accepting Remote
	LFA automatic tLDP sessions, but it may have been configured to		LFA automatic tLDP sessions, but it may have been configured to
	accept LDP over RSVP tunneling. In such a case, the tLDP session is		accept LDP over RSVP tunneling. In such a case, the tLDP session is
	formed for both LDP over RSVP and Remote LFA applications as both		formed for both LDP over RSVP and Remote LFA applications as both
	need same FECs - IPv4 or IPv6 or both.		need same FECs - IPv4 or IPv6 or both.
	5.4 mLDP node protection targeted session		5.4. mLDP node protection targeted session
	A merge point LSR may determine that it needs to form automatic tLDP		A merge point LSR may determine that it needs to form automatic tLDP
	session to the upstream point of local repair (PLR) LSR for MP2P and		session to the upstream point of local repair (PLR) LSR for MP2P and
	MP2MP LSP [RFC6388] node protection as described in the [RFC7715].		MP2MP LSP [RFC6388] node protection as described in the [RFC7715].
	The MPT LSR may add a new targeted LDP application - mLDP protection		The MPT LSR may add a new targeted LDP application - mLDP protection
	- as a unique TAE in the Targeted Application Capability Data of a		- as a unique TAE in the Targeted Application Capability Data of a
	TAC TLV and send it in the Initialization message to the PLR. If the		TAC TLV and send it in the Initialization message to the PLR. If the
	PLR is configured for mLDP node protection and establishing this		PLR is configured for mLDP node protection and establishing this
	session does not exceed the limit of either mLDP node protection		session does not exceed the limit of either mLDP node protection
	sessions or automatic tLDP sessions, the PLR may decide to accept		sessions or automatic tLDP sessions, the PLR may decide to accept
	this session. Also, the PLR may respond back with the initialization		this session. Also, the PLR may respond back with the initialization
	message with a TAC TLV that has one of the TAEs as - mLDP protection,		message with a TAC TLV that has one of the TAEs as - mLDP protection,
	and the session proceeds to establishment as per [RFC5036].		and the session proceeds to establishment as per [RFC5036].
	6. Security Considerations		6. Security Considerations
	The Capability procedure described in this document does not		The Capability procedure described in this document does not
	introduce any change to LDP Security Considerations section described		introduce any change to LDP Security Considerations section described
	in [RFC5036].		in [RFC5036].
	As described in [RFC5036], DoS attacks via Extended Hellos, which are		As described in [RFC5036], DoS attacks via Extended Hellos, which are
	required to establish a tLDP session, can be addressed by filtering		required to establish a tLDP session, can be addressed by filtering
	Extended Hellos using access lists that define addresses with which		Extended Hellos using access lists that define addresses with which
	Extended Discovery is permitted. Further, as described in section		Extended Discovery is permitted. Further, as described in section
	5.2 of this document, a LSR can employ a policy to accept all auto-		5.2 of this document, a LSR can employ a policy to accept all auto-
	discovered Extended Hellos from the configured source addresses		discovered Extended Hellos from the configured source addresses list.
	list.
	Also for the two LSRs supporting TAC, the tLDP session is only		Also for the two LSRs supporting TAC, the tLDP session is only
	established after successful negotiation of the TAC. The initiating		established after successful negotiation of the TAC. The initiating
	and receiving LSR MUST only advertise TA-Ids that they support. In		and receiving LSR MUST only advertise TA-Ids that they support. In
	other words, what they are configured for over the tLDP session.		other words, what they are configured for over the tLDP session.
	7. IANA Considerations		7. IANA Considerations
	This document requires the assignment of a new code point for a		This document requires the assignment of a new code point for a
	Capability Parameter TLVs from the IANA managed LDP registry "TLV		Capability Parameter TLVs from the IANA managed LDP registry "TLV
	Type Name Space", corresponding to the advertisement of the Targeted		Type Name Space", corresponding to the advertisement of the Targeted
	Applications capability. IANA is requested to assign the lowest		Applications capability. IANA is requested to assign the lowest
	available value after 0x050B.		available value after 0x050B.
	Value Description Reference		Value Description Reference
	----- -------------------------------- ---------		----- -------------------------------- ---------
	TBD1 Targeted Applications capability [this document]		TBD1 Targeted Applications capability [this document]
	This document requires the assignment of a new code point for a		This document requires the assignment of a new code point for a
	status code from the IANA managed registry "STATUS CODE NAME SPACE"		status code from the IANA managed registry "STATUS CODE NAME SPACE"
	on the Label Distribution Protocol (LDP) Parameters page,		on the Label Distribution Protocol (LDP) Parameters page,
	corresponding to the notification of session Rejected/Targeted		corresponding to the notification of session Rejected/Targeted
	Application Capability Mis-Match. IANA is requested to assign the		Application Capability Mis-Match. IANA is requested to assign the
	lowest available value after 0x0000004B.		lowest available value after 0x0000004B.
	Value E Description Reference		Value E Description Reference
	----- - -------------------------------- ---------		----- - -------------------------------- ---------
	TBD2 1 Session Rejected/Targeted		TBD2 1 Session Rejected/Targeted
	Application Capability Mis-Match [this document]		Application Capability Mis-Match [this document]
	This document also creates a new name space 'the LDP Targeted		This document also creates a new name space 'the LDP Targeted
	Application Identifier' on the Label Distribution Protocol (LDP)		Application Identifier' on the Label Distribution Protocol (LDP)
	Parameters page, that is to be managed by IANA. The range is 0x0001-		Parameters page, that is to be managed by IANA. The range is 0x0001-
	0xFFFE, with the following values requested in this document.		0xFFFE, with the following values requested in this document.
	Value Description Reference		Value Description Reference
	-------- ------------------------- ---------------		-------- ------------------------- ---------------
	0x0000 Reserved [this document]		0x0000 Reserved [this document]
	0x0001 LDPv4 Tunneling [this document]		0x0001 LDPv4 Tunneling [this document]
	0x0002 LDPv6 Tunneling [this document]		0x0002 LDPv6 Tunneling [this document]
	0x0003 mLDP Tunneling [this document]		0x0003 mLDP Tunneling [this document]
	0x0004 LDPv4 Remote LFA [this document]		0x0004 LDPv4 Remote LFA [this document]
	0x0005 LDPv6 Remote LFA [this document]		0x0005 LDPv6 Remote LFA [this document]
	skipping to change at page 15, line 41		skipping to change at page 15, line 29
	0x000C LDPv4 Intra-area FECs [this document]		0x000C LDPv4 Intra-area FECs [this document]
	0x000D LDPv6 Intra-area FECs [this document]		0x000D LDPv6 Intra-area FECs [this document]
	0x0001 - 0x1FFF Available for assignment		0x0001 - 0x1FFF Available for assignment
	by IETF Review		by IETF Review
	0x2000 - 0F7FF Available for assignment		0x2000 - 0F7FF Available for assignment
	as first come first served		as first come first served
	0xF800 - 0xFBFF Available for private use		0xF800 - 0xFBFF Available for private use
	0xFC00 - 0xFFFE Available for experimental use		0xFC00 - 0xFFFE Available for experimental use
	0xFFFF Reserved [this document]		0xFFFF Reserved [this document]
	8. Acknowledgments		8. Contributing Authors
	The authors wish to thank Nischal Sheth, Hassan Hosseini, Kishore
	Tiruveedhul, Loa Andersson, Eric Rosen, Yakov Rekhter, Thomas
	Beckhaus, Tarek Saad, Lizhong Jin and Bruno Decraene for doing the
	detailed review. Thanks to Manish Gupta and Martin Ehlers for their
	input to this work and many helpful suggestions.
	9. Contributing Authors
	Chris Bowers		Chris Bowers
	Juniper Networks		Juniper Networks
	1133 Innovation Way		1133 Innovation Way
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	USA		USA
	EMail: cbowers@juniper.net		EMail: cbowers@juniper.net
	Zhenbin Li		Zhenbin Li
	Huawei		Huawei
	Bld No.156 Beiqing Rd		Bld No.156 Beiqing Rd
	Beijing 100095		Beijing 100095
	China		China
	Email: lizhenbin@huawei.com		Email: lizhenbin@huawei.com
			9. Acknowledgments
			The authors wish to thank Nischal Sheth, Hassan Hosseini, Kishore
			Tiruveedhul, Loa Andersson, Eric Rosen, Yakov Rekhter, Thomas
			Beckhaus, Tarek Saad, Lizhong Jin and Bruno Decraene for doing the
			detailed review. Thanks to Manish Gupta and Martin Ehlers for their
			input to this work and many helpful suggestions.
	10. References		10. References
	10.1 Normative References		10.1. Normative References
	[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,		[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
	"LDP Specification", RFC 5036, October 2007,		"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
	<http://www.rfc-editor.org/info/rfc5036>.		October 2007, <http://www.rfc-editor.org/info/rfc5036>.
	[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.		[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
	Le Roux, "LDP Capabilities", RFC 5561, July 2009,		Le Roux, "LDP Capabilities", RFC 5561,
			DOI 10.17487/RFC5561, July 2009,
	<http://www.rfc-editor.org/info/rfc5561>.		<http://www.rfc-editor.org/info/rfc5561>.
	[RFC7473] Kamran Raza, Sami Boutros, "Controlling State		[RFC7473] Kamran Raza, Sami Boutros, "Controlling State
	Advertisements of Non-negotiated LDP Applications", RFC		Advertisements of Non-negotiated LDP Applications",
	7473, March 2015, <http://www.rfc-		RFC 7473, March 2015,
	editor.org/info/rfc7473>.		<http://www.rfc-editor.org/info/rfc7473>.
	[RFC7715] IJ. Wijnands, E. Rosen, K. Raza, J. Tantsura, A. Atlas, Q.		[RFC7715] Wijnands, IJ., Ed., Raza, K., Atlas, A., Tantsura, J., and
	Zhao, "mLDP Node Protection", RFC 7715, January 2016,		Q. Zhao, "Multipoint LDP (mLDP) Node Protection",
			RFC 7715, DOI 10.17487/RFC7715, January 2016,
	<http://www.rfc-editor.org/info/rfc7715>.		<http://www.rfc-editor.org/info/rfc7715>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997,		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	Key Words", BCP 14, RFC8174, May 2017, <http://www.rfc-		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	editor.org/info/rfc8174>.		May 2017, <http://www.rfc-editor.org/info/rfc8174>.
	10.2 Informative References		10.2. Informative References
	[RFC7490] S. Bryant, C. Filsfils, S. Previdi, M. Shand, N. So,		[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
	"Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",		So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
	April 2015.		April 2015, <http://www.rfc-editor.org/info/rfc7490>.
	[RFC6074] E. Rosen, B. Davie, V. Radoaca, and W. Luo, "Provisioning,		[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
	Auto-Discovery, and Signaling in Layer 2 Virtual Private		"Provisioning, Auto-Discovery, and Signaling in Layer 2
	Networks (L2VPNs)", January 2011.		Virtual Private Networks (L2VPNs)", January 2011.
	[RFC6388] IJ. Wijnands, I. Minei, K. Kompella, B. Thomas, "Label		[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
	Distribution Protocol Extensions for Point-to-Multipoint		"Label Distribution Protocol Extensions for Point-to-
	and Multipoint-to-Multipoint Label Switched Paths",		Multipoint and Multipoint-to-Multipoint Label Switched
	November 2011.		Paths", November 2011.
	Authors' Addresses		Authors' Addresses
	Santosh Esale		Santosh Esale
	Juniper Networks		Juniper Networks
	1133 Innovation Way		1133 Innovation Way
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	USA		USA
	EMail: sesale@juniper.net
	Raveendra Torvi		Email: sesale@juniper.net
	Juniper Networks
	10 Technology Park Drive
	Westford, MA 01886
	USA
	EMail: rtorvi@juniper.net
	Luay Jalil		Raveendra Torvi
	Verizon		Juniper Networks
	1201 E Arapaho Rd		10 Technology Park Drive
	Richardson, TX 75081		Westford, MA 01886
	USA		USA
	Email: luay.jalil@verizon.com
	Uma Chunduri		Email: rtorvi@juniper.net
	Huawei
	2330 Central Expy
	Santa Clara, CA 95050
	USA
	Email: uma.chunduri@huawei.com
	Kamran Raza		Luay Jalil
	Cisco Systems, Inc.		Verizon
	2000 Innovation Drive		1201 E Arapaho Rd
	Ottawa, ON K2K-3E8		Richardson, TX 75081
	Canada		USA
	E-mail: skraza@cisco.com
			Email: luay.jalil@verizon.com
			Uma Chunduri
			Huawei
			2330 Central Expy
			Santa Clara, CA 95050
			USA
			Email: uma.chunduri@huawei.com
			Kamran Raza
			Cisco Systems, Inc.
			2000 Innovation Drive
			Ottawa, ON K2K-3E8
			Canada
			Email: skraza@cisco.com
End of changes. 123 change blocks.
	258 lines changed or deleted		249 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/