< draft-ietf-idr-te-pm-bgp-02.txt		draft-ietf-idr-te-pm-bgp-03.txt >
	IDR Working Group Q. Wu		Networking Working Group S. Previdi, Ed.
	Internet-Draft Huawei		Internet-Draft Cisco Systems, Inc.
	Intended status: Standards Track S. Previdi		Intended status: Standards Track Q. Wu
	Expires: July 8, 2015 Cisco		Expires: November 12, 2016 Huawei
	H. Gredler		H. Gredler
	Juniper
	S. Ray		S. Ray
	Cisco
	J. Tantsura		J. Tantsura
	Ericsson		Individual
	January 4, 2015		C. Filsfils
			L. Ginsberg
			Cisco Systems, Inc.
			May 11, 2016
	BGP attribute for North-Bound Distribution of Traffic Engineering (TE)		BGP-LS Advertisement of IGP Traffic Engineering Performance Metric
	performance Metrics		Extensions
	draft-ietf-idr-te-pm-bgp-02		draft-ietf-idr-te-pm-bgp-03
	Abstract		Abstract
	In order to populate network performance information like link		This document defines new BGP-LS TLVs in order to carry the IGP
	latency, latency variation, packet loss and bandwidth into Traffic		Traffic Engineering Extensions defined in IS-IS and OSPF protocols.
	Engineering Database(TED) and ALTO server, this document describes
	extensions to BGP protocol, that can be used to distribute network		Requirements Language
	performance information (such as link delay, delay variation, packet
	loss, residual bandwidth, available bandwidth and utilized bandwidth		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	).		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119 [RFC2119].
			In this document, these words will appear with that interpretation
			only when in ALL CAPS. Lower case uses of these words are not to be
			interpreted as carrying RFC-2119 significance.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted 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). 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 November 12, 2016.
	This Internet-Draft will expire on July 8, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions used in this document . . . . . . . . . . . . . . 3		2. Link Attribute TLVs for TE Metric Extensions . . . . . . . . 3
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. TLV Details . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. MPLS-TE with H-PCE . . . . . . . . . . . . . . . . . . . 3		3.1. Unidirectional Link Delay TLV . . . . . . . . . . . . . . 3
	3.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 4		3.2. Min/Max Unidirectional Link Delay TLV . . . . . . . . . . 4
	4. Carrying TE Performance information in BGP . . . . . . . . . 5		3.3. Unidirectional Delay Variation TLV . . . . . . . . . . . 4
	5. Attribute TLV Details . . . . . . . . . . . . . . . . . . . . 6		3.4. Unidirectional Link Loss TLV . . . . . . . . . . . . . . 5
	6. Manageability Considerations . . . . . . . . . . . . . . . . 7		3.5. Unidirectional Residual Bandwidth TLV . . . . . . . . . . 5
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		3.6. Unidirectional Available Bandwidth TLV . . . . . . . . . 5
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		3.7. Unidirectional Utilized Bandwidth TLV . . . . . . . . . . 6
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	9.1. Normative References . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	9.2. Informative References . . . . . . . . . . . . . . . . . 8		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	A.1. draft-ietf-idr-te-pm-bgp-00 . . . . . . . . . . . . . . . 9		7.1. Normative References . . . . . . . . . . . . . . . . . . 7
	A.2. draft-ietf-idr-te-pm-bgp-02 . . . . . . . . . . . . . . . 9		7.2. Informative References . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	As specified in [RFC4655],a Path Computation Element (PCE) is an		BGP-LS ([RFC7752]) defines NLRI and attributes in order to carry
	entity that is capable of computing a network path or route based on		link-state information. New BGP-LS Link-Attribute TLVs are required
	a network graph, and of applying computational constraints during the		in order to carry the Traffic Engineering Metric Extensions defined
	computation. In order to compute an end to end path, the PCE needs		in [RFC7810] and [RFC7471].
	to have a unified view of the overall topology[I-D.ietf-pce-pcep-
	service-aware]. [I.D-ietf-idr-ls-distribution] describes a mechanism
	by which links state and traffic engineering information can be
	collected from networks and shared with external components using the
	BGP routing protocol. This mechanism can be used by both PCE and
	ALTO server to gather information about the topologies and
	capabilities of the network.
	With the growth of network virtualization technology, the Network		2. Link Attribute TLVs for TE Metric Extensions
	performance or QoS requirements such as latency, limited bandwidth,
	packet loss, and jitter, for real traffic are all critical factors
	that must be taken into account in the end to end path computation
	and selection ([I-D.ietf-pce-pcep-service-aware])which enable
	optimizing resource usage and degrading gracefully during period of
	heavy load .
	In order to populate network performance information like link		The following new Link Attribute TLVs are defined:
	latency, latency variation, packet loss and bandwidth into TED and
	ALTO server, this document describes extensions to BGP protocol, that
	can be used to distribute network performance information (such as
	link delay, delay variation, packet loss, residual bandwidth,
	available bandwidth, and utilized bandwidth). The network
	performance information can be distributed in the same way as link
	state information distribution,i.e., either directly or via a peer
	BGP speaker (see figure 1 of [I.D-ietf-idr-ls-distribution]).
	2. Conventions used in this document		TLV Type Value
			--------------------------------------------------------
			1104 (Suggested) Unidirectional Link Delay
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		1105 (Suggested) Min/Max Unidirectional Link Delay
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC2119 [RFC2119].
	3. Use Cases		1106 (Suggested) Unidirectional Delay Variation
	3.1. MPLS-TE with H-PCE		1107 (Suggested) Unidirectional Packet Loss
	For inter-AS path computation the Hierarchical PCE (H-PCE) [RFC6805]		1108 (Suggested) Unidirectional Residual Bandwidth
	may be used to compute the optimal sequence of domains. Within the
	H-PCE architecture, the child PCE communicates domain connectivity
	information to the parent PCE, and the parent PCE will use this
	information to compute a multi-domain path based on the optimal TE
	links between domains [I.D-ietf-pce-hierarchy-extensions] for the
	end-to-end path.
	The following figure demonstrates how a parent PCE may obtain TE		1109 (Suggested) Unidirectional Available Bandwidth
	performance information beyond that contained in the LINK_STATE
	attributes [I.D-ietf-idr-ls-distribution] using the mechanism
	described in this document.
	+----------+ +---------+		1110 (Suggested) Unidirectional Bandwidth Utilization
	| ----- | | BGP |
	| | TED |<-+-------------------------->| Speaker |
	| ----- | TED synchronization | |
	| | | mechanism: +---------+
	| | | BGP with TE performance
	| v | NLRI
	| ----- |
	| | PCE | |
	| ----- |
	+----------+
	^
	| Request/
	| Response
	v
	Service +----------+ Signaling +----------+
	Request | Head-End | Protocol | Adjacent |
	-------->| Node |<------------>| Node |
	+----------+ +----------+
	Figure 1: External PCE node using a TED synchronization mechanism		3. TLV Details
	3.2. ALTO Server Network API		3.1. Unidirectional Link Delay TLV
	The ALTO Server can aggregate information from multiple systems to		This TLV advertises the average link delay between two directly
	provide an abstract and unified view that can be more useful to		connected IGP link-state neighbors. The semantic of the TLV is
	applications.		described in [RFC7810] and [RFC7471].
	The following figure shows how an ALTO Server can get TE performance		0 1 2 3
	information from the underlying network beyond that contained in the		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
	LINK_STATE attributes [I.D-ietf-idr-ls-distribution] using the		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	mechanism described in this document.		| Type | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|A| RESERVED | Delay |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+--------+		where:
	| Client |<--+
	+--------+ |
	| ALTO +--------+ BGP with +---------+
	+--------+ | Protocol | ALTO | TE Performance | BGP |
	| Client |<--+------------| Server |<----------------| Speaker |
	+--------+ | | | NLR | |
	| +--------+ +---------+
	+--------+ |
	| Client |<--+
	+--------+
	Figure 2: ALTO Server using network performance information
	4. Carrying TE Performance information in BGP		Figure 1
	This document proposes new BGP TE performance TLVs that can be		Type: TBA (suggested value: 1104).
	announced as attribute in the BGP-LS attribute (defined in [I.D-ietf-
	idr-ls-distribution]) to distribute network performance information.
	The extensions in this document build on the ones provided in BGP-LS
	[I.D-ietf-idr-ls-distribution] and BGP-4 [RFC4271].
	BGP-LS attribute defined in [I.D-ietf-idr-ls-distribution] has nested		Length: 4.
	TLVs which allow the BGP-LS attribute to be readily extended. This
	document proposes seven additional TLVs as its attributes:
	Type Value		3.2. Min/Max Unidirectional Link Delay TLV
	TBD1 Unidirectional Link Delay		This sub-TLV advertises the minimum and maximum delay values between
			two directly connected IGP link-state neighbors. The semantic of the
			TLV is described in [RFC7810] and [RFC7471].
	TBD2 Min/Max Unidirectional Link Delay		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|A| RESERVED | Min Delay |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| RESERVED | Max Delay |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TBD3 Unidirectional Delay Variation		where:
	TBD4 Unidirectional Packet Loss		Figure 2
	TBD5 Unidirectional Residual Bandwidth		Type: TBA (suggested value: 1105).
	TBD6 Unidirectional Available Bandwidth		Length: 8.
	TBD7 Unidirectional Utilized Bandwidth		3.3. Unidirectional Delay Variation TLV
	As can be seen in the list above, the TLVs described in this document		This sub-TLV advertises the average link delay variation between two
	carry different types of network performance information. Some of		directly connected IGP link-state neighbors. The semantic of the TLV
	these TLVs include a bit called the Anomalous (or "A") bit at the		is described in [RFC7810] and [RFC7471].
	left-most bit after length field of each TLV defined in figure 4 of
	[[I.D-ietf-idr-ls-distribution]]. The other bits in the first octets
	after length field of each TLV is reserved for future use. When the
	A bit is clear (or when the TLV does not include an A bit), the TLV
	describes steady state link performance. This information could
	conceivably be used to construct a steady state performance topology
	for initial tunnel path computation, or to verify alternative
	failover paths.
	When network performance downgrades and exceeds configurable maximum		0 1 2 3
	thresholds, a TLV with the A bit set is advertised. These TLVs could		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
	be used by the receiving BGP peer to determine whether to redirect		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	failing traffic to a backup path, or whether to calculate an entirely		| Type | Length |
	new path. If link performance improves later and falls below a		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	configurable value, that TLV can be re- advertised with the Anomalous		| RESERVED | Delay Variation |
	bit cleared. In this case, a receiving BGP peer can conceivably do		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	whatever re-optimization (or failback) it wishes to do (including
	nothing).
	Note that when a TLV does not include the A bit, that TLV cannot be		where:
	used for failover purposes. The A bit was intentionally omitted from
	some TLVs to help mitigate oscillations.
	Consistent with existing ISIS TE specifications [ISIS-TE-METRIC], the		Figure 3
	bandwidth advertisements, the delay and delay variation
	advertisements, packet loss defined in this document MUST be encoded
	in the same unit as one defined in IS-IS Extended IS Reachability
	sub-TLVs [ISIS-TE-METRIC]. All values (except residual bandwidth)
	MUST be obtained by a filter that is reasonably representative of an
	average or calculated as rolling averages where the averaging period
	MUST be a configurable period of time. The measurement interval, any
	filter coefficients, and any advertisement intervals MUST be
	configurable per sub-TLV in the same way as ones defined in section 5
	of [ISIS-TE-METRIC].
	5. Attribute TLV Details		Type: TBA (suggested value: 1106).
	Link attribute TLVs defined in section 3.2.2 of [I-D.ietf-idr-ls-		Length: 4.
	distribution]are TLVs that may be encoded in the BGP-LS attribute
	with a link NLRI. Each 'Link Attribute' is a Type/Length/ Value
	(TLV) triplet formatted as defined in Section 3.1 of [I-D.ietf-idr-
	ls-distribution]. The format and semantics of the 'value' fields in
	'Link Attribute' TLVs correspond to the format and semantics of value
	fields in IS-IS Extended IS Reachability sub-TLVs, defined in
	[RFC5305]. Although the encodings for 'Link Attribute' TLVs were
	originally defined for IS-IS, the TLVs can carry data sourced either
	by IS-IS or OSPF.
	The following 'Link Attribute' TLVs are valid in the LINK_STATE		3.4. Unidirectional Link Loss TLV
	attribute:
	+------------+---------------------+--------------+-----------------+		This sub-TLV advertises the loss (as a packet percentage) between two
	| TLV Code | Description | IS-IS | Defined in: |		directly connected IGP link-state neighbors. The semantic of the TLV
	| Point | | TLV/Sub-TLV | |		is described in [RFC7810] and [RFC7471].
	+------------+---------------------+--------------+-----------------+
	| xxxx | Unidirectional | 22/xx | [ISIS-TE- |
	| | Link Delay | | METRIC]/4.1 |
	| | | | |
	| xxxx | Min/Max Unidirection| 22/xx | [ISIS-TE- |
	| | Link Delay | | METRIC]/4.2 |
	| | | | |
	| xxxx | Unidirectional | 22/xx | [ISIS-TE- |
	| | Delay Variation | | METRIC]/4.3 |
	| | | | |
	| xxxx | Unidirectional | 22/xx | [ISIS-TE- |
	| | Link Loss | | METRIC]/4.4 |
	| | | | |
	| xxxx | Unidirectional | 22/xx | [ISIS-TE- |
	| |Residual Bandwidth | | METRIC]/4.5 |
	| | | | |
	| xxxx | Unidirectional | 22/xx | [ISIS-TE- |
	| |Available Bandwidth | | METRIC]/4.6 |
	| | | | |
	| xxxx | Unidirectional | 22/xx | [ISIS-TE- |
	| |Utilized Bandwidth | | METRIC]/4.7 |
	+------------+---------------------+--------------+-----------------+
	Table 1: Link Attribute TLVs		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|A| RESERVED | Link Loss |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	6. Manageability Considerations		where:
	Manageability Considerations described in section 6.2 of [I-D.ietf-		Type: TBA (suggested value: 1107).
	idr-ls-distribution] can be applied to Traffic Engineering (TE)
	performance Metrics as well.
	7. Security Considerations		Length: 4.
	This document does not introduce security issues beyond those		3.5. Unidirectional Residual Bandwidth TLV
	discussed in [I.D-ietf-idr-ls-distribution] and [RFC4271].
	8. IANA Considerations		This sub-TLV advertises the residual bandwidth between two directly
			connected IGP link-state neighbors. The semantic of the TLV is
			described in [RFC7810] and [RFC7471].
	IANA maintains the registry for the TLVs. BGP TE Performance TLV		0 1 2 3
	will require one new type code per TLV defined in this document.		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 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Residual Bandwidth |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	9. References		where:
	9.1. Normative References		Type: TBA (suggested value: 1108).
	[I-D.ietf-idr-ls-distribution]		Length: 4.
	Gredler, H., "North-Bound Distribution of Link-State and
	TE Information using BGP", ID draft-ietf-idr-ls-
	distribution-07, November 2014.
	[I-D.ietf-pce-pcep-service-aware]		3.6. Unidirectional Available Bandwidth TLV
	Dhruv, D., "Extensions to the Path Computation Element
	Communication Protocol (PCEP) to compute service aware
	Label Switched Path (LSP)", ID draft-ietf-pce-pcep-
	service-aware-06, December 2014.
	[ISIS-TE-METRIC]		This sub-TLV advertises the available bandwidth between two directly
	Giacalone, S., "ISIS Traffic Engineering (TE) Metric		connected IGP link-state neighbors. The semantic of the TLV is
	Extensions", ID draft-ietf-isis-te-metric-extensions-04,		described in [RFC7810] and [RFC7471].
	October 2014.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		0 1 2 3
	Requirement Levels", March 1997.		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 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Available Bandwidth |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	[RFC4271] Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)", RFC		where:
	4271, January 2006.
	[RFC5305] Li, T., "IS-IS Extensions for Traffic Engineering", RFC		Figure 4
	5305, October 2008.
	9.2. Informative References		Type: TBA (suggested value: 1109).
	[ALTO] Yang, Y., "ALTO Protocol", ID		Length: 4.
	http://tools.ietf.org/html/draft-ietf-alto-protocol-16,
	May 2013.
	[I.D-ietf-pce-hierarchy-extensions]		3.7. Unidirectional Utilized Bandwidth TLV
	Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
	and D. King, "Extensions to Path Computation Element
	Communication Protocol (PCEP) for Hierarchical Path
	Computation Elements (PCE)", ID draft-ietf-pce-hierarchy-
	extensions-01, February 2014.
	[RFC4655] Farrel, A., "A Path Computation Element (PCE)-Based		This sub-TLV advertises the bandwidth utilization between two
	Architecture", RFC 4655, August 2006.		directly connected IGP link-state neighbors. The semantic of the TLV
			is described in [RFC7810] and [RFC7471].
	Appendix A. Change Log		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Utilized Bandwidth |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Note to the RFC-Editor: please remove this section prior to		where:
	publication as an RFC.
	A.1. draft-ietf-idr-te-pm-bgp-00		Figure 5
	The following are the major changes compared to previous version		Type: TBA (suggested value: 1110).
	draft-wu-idr-te-pm-bgp-03:
	o Update PCE case in section 3.1.		Length: 4.
	o Add some texts in section 1 and section 4 to clarify from where to		4. Security Considerations
	distribute pm info and measurement interval and method.
	A.2. draft-ietf-idr-te-pm-bgp-02		Procedures and protocol extensions defined in this document do not
			affect the BGP security model. See the 'Security Considerations'
			section of [RFC4271] for a discussion of BGP security. Also refer to
			[RFC4272] and [RFC6952] for analysis of security issues for BGP.
	The following are the major changes compared to previous version		The TLVs introduced in this document are used to propagate IGP
	draft-wu-idr-te-pm-bgp-03:		defined information ([RFC7810] and [RFC7471].) These TLVs represent
			the state and resources availability of the IGP link. The IGP
			instances originating these TLVs are assumed to have all the required
			security and authentication mechanism (as described in [RFC7810] and
			[RFC7471]) in order to prevent any security issue when propagating
			the TLVs into BGP-LS.
	o Some Editorial changes.		5. IANA Considerations
			This document requests assigning code-points from the registry "BGP-
			LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
			TLVs" for the new Link Attribute TLVs deefined in the table here
			below:
			TLV code-point Value
			--------------------------------------------------------
			1104 (Suggested) Unidirectional Link Delay
			1105 (Suggested) Min/Max Unidirectional Link Delay
			1106 (Suggested) Unidirectional Delay Variation
			1107 (Suggested) Unidirectional Packet Loss
			1108 (Suggested) Unidirectional Residual Bandwidth
			1109 (Suggested) Unidirectional Available Bandwidth
			1110 (Suggested) Unidirectional Bandwidth Utilization
			6. Acknowledgements
			TBD
			7. References
			7.1. Normative References
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
			[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
			Border Gateway Protocol 4 (BGP-4)", RFC 4271,
			DOI 10.17487/RFC4271, January 2006,
			<http://www.rfc-editor.org/info/rfc4271>.
			[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
			Previdi, "OSPF Traffic Engineering (TE) Metric
			Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
			<http://www.rfc-editor.org/info/rfc7471>.
			[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
			S. Ray, "North-Bound Distribution of Link-State and
			Traffic Engineering (TE) Information Using BGP", RFC 7752,
			DOI 10.17487/RFC7752, March 2016,
			<http://www.rfc-editor.org/info/rfc7752>.
			[RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
			Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
			RFC 7810, DOI 10.17487/RFC7810, May 2016,
			<http://www.rfc-editor.org/info/rfc7810>.
			7.2. Informative References
			[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
			RFC 4272, DOI 10.17487/RFC4272, January 2006,
			<http://www.rfc-editor.org/info/rfc4272>.
			[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
			BGP, LDP, PCEP, and MSDP Issues According to the Keying
			and Authentication for Routing Protocols (KARP) Design
			Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
			<http://www.rfc-editor.org/info/rfc6952>.
	Authors' Addresses		Authors' Addresses
			Stefano Previdi (editor)
			Cisco Systems, Inc.
			Via Del Serafico 200
			Rome 00191
			IT
			Email: sprevidi@cisco.com
	Qin Wu		Qin Wu
	Huawei		Huawei
	101 Software Avenue, Yuhua District		101 Software Avenue, Yuhua District
	Nanjing, Jiangsu 210012		Nanjing, Jiangsu 210012
	China		China
	Email: bill.wu@huawei.com		Email: bill.wu@huawei.com
	Stefano Previdi
	Cisco Systems, Inc.
	Via Del Serafico 200
	Rome 00191
	Italy
	Email: sprevidi@cisco.com
	Hannes Gredler		Hannes Gredler
	Juniper Networks, Inc.		Individual
	1194 N. Mathilda Ave.		AT
	Sunnyvale, CA 94089
	US
	Email: hannes@juniper.net		Email: hannes@gredler.at
	Saikat Ray		Saikat Ray
	Cisco Systems, Inc.		Individual
	170, West Tasman Drive
	San Jose, CA 95134
	US		US
	Email: sairay@cisco.com		Email: raysaikat@gmail.com
	Jeff Tantsura		Jeff Tantsura
	Ericsson		Individual
	300 Holger Way
	San Jose, CA 95134
	US		US
	Email: jeff.tantsura@ericsson.com		Email: jefftant@gmail.com
			Clarence Filsfils
			Cisco Systems, Inc.
			Brussels
			BE
			Email: cfilsfil@cisco.com
			Les Ginsberg
			Cisco Systems, Inc.
			US
			Email: ginsberg@cisco.com
End of changes. 79 change blocks.
	287 lines changed or deleted		257 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/