draft-ietf-idr-ls-distribution-11.txt		draft-ietf-idr-ls-distribution-12.txt
	Inter-Domain Routing H. Gredler, Ed.		Inter-Domain Routing H. Gredler, Ed.
	Internet-Draft Juniper Networks, Inc.		Internet-Draft Private Contributor
	Intended status: Standards Track J. Medved		Intended status: Standards Track J. Medved
	Expires: December 6, 2015 S. Previdi		Expires: April 6, 2016 S. Previdi
	Cisco Systems, Inc.		Cisco Systems, Inc.
	A. Farrel		A. Farrel
	Juniper Networks, Inc.		Juniper Networks, Inc.
	S. Ray		S. Ray
	June 4, 2015		October 4, 2015
	North-Bound Distribution of Link-State and TE Information using BGP		North-Bound Distribution of Link-State and TE Information using BGP
	draft-ietf-idr-ls-distribution-11		draft-ietf-idr-ls-distribution-12
	Abstract		Abstract
	In a number of environments, a component external to a network is		In a number of environments, a component external to a network is
	called upon to perform computations based on the network topology and		called upon to perform computations based on the network topology and
	current state of the connections within the network, including		current state of the connections within the network, including
	traffic engineering information. This is information typically		traffic engineering information. This is information typically
	distributed by IGP routing protocols within the network.		distributed by IGP routing protocols within the network.
	This document describes a mechanism by which links state and traffic		This document describes a mechanism by which links state and traffic
	skipping to change at page 2, line 10		skipping to change at page 2, line 10
	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 December 6, 2015.		This Internet-Draft will expire on April 6, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 2, line 41		skipping to change at page 2, line 41
	2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 5		2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 5
	2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 6		2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 6
	3. Carrying Link State Information in BGP . . . . . . . . . . . 7		3. Carrying Link State Information in BGP . . . . . . . . . . . 7
	3.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 8		3.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 8
	3.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 12		3.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 12
	3.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 16		3.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 16
	3.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 17		3.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 17
	3.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 19		3.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 19
	3.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 19		3.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 19
	3.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 22		3.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 23
	3.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 27		3.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 28
	3.4. BGP Next Hop Information . . . . . . . . . . . . . . . . 30		3.4. BGP Next Hop Information . . . . . . . . . . . . . . . . 31
	3.5. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 31		3.5. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 32
	3.6. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 31		3.6. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 32
	3.7. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 32		3.7. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 33
	3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 33		3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 34
	4. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 33		4. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 34
	4.1. Example: No Link Aggregation . . . . . . . . . . . . . . 34		4.1. Example: No Link Aggregation . . . . . . . . . . . . . . 35
	4.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 34		4.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 35
	4.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 35		4.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 36
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
	6. Manageability Considerations . . . . . . . . . . . . . . . . 36		5.1. Guidance for Designated Experts . . . . . . . . . . . . . 37
	6.1. Operational Considerations . . . . . . . . . . . . . . . 36		6. Manageability Considerations . . . . . . . . . . . . . . . . 37
	6.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 36		6.1. Operational Considerations . . . . . . . . . . . . . . . 37
	6.1.2. Installation and Initial Setup . . . . . . . . . . . 37		6.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 37
	6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 37		6.1.2. Installation and Initial Setup . . . . . . . . . . . 38
			6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 38
	6.1.4. Requirements on Other Protocols and Functional		6.1.4. Requirements on Other Protocols and Functional
	Components . . . . . . . . . . . . . . . . . . . . . 37		Components . . . . . . . . . . . . . . . . . . . . . 38
	6.1.5. Impact on Network Operation . . . . . . . . . . . . . 37		6.1.5. Impact on Network Operation . . . . . . . . . . . . . 38
	6.1.6. Verifying Correct Operation . . . . . . . . . . . . . 37		6.1.6. Verifying Correct Operation . . . . . . . . . . . . . 38
	6.2. Management Considerations . . . . . . . . . . . . . . . . 37		6.2. Management Considerations . . . . . . . . . . . . . . . . 39
	6.2.1. Management Information . . . . . . . . . . . . . . . 37		6.2.1. Management Information . . . . . . . . . . . . . . . 39
	6.2.2. Fault Management . . . . . . . . . . . . . . . . . . 38		6.2.2. Fault Management . . . . . . . . . . . . . . . . . . 39
	6.2.3. Configuration Management . . . . . . . . . . . . . . 38		6.2.3. Configuration Management . . . . . . . . . . . . . . 39
	6.2.4. Accounting Management . . . . . . . . . . . . . . . . 39		6.2.4. Accounting Management . . . . . . . . . . . . . . . . 40
	6.2.5. Performance Management . . . . . . . . . . . . . . . 39		6.2.5. Performance Management . . . . . . . . . . . . . . . 40
	6.2.6. Security Management . . . . . . . . . . . . . . . . . 39		6.2.6. Security Management . . . . . . . . . . . . . . . . . 40
	7. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 39		7. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 40
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 41		8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 43
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
	11.1. Normative References . . . . . . . . . . . . . . . . . . 42		11.1. Normative References . . . . . . . . . . . . . . . . . . 43
	11.2. Informative References . . . . . . . . . . . . . . . . . 43		11.2. Informative References . . . . . . . . . . . . . . . . . 45
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
	1. Introduction		1. Introduction
	The contents of a Link State Database (LSDB) or a Traffic Engineering		The contents of a Link State Database (LSDB) or a Traffic Engineering
	Database (TED) has the scope of an IGP area. Some applications, such		Database (TED) has the scope of an IGP area. Some applications, such
	as end-to-end Traffic Engineering (TE), would benefit from visibility		as end-to-end Traffic Engineering (TE), would benefit from visibility
	outside one area or Autonomous System (AS) in order to make better		outside one area or Autonomous System (AS) in order to make better
	decisions.		decisions.
	The IETF has defined the Path Computation Element (PCE) [RFC4655] as		The IETF has defined the Path Computation Element (PCE) [RFC4655] as
	skipping to change at page 8, line 17		skipping to change at page 8, line 17
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Value (variable) //		// Value (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: TLV format		Figure 4: TLV format
	The Length field defines the length of the value portion in octets		The Length field defines the length of the value portion in octets
	(thus a TLV with no value portion would have a length of zero). The		(thus a TLV with no value portion would have a length of zero). The
	TLV is not padded to four-octet alignment. Unrecognized types are		TLV is not padded to four-octet alignment. Unrecognized types MUST
	preserved and propagated. In order to compare NLRIs with unknown		be preserved and propagated. In order to compare NLRIs with unknown
	TLVs all TLVs MUST be ordered in ascending order by TLV Type. If		TLVs all TLVs MUST be ordered in ascending order by TLV Type. If
	there are more TLVs of the same type, then the TLVs MUST be ordered		there are more TLVs of the same type, then the TLVs MUST be ordered
	in ascending order of the TLV value within the TLVs with the same		in ascending order of the TLV value within the TLVs with the same
	type. All TLVs that are not specified as mandatory are considered		type by treating the entire value field an opaque hexadecimal string
	optional.		and comparing leftmost octets first regardless of the length of the
			string. . All TLVs that are not specified as mandatory are
			considered optional.
	3.2. The Link-State NLRI		3.2. The Link-State NLRI
	The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers		The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers
	for carrying opaque information. Each Link-State NLRI describes		for carrying opaque information. Each Link-State NLRI describes
	either a node, a link or a prefix.		either a node, a link or a prefix.
	All non-VPN link, node and prefix information SHALL be encoded using		All non-VPN link, node and prefix information SHALL be encoded using
	AFI 16388 / SAFI 71. VPN link, node and prefix information SHALL be		AFI 16388 / SAFI 71. VPN link, node and prefix information SHALL be
	encoded using AFI 16388 / SAFI TBD.		encoded using AFI 16388 / SAFI TBD.
	In order for two BGP speakers to exchange Link-State NLRI, they MUST		In order for two BGP speakers to exchange Link-State NLRI, they MUST
	use BGP Capabilities Advertisement to ensure that they both are		use BGP Capabilities Advertisement to ensure that they both are
	capable of properly processing such NLRI. This is done as specified		capable of properly processing such NLRI. This is done as specified
	in [RFC4760], by using capability code 1 (multi-protocol BGP), with		in [RFC4760], by using capability code 1 (multi-protocol BGP), with
	an AFI 16388 / SAFI 71 and AFI 16388 / SAFI TBD for the VPN flavor.		AFI 16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI TBD for BGP-LS-
			VPN.
	The format of the Link-State NLRI is shown in the following figure.		The format of the Link-State NLRI is shown in the following figure.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| NLRI Type | Total NLRI Length |		| NLRI Type | Total NLRI Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	// Link-State NLRI (variable) //		// Link-State NLRI (variable) //
	skipping to change at page 9, line 49		skipping to change at page 9, line 49
	| Type | NLRI Type |		| Type | NLRI Type |
	+------+---------------------------+		+------+---------------------------+
	| 1 | Node NLRI |		| 1 | Node NLRI |
	| 2 | Link NLRI |		| 2 | Link NLRI |
	| 3 | IPv4 Topology Prefix NLRI |		| 3 | IPv4 Topology Prefix NLRI |
	| 4 | IPv6 Topology Prefix NLRI |		| 4 | IPv6 Topology Prefix NLRI |
	+------+---------------------------+		+------+---------------------------+
	Table 1: NLRI Types		Table 1: NLRI Types
			Route Distinguishers are defined and discussed in [RFC4364].
	The Node NLRI (NLRI Type = 1) is shown in the following figure.		The Node NLRI (NLRI Type = 1) is shown in the following figure.
	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
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Protocol-ID |		| Protocol-ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Identifier |		| Identifier |
	| (64 bits) |		| (64 bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 11, line 35		skipping to change at page 11, line 35
	| 1 | IS-IS Level 1 |		| 1 | IS-IS Level 1 |
	| 2 | IS-IS Level 2 |		| 2 | IS-IS Level 2 |
	| 3 | OSPFv2 |		| 3 | OSPFv2 |
	| 4 | Direct |		| 4 | Direct |
	| 5 | Static configuration |		| 5 | Static configuration |
	| 6 | OSPFv3 |		| 6 | OSPFv3 |
	+-------------+----------------------------------+		+-------------+----------------------------------+
	Table 2: Protocol Identifiers		Table 2: Protocol Identifiers
	The 'Direct' and 'Static' protocol types SHOULD be used when BGP-LS		The 'Direct' and 'Static configuration' protocol types SHOULD be used
	is sourcing local information. For all information, derived from		when BGP-LS is sourcing local information. For all information,
	other protocols the corresponding protocol-ID MUST be used. If BGP-		derived from other protocols the corresponding protocol-ID MUST be
	LS has got direct access to interface information and wants to		used. If BGP-LS has got direct access to interface information and
	advertise a local link then the protocol-ID 'Direct' SHOULD be used.		wants to advertise a local link then the protocol-ID 'Direct' SHOULD
	For modeling virtual links, like described in Section 4 the protocol-		be used. For modeling virtual links, like described in Section 4 the
	ID 'Static configuration' SHOULD be used.		protocol-ID 'Static configuration' SHOULD be used.
	Both OSPF and IS-IS MAY run multiple routing protocol instances over		Both OSPF and IS-IS MAY run multiple routing protocol instances over
	the same link. See [RFC6822] and [RFC6549]. These instances define		the same link. See [RFC6822] and [RFC6549]. These instances define
	independent "routing universes". The 64-Bit 'Identifier' field is		independent "routing universes". The 64-Bit 'Identifier' field is
	used to identify the "routing universe" where the NLRI belongs. The		used to identify the "routing universe" where the NLRI belongs. The
	NLRIs representing Link-state objects (nodes, links or prefixes) from		NLRIs representing Link-state objects (nodes, links or prefixes) from
	the same routing universe MUST have the same 'Identifier' value.		the same routing universe MUST have the same 'Identifier' value.
	NLRIs with different 'Identifier' values MUST be considered to be		NLRIs with different 'Identifier' values MUST be considered to be
	from different routing universes. Table 3 lists the 'Identifier'		from different routing universes. Table 3 lists the 'Identifier'
	values that are defined as well-known in this draft.		values that are defined as well-known in this draft.
	skipping to change at page 12, line 36		skipping to change at page 12, line 36
	Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more		Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more
	additional auxiliary Router-IDs, mainly for traffic engineering		additional auxiliary Router-IDs, mainly for traffic engineering
	purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE		purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE
	Router-IDs [RFC5305], [RFC6119]. These auxiliary Router-IDs MUST be		Router-IDs [RFC5305], [RFC6119]. These auxiliary Router-IDs MUST be
	included in the link attribute described in Section 3.3.2.		included in the link attribute described in Section 3.3.2.
	It is desirable that the Router-ID assignments inside the Node		It is desirable that the Router-ID assignments inside the Node
	Descriptor are globally unique. However there may be Router-ID		Descriptor are globally unique. However there may be Router-ID
	spaces (e.g. ISO) where no global registry exists, or worse, Router-		spaces (e.g. ISO) where no global registry exists, or worse, Router-
	IDs have been allocated following private-IP RFC 1918 [RFC1918]		IDs have been allocated following private-IP RFC 1918 [RFC1918]
	allocation. We use Autonomous System (AS) Number and BGP-LS		allocation. BGP-LS uses the Autonomous System (AS) Number and BGP-LS
	Identifier (Paragraph 2) in order to disambiguate the Router-IDs, as		Identifier (see Section 3.2.1.4) to disambiguate the Router-IDs, as
	described in Section 3.2.1.1.		described in Section 3.2.1.1.
	3.2.1.1. Globally Unique Node/Link/Prefix Identifiers		3.2.1.1. Globally Unique Node/Link/Prefix Identifiers
	One problem that needs to be addressed is the ability to identify an		One problem that needs to be addressed is the ability to identify an
	IGP node globally (by "global", we mean within the BGP-LS database		IGP node globally (by "global", we mean within the BGP-LS database
	collected by all BGP-LS speakers that talk to each other). This can		collected by all BGP-LS speakers that talk to each other). This can
	be expressed through the following two requirements:		be expressed through the following two requirements:
	(A) The same node MUST NOT be represented by two keys (otherwise one		(A) The same node MUST NOT be represented by two keys (otherwise one
	skipping to change at page 13, line 22		skipping to change at page 13, line 22
	IGP transitions it may happen that two redundant IGPs are in place.		IGP transitions it may happen that two redundant IGPs are in place.
	In Section 3.2.1.4 a set of sub-TLVs is described, which allows		In Section 3.2.1.4 a set of sub-TLVs is described, which allows
	specification of a flexible key for any given Node/Link information		specification of a flexible key for any given Node/Link information
	such that global uniqueness of the NLRI is ensured.		such that global uniqueness of the NLRI is ensured.
	3.2.1.2. Local Node Descriptors		3.2.1.2. Local Node Descriptors
	The Local Node Descriptors TLV contains Node Descriptors for the node		The Local Node Descriptors TLV contains Node Descriptors for the node
	anchoring the local end of the link. This is a mandatory TLV in all		anchoring the local end of the link. This is a mandatory TLV in all
	three types of NLRIs. The length of this TLV is variable. The value		three types of NLRIs (node, link, and prefix). The length of this
	contains one or more Node Descriptor Sub-TLVs defined in		TLV is variable. The value contains one or more Node Descriptor Sub-
	Section 3.2.1.4.		TLVs defined in Section 3.2.1.4.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	// Node Descriptor Sub-TLVs (variable) //		// Node Descriptor Sub-TLVs (variable) //
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 16, line 13		skipping to change at page 16, line 13
	Figure 12: Multi-Topology ID TLV format		Figure 12: Multi-Topology ID TLV format
	where Type is 263, Length is 2*n and n is the number of MT-IDs		where Type is 263, Length is 2*n and n is the number of MT-IDs
	carried in the TLV.		carried in the TLV.
	The MT-ID TLV MAY be present in a Link Descriptor, a Prefix		The MT-ID TLV MAY be present in a Link Descriptor, a Prefix
	Descriptor, or in the BGP-LS attribute of a node NLRI. In a Link or		Descriptor, or in the BGP-LS attribute of a node NLRI. In a Link or
	Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of		Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of
	the topology where the link or the prefix is reachable is allowed.		the topology where the link or the prefix is reachable is allowed.
	In case one wants to advertise multiple topologies for a given Link		In case one wants to advertise multiple topologies for a given Link
	Descriptor or Prefix Descriptor, multiple NRLIs need to be generated		Descriptor or Prefix Descriptor, multiple NLRIs need to be generated
	where each NLRI contains an unique MT-ID. In the BGP-LS attribute of		where each NLRI contains an unique MT-ID. In the BGP-LS attribute of
	a node NLRI, one MT-ID TLV containing the array of MT-IDs of all		a node NLRI, one MT-ID TLV containing the array of MT-IDs of all
	topologies where the node is reachable is allowed.		topologies where the node is reachable is allowed.
	3.2.2. Link Descriptors		3.2.2. Link Descriptors
	The 'Link Descriptor' field is a set of Type/Length/Value (TLV)		The 'Link Descriptor' field is a set of Type/Length/Value (TLV)
	triplets. The format of each TLV is shown in Section 3.1. The 'Link		triplets. The format of each TLV is shown in Section 3.1. The 'Link
	descriptor' TLVs uniquely identify a link among multiple parallel		descriptor' TLVs uniquely identify a link among multiple parallel
	links between a pair of anchor routers. A link described by the Link		links between a pair of anchor routers. A link described by the Link
	skipping to change at page 18, line 23		skipping to change at page 18, line 23
	| | Information | | |		| | Information | | |
	+--------------+-----------------------+----------+-----------------+		+--------------+-----------------------+----------+-----------------+
	Table 6: Prefix Descriptor TLVs		Table 6: Prefix Descriptor TLVs
	3.2.3.1. OSPF Route Type		3.2.3.1. OSPF Route Type
	OSPF Route Type is an optional TLV that MAY be present in Prefix		OSPF Route Type is an optional TLV that MAY be present in Prefix
	NLRIs. It is used to identify the OSPF route-type of the prefix. It		NLRIs. It is used to identify the OSPF route-type of the prefix. It
	is used when an OSPF prefix is advertised in the OSPF domain with		is used when an OSPF prefix is advertised in the OSPF domain with
	multiple route-types. The Route Type TLV allows to discrimination of		multiple route-types. The Route Type TLV allows the discrimination
	these advertisements. The format of the OSPF Route Type TLV is shown		of these advertisements. The format of the OSPF Route Type TLV is
	in the following figure.		shown in the following figure.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Route Type |		| Route Type |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 13: OSPF Route Type TLV Format		Figure 13: OSPF Route Type TLV Format
	skipping to change at page 20, line 35		skipping to change at page 20, line 35
	The Node Flag Bits TLV carries a bit mask describing node attributes.		The Node Flag Bits TLV carries a bit mask describing node attributes.
	The value is a variable length bit array of flags, where each bit		The value is a variable length bit array of flags, where each bit
	represents a node capability.		represents a node capability.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|O|T|E|B| Reserved|		|O|T|E|B|R|V| Rsvd|
	+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+
	Figure 15: Node Flag Bits TLV format		Figure 15: Node Flag Bits TLV format
	The bits are defined as follows:		The bits are defined as follows:
	+----------+-------------------------+-----------+		+-----------------+-------------------------+-----------+
	| Bit | Description | Reference |		| Bit | Description | Reference |
	+----------+-------------------------+-----------+		+-----------------+-------------------------+-----------+
	| 'O' | Overload Bit | [RFC1195] |		| 'O' | Overload Bit | [RFC1195] |
	| 'T' | Attached Bit | [RFC1195] |		| 'T' | Attached Bit | [RFC1195] |
	| 'E' | External Bit | [RFC2328] |		| 'E' | External Bit | [RFC2328] |
	| 'B' | ABR Bit | [RFC2328] |		| 'B' | ABR Bit | [RFC2328] |
	| Reserved | Reserved for future use | |		| 'R' | Router Bit | [RFC5340] |
	+----------+-------------------------+-----------+		| 'V' | V6 Bit | [RFC5340] |
			| Reserved (Rsvd) | Reserved for future use | |
			+-----------------+-------------------------+-----------+
	Table 8: Node Flag Bits Definitions		Table 8: Node Flag Bits Definitions
	3.3.1.2. IS-IS Area Identifier TLV		3.3.1.2. IS-IS Area Identifier TLV
	An IS-IS node can be part of one or more IS-IS areas. Each of these		An IS-IS node can be part of one or more IS-IS areas. Each of these
	area addresses is carried in the IS-IS Area Identifier TLV. If		area addresses is carried in the IS-IS Area Identifier TLV. If
	multiple Area Addresses are present, multiple TLVs are used to encode		multiple Area Addresses are present, multiple TLVs are used to encode
	them. The IS-IS Area Identifier TLV may be present in the BGP-LS		them. The IS-IS Area Identifier TLV may be present in the BGP-LS
	attribute only when advertised in the Link-State Node NLRI.		attribute only when advertised in the Link-State Node NLRI.
	skipping to change at page 23, line 5		skipping to change at page 23, line 28
	attribute with a link NLRI. Each 'Link Attribute' is a Type/Length/		attribute with a link NLRI. Each 'Link Attribute' is a Type/Length/
	Value (TLV) triplet formatted as defined in Section 3.1. The format		Value (TLV) triplet formatted as defined in Section 3.1. The format
	and semantics of the 'value' fields in some 'Link Attribute' TLVs		and semantics of the 'value' fields in some 'Link Attribute' TLVs
	correspond to the format and semantics of value fields in IS-IS		correspond to the format and semantics of value fields in IS-IS
	Extended IS Reachability sub-TLVs, defined in [RFC5305] and		Extended IS Reachability sub-TLVs, defined in [RFC5305] and
	[RFC5307]. Other 'Link Attribute' TLVs are defined in this document.		[RFC5307]. Other 'Link Attribute' TLVs are defined in this document.
	Although the encodings for 'Link Attribute' TLVs were originally		Although the encodings for 'Link Attribute' TLVs were originally
	defined for IS-IS, the TLVs can carry data sourced either by IS-IS or		defined for IS-IS, the TLVs can carry data sourced either by IS-IS or
	OSPF.		OSPF.
	The following 'Link Attribute' TLVs are valid in the LINK_STATE		The following 'Link Attribute' TLVs are valid in the BGP-LS attribute
	attribute:		with a link NLRI:
	+-----------+---------------------+--------------+------------------+		+-----------+---------------------+--------------+------------------+
	| TLV Code | Description | IS-IS TLV | Defined in: |		| TLV Code | Description | IS-IS TLV | Defined in: |
	| Point | | /Sub-TLV | |		| Point | | /Sub-TLV | |
	+-----------+---------------------+--------------+------------------+		+-----------+---------------------+--------------+------------------+
	| 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |		| 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
	| | Local Node | | |		| | Local Node | | |
	| 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |		| 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
	| | Local Node | | |		| | Local Node | | |
	| 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |		| 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
	skipping to change at page 24, line 7		skipping to change at page 24, line 50
	The local/remote IPv4/IPv6 Router-ID TLVs are used to describe		The local/remote IPv4/IPv6 Router-ID TLVs are used to describe
	auxiliary Router-IDs that the IGP might be using, e.g., for TE		auxiliary Router-IDs that the IGP might be using, e.g., for TE
	purposes. All auxiliary Router-IDs of both the local and the remote		purposes. All auxiliary Router-IDs of both the local and the remote
	node MUST be included in the link attribute of each link NLRI. If		node MUST be included in the link attribute of each link NLRI. If
	there are more than one auxiliary Router-ID of a given type, then		there are more than one auxiliary Router-ID of a given type, then
	multiple TLVs are used to encode them.		multiple TLVs are used to encode them.
	3.3.2.2. MPLS Protocol Mask TLV		3.3.2.2. MPLS Protocol Mask TLV
	The MPLS Protocol TLV carries a bit mask describing which MPLS		The MPLS Protocol Mask TLV carries a bit mask describing which MPLS
	signaling protocols are enabled. The length of this TLV is 1. The		signaling protocols are enabled. The length of this TLV is 1. The
	value is a bit array of 8 flags, where each bit represents an MPLS		value is a bit array of 8 flags, where each bit represents an MPLS
	Protocol capability.		Protocol capability.
	Generation of the MPLS Protocol Mask TLV is only valid for		>Generation of the MPLS Protocol Mask TLV is only valid for and
	originators that have local link insight, like for example Protocol-		SHOULD only be used with originators that have local link insight,
	IDs 'Static' or 'Direct' as per Table 2. The 'MPLS Protocol Mask'		like for example the Protocol-IDs 'Static' or 'Direct' as per
	TLV MUST NOT be included in NLRIs with protocol-IDs 'IS-IS L1', 'IS-		Table 2. The 'MPLS Protocol Mask' TLV MUST NOT be included in NLRIs
	IS L2', 'OSPFv2' or 'OSPFv3' as per Table 2.		with the other Protocol-IDs listed in Table 2.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|L|R| Reserved |		|L|R| Reserved |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 19: MPLS Protocol TLV		Figure 19: MPLS Protocol Mask TLV
	The following bits are defined:		The following bits are defined:
	+------------+------------------------------------------+-----------+		+------------+------------------------------------------+-----------+
	| Bit | Description | Reference |		| Bit | Description | Reference |
	+------------+------------------------------------------+-----------+		+------------+------------------------------------------+-----------+
	| 'L' | Label Distribution Protocol (LDP) | [RFC5036] |		| 'L' | Label Distribution Protocol (LDP) | [RFC5036] |
	| 'R' | Extension to RSVP for LSP Tunnels (RSVP- | [RFC3209] |		| 'R' | Extension to RSVP for LSP Tunnels (RSVP- | [RFC3209] |
	| | TE) | |		| | TE) | |
	| 'Reserved' | Reserved for future use | |		| 'Reserved' | Reserved for future use | |
	+------------+------------------------------------------+-----------+		+------------+------------------------------------------+-----------+
	Table 10: MPLS Protocol Mask TLV Codes		Table 10: MPLS Protocol Mask TLV Codes
	3.3.2.3. TE Default Metric TLV		3.3.2.3. TE Default Metric TLV
	The TE Default Metric TLV carries the Traffic engineering metric for		The TE Default Metric TLV carries the Traffic Engineering metric for
	this link. The length of this TLV is fixed at 4 octets. If a source		this link. The length of this TLV is fixed at 4 octets. If a source
	protocol (e.g. IS-IS) does not support a Metric width of 32 bits		protocol uses a Metric width of less than 32 bits then the high order
	then the high order octet MUST be set to zero.		bits of this field MUST be padded with zero.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TE Default Link Metric |		| TE Default Link Metric |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 20: TE Default Metric TLV format		Figure 20: TE Default Metric TLV format
	skipping to change at page 27, line 31		skipping to change at page 28, line 19
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Link Name (variable) //		// Link Name (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 24: Link Name format		Figure 24: Link Name format
	3.3.3. Prefix Attribute TLVs		3.3.3. Prefix Attribute TLVs
	Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set		Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set
	of IGP attributes (such as metric, route tags, etc.) that MUST be		of IGP attributes (such as metric, route tags, etc.) that MUST be
	reflected into the LINK_STATE attribute. This section describes the		reflected into the BGP-LS attribute with a link NLRI. This section
	different attributes related to the IPv4/IPv6 prefixes. Prefix		describes the different attributes related to the IPv4/IPv6 prefixes.
	Attributes TLVs SHOULD be used when advertising NLRI types 3 and 4		Prefix Attributes TLVs SHOULD be used when advertising NLRI types 3
	only. The following attributes TLVs are defined:		and 4 only. The following attributes TLVs are defined:
	+---------------+----------------------+----------+-----------------+		+---------------+----------------------+----------+-----------------+
	| TLV Code | Description | Length | Reference |		| TLV Code | Description | Length | Reference |
	| Point | | | |		| Point | | | |
	+---------------+----------------------+----------+-----------------+		+---------------+----------------------+----------+-----------------+
	| 1152 | IGP Flags | 1 | Section 3.3.3.1 |		| 1152 | IGP Flags | 1 | Section 3.3.3.1 |
	| 1153 | Route Tag | 4*n | Section 3.3.3.2 |		| 1153 | Route Tag | 4*n | Section 3.3.3.2 |
	| 1154 | Extended Tag | 8*n | Section 3.3.3.3 |		| 1154 | Extended Tag | 8*n | Section 3.3.3.3 |
	| 1155 | Prefix Metric | 4 | Section 3.3.3.4 |		| 1155 | Prefix Metric | 4 | Section 3.3.3.4 |
	| 1156 | OSPF Forwarding | 4 | Section 3.3.3.5 |		| 1156 | OSPF Forwarding | 4 | Section 3.3.3.5 |
	skipping to change at page 29, line 29		skipping to change at page 30, line 29
	Length is a multiple of 8.		Length is a multiple of 8.
	The 'Extended Route Tag' field contains one or more Extended Route		The 'Extended Route Tag' field contains one or more Extended Route
	Tags as learned in the IGP topology.		Tags as learned in the IGP topology.
	3.3.3.4. Prefix Metric TLV		3.3.3.4. Prefix Metric TLV
	Prefix Metric TLV is an optional attribute and may only appear once.		Prefix Metric TLV is an optional attribute and may only appear once.
	If present, it carries the metric of the prefix as known in the IGP		If present, it carries the metric of the prefix as known in the IGP
	topology [RFC5305] (and therefore represents the reachability cost to		topology as described in Section 4 of [RFC5305] (and therefore
	the prefix). If not present, it means that the prefix is advertised		represents the reachability cost to the prefix). If not present, it
	without any reachability.		means that the prefix is advertised without any reachability.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Metric |		| Metric |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 28: Prefix Metric TLV Format		Figure 28: Prefix Metric TLV Format
	skipping to change at page 31, line 40		skipping to change at page 32, line 40
	3.6. Router-ID Anchoring Example: ISO Pseudonode		3.6. Router-ID Anchoring Example: ISO Pseudonode
	Encoding of a broadcast LAN in IS-IS provides a good example of how		Encoding of a broadcast LAN in IS-IS provides a good example of how
	Router-IDs are encoded. Consider Figure 31. This represents a		Router-IDs are encoded. Consider Figure 31. This represents a
	Broadcast LAN between a pair of routers. The "real" (=non		Broadcast LAN between a pair of routers. The "real" (=non
	pseudonode) routers have both an IPv4 Router-ID and IS-IS Node-ID.		pseudonode) routers have both an IPv4 Router-ID and IS-IS Node-ID.
	The pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for		The pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for
	the LAN. Two unidirectional links (Node1, Pseudonode 1) and		the LAN. Two unidirectional links (Node1, Pseudonode 1) and
	(Pseudonode1, Node2) are being generated.		(Pseudonode1, Node2) are being generated.
	The link NRLI of (Node1, Pseudonode1) is encoded as follows: the IGP		The link NLRI of (Node1, Pseudonode1) is encoded as follows: the IGP
	Router-ID TLV of the local node descriptor is 6 octets long		Router-ID TLV of the local node descriptor is 6 octets long
	containing ISO-ID of Node1, 1920.0000.2001; the IGP Router-ID TLV of		containing ISO-ID of Node1, 1920.0000.2001; the IGP Router-ID TLV of
	the remote node descriptor is 7 octets long containing the ISO-ID of		the remote node descriptor is 7 octets long containing the ISO-ID of
	Pseudonode1, 1920.0000.2001.02. The BGP-LS attribute of this link		Pseudonode1, 1920.0000.2001.02. The BGP-LS attribute of this link
	contains one local IPv4 Router-ID TLV (TLV type 1028) containing		contains one local IPv4 Router-ID TLV (TLV type 1028) containing
	192.0.2.1, the IPv4 Router-ID of Node1.		192.0.2.1, the IPv4 Router-ID of Node1.
	The link NRLI of (Pseudonode1. Node2) is encoded as follows: the IGP		The link NLRI of (Pseudonode1. Node2) is encoded as follows: the IGP
	Router-ID TLV of the local node descriptor is 7 octets long		Router-ID TLV of the local node descriptor is 7 octets long
	containing the ISO-ID of Pseudonode1, 1920.0000.2001.02; the IGP		containing the ISO-ID of Pseudonode1, 1920.0000.2001.02; the IGP
	Router-ID TLV of the remote node descriptor is 6 octets long		Router-ID TLV of the remote node descriptor is 6 octets long
	containing ISO-ID of Node2, 1920.0000.2002. The BGP-LS attribute of		containing ISO-ID of Node2, 1920.0000.2002. The BGP-LS attribute of
	this link contains one remote IPv4 Router-ID TLV (TLV type 1030)		this link contains one remote IPv4 Router-ID TLV (TLV type 1030)
	containing 192.0.2.2, the IPv4 Router-ID of Node2.		containing 192.0.2.2, the IPv4 Router-ID of Node2.
	+-----------------+ +-----------------+ +-----------------+		+-----------------+ +-----------------+ +-----------------+
	| Node1 | | Pseudonode1 | | Node2 |		| Node1 | | Pseudonode1 | | Node2 |
	|1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00|		|1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00|
	skipping to change at page 32, line 29		skipping to change at page 33, line 29
	Router-IDs and local Interface IPs are encoded. Consider Figure 32.		Router-IDs and local Interface IPs are encoded. Consider Figure 32.
	This represents a Broadcast LAN between a pair of routers. The		This represents a Broadcast LAN between a pair of routers. The
	"real" (=non pseudonode) routers have both an IPv4 Router-ID and an		"real" (=non pseudonode) routers have both an IPv4 Router-ID and an
	Area Identifier. The pseudonode does have an IPv4 Router-ID, an IPv4		Area Identifier. The pseudonode does have an IPv4 Router-ID, an IPv4
	interface Address (for disambiguation) and an OSPF Area. Node1 is		interface Address (for disambiguation) and an OSPF Area. Node1 is
	the DR for the LAN, hence its local IP address 10.1.1.1 is used both		the DR for the LAN, hence its local IP address 10.1.1.1 is used both
	as the Router-ID and Interface IP for the Pseudonode keys. Two		as the Router-ID and Interface IP for the Pseudonode keys. Two
	unidirectional links (Node1, Pseudonode 1) and (Pseudonode1, Node2)		unidirectional links (Node1, Pseudonode 1) and (Pseudonode1, Node2)
	are being generated.		are being generated.
	The link NRLI of (Node1, Pseudonode1) is encoded as follows:		The link NLRI of (Node1, Pseudonode1) is encoded as follows:
	o Local Node Descriptor		o Local Node Descriptor
	TLV #515: IGP Router ID: 11.11.11.11		TLV #515: IGP Router ID: 11.11.11.11
	TLV #514: OSPF Area-ID: ID:0.0.0.0		TLV #514: OSPF Area-ID: ID:0.0.0.0
	o Remote Node Descriptor		o Remote Node Descriptor
	TLV #515: IGP Router ID: 10.1.1.1:10.1.1.1		TLV #515: IGP Router ID: 11.11.11.11:10.1.1.1
	TLV #514: OSPF Area-ID: ID:0.0.0.0		TLV #514: OSPF Area-ID: ID:0.0.0.0
	The link NRLI of (Pseudonode1, Node2) is encoded as follows:		The link NLRI of (Pseudonode1, Node2) is encoded as follows:
	o Local Node Descriptor		o Local Node Descriptor
	TLV #515: IGP Router ID: 10.1.1.1:10.1.1.1		TLV #515: IGP Router ID: 11.11.11.11:10.1.1.1
	TLV #514: OSPF Area-ID: ID:0.0.0.0		TLV #514: OSPF Area-ID: ID:0.0.0.0
	o Remote Node Descriptor		o Remote Node Descriptor
	TLV #515: IGP Router ID: 33.33.33.34		TLV #515: IGP Router ID: 33.33.33.34
	TLV #514: OSPF Area-ID: ID:0.0.0.0		TLV #514: OSPF Area-ID: ID:0.0.0.0
	+-----------------+ +-----------------+ +-----------------+		+-----------------+ +-----------------+ +-----------------+
	| Node1 | | Pseudonode1 | | Node2 |		| Node1 | | Pseudonode1 | | Node2 |
	skipping to change at page 34, line 14		skipping to change at page 35, line 14
	specific links or aggregated links is an operator's policy choice.		specific links or aggregated links is an operator's policy choice.
	To highlight the varying levels of exposure, the following deployment		To highlight the varying levels of exposure, the following deployment
	examples are discussed.		examples are discussed.
	4.1. Example: No Link Aggregation		4.1. Example: No Link Aggregation
	Consider Figure 33. Both AS1 and AS2 operators want to protect their		Consider Figure 33. Both AS1 and AS2 operators want to protect their
	inter-AS {R1,R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants to		inter-AS {R1,R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants to
	compute its link-protection LSP to R3 it needs to "see" an alternate		compute its link-protection LSP to R3 it needs to "see" an alternate
	path to R3. Therefore the AS2 operator exposes its topology. All		path to R3. Therefore the AS2 operator exposes its topology. All
	BGP TE enabled routers in AS1 "see" the full topology of AS and		BGP TE enabled routers in AS1 "see" the full topology of AS2 and
	therefore can compute a backup path. Note that the decision if the		therefore can compute a backup path. Note that the decision if the
	direct link between {R3, R4} or the {R4, R5, R3) path is used is made		direct link between {R3, R4} or the {R4, R5, R3) path is used is made
	by the computing router.		by the computing router.
	AS1 : AS2		AS1 : AS2
	:		:
	R1-------R3		R1-------R3
	| : | \		| : | \
	| : | R5		| : | R5
	| : | /		| : | /
	skipping to change at page 36, line 27		skipping to change at page 37, line 27
	[RFC5226]).		[RFC5226]).
	This document requests creation of a new registry for node anchor,		This document requests creation of a new registry for node anchor,
	link descriptor and link attribute TLVs. Values 0-255 are reserved.		link descriptor and link attribute TLVs. Values 0-255 are reserved.
	Values 256-65535 will be used for code points. The registry will be		Values 256-65535 will be used for code points. The registry will be
	initialized as shown in Table 13. Allocations within the registry		initialized as shown in Table 13. Allocations within the registry
	will require documentation of the proposed use of the allocated value		will require documentation of the proposed use of the allocated value
	(=Specification required) and approval by the Designated Expert		(=Specification required) and approval by the Designated Expert
	assigned by the IESG (see [RFC5226]).		assigned by the IESG (see [RFC5226]).
	Note to RFC Editor: this section may be removed on publication as an		5.1. Guidance for Designated Experts
	RFC.
			In all cases of review by Designated Expert (DE) described here, the
			DE is expected to ascertain the existence of suitable documentation
			(a specification) as described in [RFC5226], and to verify the
			permanent and publically ready availability of the document. The DE
			is also expected to check the clarity of purpose and use of the
			requested code points. Lastly, the DE must verify that any
			specification produced in the IETF that requests one of these code
			points has been made available for review by the IDR working group,
			and that any specification produced outside the IETF does not
			conflict with work that is active or already published within the
			IETF.
	6. Manageability Considerations		6. Manageability Considerations
	This section is structured as recommended in [RFC5706].		This section is structured as recommended in [RFC5706].
	6.1. Operational Considerations		6.1. Operational Considerations
	6.1.1. Operations		6.1.1. Operations
	Existing BGP operational procedures apply. No new operation		Existing BGP operational procedures apply. No new operation
	skipping to change at page 37, line 49		skipping to change at page 39, line 9
	Existing BGP procedures apply. In addition, an implementation SHOULD		Existing BGP procedures apply. In addition, an implementation SHOULD
	allow an operator to:		allow an operator to:
	o List neighbors with whom the Speaker is exchanging Link-State		o List neighbors with whom the Speaker is exchanging Link-State
	NLRIs		NLRIs
	6.2. Management Considerations		6.2. Management Considerations
	6.2.1. Management Information		6.2.1. Management Information
	This document does not mandate any new MIB information or NETCONF/		The IDR working group has documented and continues to document parts
	YANG models.		of the Management Information Base and YANG models for managing and
			monitoring BGP speakers and the sessions between them. It is
			currently believed that the BGP session running BGP-LS is not
			substantially different from any other BGP session and can be managed
			using the same data models.
	6.2.2. Fault Management		6.2.2. Fault Management
	If an implementation of BGP-LS detects a malformed attribute, then it		If an implementation of BGP-LS detects a malformed attribute, then it
	MUST use the 'Attribute Discard' action as per		MUST use the 'Attribute Discard' action as per [RFC7606] Section 2.
	[I-D.ietf-idr-error-handling] Section 2.
	An implementation of BGP-LS MUST perform the following syntactic		An implementation of BGP-LS MUST perform the following syntactic
	checks for determining if a message is malformed.		checks for determining if a message is malformed.
	o Does the sum of all TLVs found in the BGP LS attribute correspond		o Does the sum of all TLVs found in the BGP LS attribute correspond
	to the BGP LS path attribute length ?		to the BGP LS path attribute length?
	o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute		o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute
	correspond to the BGP MP_REACH_NLRI length ?		correspond to the BGP MP_REACH_NLRI length?
	o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI		o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI
	attribute correspond to the BGP MP_UNREACH_NLRI length ?		attribute correspond to the BGP MP_UNREACH_NLRI length?
	o Does the sum of all TLVs found in a Node-, Link or Prefix		o Does the sum of all TLVs found in a Node-, Link or Prefix
	Descriptor NLRI attribute correspond to the Node-, Link- or Prefix		Descriptor NLRI attribute correspond to the Node-, Link- or Prefix
	Descriptors 'Total NLRI Length' field ?		Descriptors 'Total NLRI Length' field?
	o Does any fixed length TLV correspond to the TLV Length field in		o Does any fixed length TLV correspond to the TLV Length field in
	this document ?		this document?
	6.2.3. Configuration Management		6.2.3. Configuration Management
	An implementation SHOULD allow the operator to specify neighbors to		An implementation SHOULD allow the operator to specify neighbors to
	which Link-State NLRIs will be advertised and from which Link-State		which Link-State NLRIs will be advertised and from which Link-State
	NLRIs will be accepted.		NLRIs will be accepted.
	An implementation SHOULD allow the operator to specify the maximum		An implementation SHOULD allow the operator to specify the maximum
	rate at which Link-State NLRIs will be advertised/withdrawn from		rate at which Link-State NLRIs will be advertised/withdrawn from
	neighbors.		neighbors.
	skipping to change at page 38, line 51		skipping to change at page 40, line 13
	number of Link-State NLRIs stored in router's RIB.		number of Link-State NLRIs stored in router's RIB.
	An implementation SHOULD allow the operator to create abstracted		An implementation SHOULD allow the operator to create abstracted
	topologies that are advertised to neighbors; Create different		topologies that are advertised to neighbors; Create different
	abstractions for different neighbors.		abstractions for different neighbors.
	An implementation SHOULD allow the operator to configure a 64-bit		An implementation SHOULD allow the operator to configure a 64-bit
	instance ID.		instance ID.
	An implementation SHOULD allow the operator to configure a pair of		An implementation SHOULD allow the operator to configure a pair of
	ASN and BGP-LS identifier (Paragraph 2) per flooding set in which the		ASN and BGP-LS identifier (Section 3.2.1.4) per flooding set in which
	node participates.		the node participates.
	6.2.4. Accounting Management		6.2.4. Accounting Management
	Not Applicable.		Not Applicable.
	6.2.5. Performance Management		6.2.5. Performance Management
	An implementation SHOULD provide the following statistics:		An implementation SHOULD provide the following statistics:
	o Total number of Link-State NLRI updates sent/received		o Total number of Link-State NLRI updates sent/received
	o Number of Link-State NLRI updates sent/received, per neighbor		o Number of Link-State NLRI updates sent/received, per neighbor
	o Number of errored received Link-State NLRI updates, per neighbor		o Number of errored received Link-State NLRI updates, per neighbor
	o Total number of locally originated Link-State NLRIs		o Total number of locally originated Link-State NLRIs
			These statistics should be recorded as absolute counts since system
			or session start time. An implementation MAY also enhance this
			information by also recording peak per-second counts in each case.
	6.2.6. Security Management		6.2.6. Security Management
	An operator SHOULD define an import policy to limit inbound updates		An operator SHOULD define an import policy to limit inbound updates
	as follows:		as follows:
	o Drop all updates from Consumer peers		o Drop all updates from Consumer peers
	An implementation MUST have means to limit inbound updates.		An implementation MUST have means to limit inbound updates.
	7. TLV/Sub-TLV Code Points Summary		7. TLV/Sub-TLV Code Points Summary
	skipping to change at page 41, line 50		skipping to change at page 43, line 17
	We would like to thank Robert Varga for the significant contribution		We would like to thank Robert Varga for the significant contribution
	he gave to this document.		he gave to this document.
	10. Acknowledgements		10. Acknowledgements
	We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek		We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek
	Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les		Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les
	Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand,		Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand,
	Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas		Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas
	Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro,		Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro,
	Balaji Rajagopalan and Yakov Rekhter for their comments.		Balaji Rajagopalan, Yakov Rekhter, and Alvaro Retana for their
			comments.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and		[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
	dual environments", RFC 1195, December 1990.		dual environments", RFC 1195, DOI 10.17487/RFC1195,
			December 1990, <http://www.rfc-editor.org/info/rfc1195>.
	[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
	E. Lear, "Address Allocation for Private Internets", BCP
	5, RFC 1918, February 1996.
	[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>.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
			DOI 10.17487/RFC2328, April 1998,
			<http://www.rfc-editor.org/info/rfc2328>.
	[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol		[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
	Extensions for IPv6 Inter-Domain Routing", RFC 2545, March		Extensions for IPv6 Inter-Domain Routing", RFC 2545,
	1999.		DOI 10.17487/RFC2545, March 1999,
			<http://www.rfc-editor.org/info/rfc2545>.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001.		Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
			<http://www.rfc-editor.org/info/rfc3209>.
	[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in		[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
	Support of Generalized Multi-Protocol Label Switching		in Support of Generalized Multi-Protocol Label Switching
	(GMPLS)", RFC 4202, October 2005.		(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
			<http://www.rfc-editor.org/info/rfc4202>.
	[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support		[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
	of Generalized Multi-Protocol Label Switching (GMPLS)",		Support of Generalized Multi-Protocol Label Switching
	RFC 4203, October 2005.		(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
			<http://www.rfc-editor.org/info/rfc4203>.
	[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Border Gateway Protocol 4 (BGP-4)", RFC 4271,
			DOI 10.17487/RFC4271, January 2006,
			<http://www.rfc-editor.org/info/rfc4271>.
	[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,		[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
	"Multiprotocol Extensions for BGP-4", RFC 4760, January		"Multiprotocol Extensions for BGP-4", RFC 4760,
	2007.		DOI 10.17487/RFC4760, January 2007,
			<http://www.rfc-editor.org/info/rfc4760>.
	[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.		[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
	Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC		Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
	4915, June 2007.		RFC 4915, DOI 10.17487/RFC4915, June 2007,
			<http://www.rfc-editor.org/info/rfc4915>.
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP		[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
	Specification", RFC 5036, October 2007.		"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
			October 2007, <http://www.rfc-editor.org/info/rfc5036>.
	[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi		[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
	Topology (MT) Routing in Intermediate System to		Topology (MT) Routing in Intermediate System to
	Intermediate Systems (IS-ISs)", RFC 5120, February 2008.		Intermediate Systems (IS-ISs)", RFC 5120,
			DOI 10.17487/RFC5120, February 2008,
			<http://www.rfc-editor.org/info/rfc5120>.
	[RFC5130] Previdi, S., Shand, M., and C. Martin, "A Policy Control		[RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy
	Mechanism in IS-IS Using Administrative Tags", RFC 5130,		Control Mechanism in IS-IS Using Administrative Tags",
	February 2008.		RFC 5130, DOI 10.17487/RFC5130, February 2008,
			<http://www.rfc-editor.org/info/rfc5130>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		DOI 10.17487/RFC5226, May 2008,
			<http://www.rfc-editor.org/info/rfc5226>.
	[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange		[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange
	Mechanism for IS-IS", RFC 5301, October 2008.		Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301,
			October 2008, <http://www.rfc-editor.org/info/rfc5301>.
	[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic		[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
	Engineering", RFC 5305, October 2008.		Engineering", RFC 5305, DOI 10.17487/RFC5305, October
			2008, <http://www.rfc-editor.org/info/rfc5305>.
	[RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support		[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
	of Generalized Multi-Protocol Label Switching (GMPLS)",		in Support of Generalized Multi-Protocol Label Switching
	RFC 5307, October 2008.		(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
			<http://www.rfc-editor.org/info/rfc5307>.
	[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF		[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
	for IPv6", RFC 5340, July 2008.		for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
			<http://www.rfc-editor.org/info/rfc5340>.
	[RFC5890] Klensin, J., "Internationalized Domain Names for		[RFC5890] Klensin, J., "Internationalized Domain Names for
	Applications (IDNA): Definitions and Document Framework",		Applications (IDNA): Definitions and Document Framework",
	RFC 5890, August 2010.		RFC 5890, DOI 10.17487/RFC5890, August 2010,
			<http://www.rfc-editor.org/info/rfc5890>.
	[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic		[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
	Engineering in IS-IS", RFC 6119, February 2011.		Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
			February 2011, <http://www.rfc-editor.org/info/rfc6119>.
	[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP		[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP
	Identifier for BGP-4", RFC 6286, June 2011.		Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286,
			June 2011, <http://www.rfc-editor.org/info/rfc6286>.
	[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-		[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-
	Instance Extensions", RFC 6549, March 2012.		Instance Extensions", RFC 6549, DOI 10.17487/RFC6549,
			March 2012, <http://www.rfc-editor.org/info/rfc6549>.
	[RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D.		[RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D.
	Ward, "IS-IS Multi-Instance", RFC 6822, December 2012.		Ward, "IS-IS Multi-Instance", RFC 6822,
			DOI 10.17487/RFC6822, December 2012,
			<http://www.rfc-editor.org/info/rfc6822>.
			[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
			Patel, "Revised Error Handling for BGP UPDATE Messages",
			RFC 7606, DOI 10.17487/RFC7606, August 2015,
			<http://www.rfc-editor.org/info/rfc7606>.
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-idr-error-handling]		[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
	Chen, E., Scudder, J., Mohapatra, P., and K. Patel,		and E. Lear, "Address Allocation for Private Internets",
	"Revised Error Handling for BGP UPDATE Messages", draft-		BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
	ietf-idr-error-handling-18 (work in progress), December		<http://www.rfc-editor.org/info/rfc1918>.
	2014.
	[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC		[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
	4272, January 2006.		RFC 4272, DOI 10.17487/RFC4272, January 2006,
			<http://www.rfc-editor.org/info/rfc4272>.
			[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
			Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
			2006, <http://www.rfc-editor.org/info/rfc4364>.
	[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation		[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
	Element (PCE)-Based Architecture", RFC 4655, August 2006.		Element (PCE)-Based Architecture", RFC 4655,
			DOI 10.17487/RFC4655, August 2006,
			<http://www.rfc-editor.org/info/rfc4655>.
	[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.		[RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
	Shaffer, "Extensions to OSPF for Advertising Optional		S. Shaffer, "Extensions to OSPF for Advertising Optional
	Router Capabilities", RFC 4970, July 2007.		Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July
			2007, <http://www.rfc-editor.org/info/rfc4970>.
	[RFC5073] Vasseur, J. and J. Le Roux, "IGP Routing Protocol		[RFC5073] Vasseur, J., Ed. and J. Le Roux, Ed., "IGP Routing
	Extensions for Discovery of Traffic Engineering Node		Protocol Extensions for Discovery of Traffic Engineering
	Capabilities", RFC 5073, December 2007.		Node Capabilities", RFC 5073, DOI 10.17487/RFC5073,
			December 2007, <http://www.rfc-editor.org/info/rfc5073>.
	[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain		[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
	Path Computation Method for Establishing Inter-Domain		Per-Domain Path Computation Method for Establishing Inter-
	Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC		Domain Traffic Engineering (TE) Label Switched Paths
	5152, February 2008.		(LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008,
			<http://www.rfc-editor.org/info/rfc5152>.
	[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in		[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
	Support of Inter-Autonomous System (AS) MPLS and GMPLS		Support of Inter-Autonomous System (AS) MPLS and GMPLS
	Traffic Engineering", RFC 5316, December 2008.		Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
			December 2008, <http://www.rfc-editor.org/info/rfc5316>.
	[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in		[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
	Support of Inter-Autonomous System (AS) MPLS and GMPLS		Support of Inter-Autonomous System (AS) MPLS and GMPLS
	Traffic Engineering", RFC 5392, January 2009.		Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392,
			January 2009, <http://www.rfc-editor.org/info/rfc5392>.
	[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic		[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
	Optimization (ALTO) Problem Statement", RFC 5693, October		Optimization (ALTO) Problem Statement", RFC 5693,
	2009.		DOI 10.17487/RFC5693, October 2009,
			<http://www.rfc-editor.org/info/rfc5693>.
	[RFC5706] Harrington, D., "Guidelines for Considering Operations and		[RFC5706] Harrington, D., "Guidelines for Considering Operations and
	Management of New Protocols and Protocol Extensions", RFC		Management of New Protocols and Protocol Extensions",
	5706, November 2009.		RFC 5706, DOI 10.17487/RFC5706, November 2009,
			<http://www.rfc-editor.org/info/rfc5706>.
	[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of		[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
	BGP, LDP, PCEP, and MSDP Issues According to the Keying		BGP, LDP, PCEP, and MSDP Issues According to the Keying
	and Authentication for Routing Protocols (KARP) Design		and Authentication for Routing Protocols (KARP) Design
	Guide", RFC 6952, May 2013.		Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
			<http://www.rfc-editor.org/info/rfc6952>.
	[RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S.,		[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
	Roome, W., Shalunov, S., and R. Woundy, "Application-Layer		Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
	Traffic Optimization (ALTO) Protocol", RFC 7285, September		"Application-Layer Traffic Optimization (ALTO) Protocol",
	2014.		RFC 7285, DOI 10.17487/RFC7285, September 2014,
			<http://www.rfc-editor.org/info/rfc7285>.
	Authors' Addresses		Authors' Addresses
	Hannes Gredler (editor)		Hannes Gredler (editor)
	Juniper Networks, Inc.		Private Contributor
	1194 N. Mathilda Ave.
	Sunnyvale, CA 94089
	US
	Email: hannes@juniper.net		Email: hannes@gredler.at
	Jan Medved		Jan Medved
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170, West Tasman Drive		170, West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	US		US
	Email: jmedved@cisco.com		Email: jmedved@cisco.com
	Stefano Previdi		Stefano Previdi
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Via Del Serafico, 200		Via Del Serafico, 200
	Rome 00142		Rome 00142
	Italy		Italy
	Email: sprevidi@cisco.com		Email: sprevidi@cisco.com
	Adrian Farrel		Adrian Farrel
	Juniper Networks, Inc.		Juniper Networks, Inc.
	1194 N. Mathilda Ave.
	Sunnyvale, CA 94089
	US
	Email: afarrel@juniper.net		Email: adrian@olddog.co.uk
	Saikat Ray		Saikat Ray
	Email: raysaikat@gmail.com		Email: raysaikat@gmail.com
End of changes. 83 change blocks.
	190 lines changed or deleted		255 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/