< draft-ietf-idr-te-lsp-distribution-09.txt		draft-ietf-idr-te-lsp-distribution-10.txt >
	Network Working Group S. Previdi, Ed.		Network Working Group S. Previdi
	Internet-Draft		Internet-Draft
	Intended status: Standards Track K. Talaulikar		Intended status: Standards Track K. Talaulikar, Ed.
	Expires: December 31, 2018 Cisco Systems, Inc.		Expires: August 30, 2019 Cisco Systems, Inc.
	J. Dong, Ed.		J. Dong, Ed.
	M. Chen		M. Chen
	Huawei Technologies		Huawei Technologies
	H. Gredler		H. Gredler
	RtBrick Inc.		RtBrick Inc.
	J. Tantsura		J. Tantsura
	Nuage Networks		Apstra
	June 29, 2018		February 26, 2019
	Distribution of Traffic Engineering (TE) Policies and State using BGP-LS		Distribution of Traffic Engineering (TE) Policies and State using BGP-LS
	draft-ietf-idr-te-lsp-distribution-09		draft-ietf-idr-te-lsp-distribution-10
	Abstract		Abstract
	This document describes a mechanism to collect the Traffic		This document describes a mechanism to collect the Traffic
	Engineering and Policy information that is locally available in a		Engineering and Policy information that is locally available in a
	node and advertise it into BGP-LS updates. Such information can be		node and advertise it into BGP Link State (BGP-LS) updates. Such
	used by external components for path computation, re-optimization,		information can be used by external components for path computation,
	service placement, network visualization, etc.		re-optimization, service placement, network visualization, etc.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in RFC 2119 [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 August 30, 2019.
	This Internet-Draft will expire on December 31, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	skipping to change at page 2, line 44 ¶		skipping to change at page 2, line 45 ¶
	5. MPLS-TE Policy State TLV . . . . . . . . . . . . . . . . . . 14		5. MPLS-TE Policy State TLV . . . . . . . . . . . . . . . . . . 14
	5.1. RSVP Objects . . . . . . . . . . . . . . . . . . . . . . 15		5.1. RSVP Objects . . . . . . . . . . . . . . . . . . . . . . 15
	5.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 16		5.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 16
	6. SR Policy State TLVs . . . . . . . . . . . . . . . . . . . . 17		6. SR Policy State TLVs . . . . . . . . . . . . . . . . . . . . 17
	6.1. SR Binding SID . . . . . . . . . . . . . . . . . . . . . 17		6.1. SR Binding SID . . . . . . . . . . . . . . . . . . . . . 17
	6.2. SR Candidate Path State . . . . . . . . . . . . . . . . . 19		6.2. SR Candidate Path State . . . . . . . . . . . . . . . . . 19
	6.3. SR Candidate Path Name . . . . . . . . . . . . . . . . . 21		6.3. SR Candidate Path Name . . . . . . . . . . . . . . . . . 21
	6.4. SR Candidate Path Constraints . . . . . . . . . . . . . . 21		6.4. SR Candidate Path Constraints . . . . . . . . . . . . . . 21
	6.4.1. SR Affinity Constraint . . . . . . . . . . . . . . . 23		6.4.1. SR Affinity Constraint . . . . . . . . . . . . . . . 23
	6.4.2. SR SRLG Constraint . . . . . . . . . . . . . . . . . 24		6.4.2. SR SRLG Constraint . . . . . . . . . . . . . . . . . 24
	6.4.3. SR Bandwidth Constraint . . . . . . . . . . . . . . . 24		6.4.3. SR Bandwidth Constraint . . . . . . . . . . . . . . . 25
	6.4.4. SR Disjoint Group Constraint . . . . . . . . . . . . 25		6.4.4. SR Disjoint Group Constraint . . . . . . . . . . . . 25
	6.5. SR Segment List . . . . . . . . . . . . . . . . . . . . . 27		6.5. SR Segment List . . . . . . . . . . . . . . . . . . . . . 27
	6.6. SR Segment . . . . . . . . . . . . . . . . . . . . . . . 29		6.6. SR Segment . . . . . . . . . . . . . . . . . . . . . . . 30
	6.6.1. Segment Descriptors . . . . . . . . . . . . . . . . . 31		6.6.1. Segment Descriptors . . . . . . . . . . . . . . . . . 31
	6.7. SR Segment List Metric . . . . . . . . . . . . . . . . . 37		6.7. SR Segment List Metric . . . . . . . . . . . . . . . . . 38
	7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 39		7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 40
	8. Manageability Considerations . . . . . . . . . . . . . . . . 40		8. Manageability Considerations . . . . . . . . . . . . . . . . 41
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
	9.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 40		9.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 41
	9.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 40		9.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 41
	9.3. BGP-LS TLVs . . . . . . . . . . . . . . . . . . . . . . . 41		9.3. BGP-LS TLVs . . . . . . . . . . . . . . . . . . . . . . . 42
	9.4. BGP-LS SR Policy Protocol Origin . . . . . . . . . . . . 41		9.4. BGP-LS SR Policy Protocol Origin . . . . . . . . . . . . 42
	9.5. BGP-LS TE State Path Origin . . . . . . . . . . . . . . . 42		9.5. BGP-LS TE State Object Origin . . . . . . . . . . . . . . 43
	9.6. BGP-LS TE State Dataplane . . . . . . . . . . . . . . . . 42		9.6. BGP-LS TE State Address Family . . . . . . . . . . . . . 43
	9.7. BGP-LS SR Segment Descriptors . . . . . . . . . . . . . . 43		9.7. BGP-LS SR Segment Descriptors . . . . . . . . . . . . . . 44
	9.8. BGP-LS Metric Type . . . . . . . . . . . . . . . . . . . 43		9.8. BGP-LS Metric Type . . . . . . . . . . . . . . . . . . . 44
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 44		10. Security Considerations . . . . . . . . . . . . . . . . . . . 45
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
	12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 44		12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
	13.1. Normative References . . . . . . . . . . . . . . . . . . 44		13.1. Normative References . . . . . . . . . . . . . . . . . . 45
	13.2. Informative References . . . . . . . . . . . . . . . . . 46		13.2. Informative References . . . . . . . . . . . . . . . . . 47
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
	1. Introduction		1. Introduction
	In many network environments, traffic engineering policies are		In many network environments, traffic engineering (TE) policies are
	instantiated into various forms:		instantiated into various forms:
	o MPLS Traffic Engineering Label Switched Paths (TE-LSPs).		o MPLS Traffic Engineering Label Switched Paths (TE-LSPs).
	o IP based tunnels (IP in IP, GRE, etc).		o IP based tunnels (IP in IP, GRE, etc).
	o Segment Routing Policies (SR Policy) as defined in		o Segment Routing (SR) Policies as defined in
	[I-D.ietf-spring-segment-routing-policy]		[I-D.ietf-spring-segment-routing-policy]
	o Local MPLS cross-connect configuration		o Local MPLS cross-connect configuration
	All this information can be grouped into the same term: TE Policies.		All this information can be grouped into the same term: TE Policies.
	In the rest of this document we refer to TE Policies as the set of		In the rest of this document we refer to TE Policies as the set of
	information related to the various instantiation of polices: MPLS TE		information related to the various instantiation of polices: MPLS TE
	LSPs, IP tunnels (IPv4 or IPv6), SR Policies, etc.		LSPs, IP tunnels (IPv4 or IPv6), SR Policies, etc.
	TE Polices are generally instantiated at the head-end and are based		TE Polices are generally instantiated at the head-end and are based
	skipping to change at page 6, line 41 ¶		skipping to change at page 6, line 43 ¶
	| Protocol-ID | NLRI information source protocol |		| Protocol-ID | NLRI information source protocol |
	+-------------+----------------------------------+		+-------------+----------------------------------+
	| TBD | RSVP-TE |		| TBD | RSVP-TE |
	| TBD | Segment Routing |		| TBD | Segment Routing |
	+-------------+----------------------------------+		+-------------+----------------------------------+
	o "Identifier" is an 8 octet value as defined in [RFC7752].		o "Identifier" is an 8 octet value as defined in [RFC7752].
	o "Headend" consists of a Node Descriptor defined in [RFC7752].		o "Headend" consists of a Node Descriptor defined in [RFC7752].
	o "TE Policy Descriptors" consists of (values TBD see IANA		o "TE Policy Descriptors" consists of one or more of the TLVs listed
	Considerations Section 9.3):		as below: (values TBD see IANA Considerations Section 9.3):
	+-----------+----------------------------------+		+-----------+----------------------------------+
	| Codepoint | Descriptor TLVs |		| Codepoint | Descriptor TLVs |
	+-----------+----------------------------------+		+-----------+----------------------------------+
	| TBD | Tunnel ID |		| TBD | Tunnel ID |
	| TBD | LSP ID |		| TBD | LSP ID |
	| TBD | IPv4/6 Tunnel Head-end address |		| TBD | IPv4/6 Tunnel Head-end address |
	| TBD | IPv4/6 Tunnel Tail-end address |		| TBD | IPv4/6 Tunnel Tail-end address |
	| TBD | SR Policy Candidate Path |		| TBD | SR Policy Candidate Path |
	| TBD | Local MPLS Cross Connect |		| TBD | Local MPLS Cross Connect |
	skipping to change at page 10, line 30 ¶		skipping to change at page 10, line 30 ¶
	receiver.		receiver.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|E|O| |		|E|O| |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	where:		where:
	* E-Flag : Indicates the encoding of endpoint as IPv6 address		* E-Flag : Indicates the encoding of endpoint as IPv6 address
	when SET and IPv4 address when CLEAR		when set and IPv4 address when clear
	* O-Flag : Indicates the encoding of originator address as IPv6		* O-Flag : Indicates the encoding of originator address as IPv6
	address when SET and IPv4 address when CLEAR		address when set and IPv4 address when clear
	o Reserved : 2 octets which SHOULD be set to 0 by originator and		o Reserved : 2 octets which SHOULD be set to 0 by originator and
	MUST be ignored by receiver.		MUST be ignored by receiver.
	o Endpoint : 4 or 16 octets (as indicated by the flags) containing		o Endpoint : 4 or 16 octets (as indicated by the flags) containing
	the address of the endpoint of the SR Policy		the address of the endpoint of the SR Policy
	o Color : 4 octets that indicates the color of the SR Policy		o Color : 4 octets that indicates the color of the SR Policy
	o Originator ASN : 4 octets to carry the 4 byte encoding of the ASN		o Originator ASN : 4 octets to carry the 4 byte encoding of the ASN
	skipping to change at page 14, line 19 ¶		skipping to change at page 14, line 19 ¶
	where:		where:
	* 4-Flag is the IPv4 flag. When set, the FEC Sub-TLV describes		* 4-Flag is the IPv4 flag. When set, the FEC Sub-TLV describes
	an IPv4 FEC. If the 4-flag is not set, then the FEC Sub-TLV		an IPv4 FEC. If the 4-flag is not set, then the FEC Sub-TLV
	describes an IPv6 FEC.		describes an IPv6 FEC.
	o Mask Length: 1 octet of prefix length.		o Mask Length: 1 octet of prefix length.
	o Prefix: an IPv4 or IPv6 prefix whose mask length is given by the "		o Prefix: an IPv4 or IPv6 prefix whose mask length is given by the "
	Mask Length" field.		Mask Length" field padded to an octet boundary.
	5. MPLS-TE Policy State TLV		5. MPLS-TE Policy State TLV
	A new TLV called "MPLS-TE Policy State TLV", is used to describe the		A new TLV called "MPLS-TE Policy State TLV", is used to describe the
	characteristics of the MPLS-TE Policy and it is carried in the		characteristics of the MPLS-TE Policy and it is carried in the
	optional non-transitive BGP Attribute "LINK_STATE Attribute" defined		optional non-transitive BGP Attribute "LINK_STATE Attribute" defined
	in [RFC7752]. These MPLS-TE Policy characteristics include the		in [RFC7752]. These MPLS-TE Policy characteristics include the
	characteristics and attributes of the policy, it's dataplane,		characteristics and attributes of the policy, its dataplane, explicit
	explicit path, Quality of Service (QoS) parameters, route		path, Quality of Service (QoS) parameters, route information, the
	information, the protection mechanisms, etc.		protection mechanisms, etc.
	The MPLS-TE Policy State TLV has the following format:		The MPLS-TE Policy State TLV has the following format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Path-origin | Dataplane | RESERVED |		| Object-origin | Address Family| RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// MPLS-TE Policy State Objects (variable) //		// MPLS-TE Policy State Objects (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	MPLS-TE Policy State TLV		MPLS-TE Policy State TLV
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: TBD (see IANA Considerations Section 9.3)
	o Length: the total length of the MPLS-TE Policy State TLV not		o Length: the total length of the MPLS-TE Policy State TLV not
	including Type and Length fields.		including Type and Length fields.
	o Path-origin: identifies the component (or protocol) from which the		o Object-origin: identifies the component (or protocol) from which
	contained object originated. This allows for objects defined in		the contained object originated. This allows for objects defined
	different components to be collected while avoiding the possible		in different components to be collected while avoiding the
	codepoint collisions among these components. Following path-		possible codepoint collisions among these components. Following
	origin codepoints are defined in this document.		object-origin codepoints are defined in this document.
	+----------+------------------+		+----------+------------------+
	| Code | Path |		| Code | Object |
	| Point | Origin |		| Point | Origin |
	+----------+------------------+		+----------+------------------+
	| 1 | RSVP-TE |		| 1 | RSVP-TE |
	| 2 | PCEP |		| 2 | PCEP |
	| 3 | Local/Static |		| 3 | Local/Static |
	+----------+------------------+		+----------+------------------+
	o Dataplane: describes to which dataplane the policy is applied to.		o Address Family: describes the address family used to setup the
	The following dataplane values are defined in this document:		MPLS-TE policy. The following address family values are defined
			in this document:
	+----------+------------------+		+----------+------------------+
	| Code | Dataplane |		| Code | Dataplane |
	| Point | |		| Point | |
	+----------+------------------+		+----------+------------------+
	| 1 | MPLS-IPv4 |		| 1 | MPLS-IPv4 |
	| 2 | MPLS-IPv6 |		| 2 | MPLS-IPv6 |
	+----------+------------------+		+----------+------------------+
	o RESERVED: 16-bit field. SHOULD be set to 0 on transmission and		o RESERVED: 16-bit field. SHOULD be set to 0 on transmission and
	skipping to change at page 16, line 5 ¶		skipping to change at page 16, line 5 ¶
	5.1. RSVP Objects		5.1. RSVP Objects
	RSVP-TE objects are encoded in the "MPLS-TE Policy State Objects"		RSVP-TE objects are encoded in the "MPLS-TE Policy State Objects"
	field of the MPLS-TE Policy State TLV and consists of MPLS TE LSP		field of the MPLS-TE Policy State TLV and consists of MPLS TE LSP
	objects defined in RSVP-TE [RFC3209] [RFC3473]. Rather than		objects defined in RSVP-TE [RFC3209] [RFC3473]. Rather than
	replicating all MPLS TE LSP related objects in this document, the		replicating all MPLS TE LSP related objects in this document, the
	semantics and encodings of the MPLS TE LSP objects are re-used.		semantics and encodings of the MPLS TE LSP objects are re-used.
	These MPLS TE LSP objects are carried in the MPLS-TE Policy State		These MPLS TE LSP objects are carried in the MPLS-TE Policy State
	TLV.		TLV.
	When carrying RSVP-TE objects, the "Path-Origin" field is set to		When carrying RSVP-TE objects, the "Object-Origin" field is set to
	"RSVP-TE".		"RSVP-TE".
	The following RSVP-TE Objects are defined:		The following RSVP-TE Objects are defined:
	o SENDER_TSPEC and FLOW_SPEC [RFC2205]		o SENDER_TSPEC and FLOW_SPEC [RFC2205]
	o SESSION_ATTRIBUTE [RFC3209]		o SESSION_ATTRIBUTE [RFC3209]
	o EXPLICIT_ROUTE Object (ERO) [RFC3209]		o EXPLICIT_ROUTE Object (ERO) [RFC3209]
	skipping to change at page 17, line 8 ¶		skipping to change at page 17, line 8 ¶
	5.2. PCEP Objects		5.2. PCEP Objects
	PCEP objects are encoded in the "MPLS-TE Policy State Objects" field		PCEP objects are encoded in the "MPLS-TE Policy State Objects" field
	of the MPLS-TE Policy State TLV and consists of PCEP objects defined		of the MPLS-TE Policy State TLV and consists of PCEP objects defined
	in [RFC5440]. Rather than replicating all MPLS TE LSP related		in [RFC5440]. Rather than replicating all MPLS TE LSP related
	objects in this document, the semantics and encodings of the MPLS TE		objects in this document, the semantics and encodings of the MPLS TE
	LSP objects are re-used. These MPLS TE LSP objects are carried in		LSP objects are re-used. These MPLS TE LSP objects are carried in
	the MPLS-TE Policy State TLV.		the MPLS-TE Policy State TLV.
	When carrying PCEP objects, the "Path-Origin" field is set to "PCEP".		When carrying PCEP objects, the "Object-Origin" field is set to
			"PCEP".
	The following PCEP Objects are defined:		The following PCEP Objects are defined:
	o METRIC Object [RFC5440]		o METRIC Object [RFC5440]
	o BANDWIDTH Object [RFC5440]		o BANDWIDTH Object [RFC5440]
	For the MPLS TE LSP Objects listed above, the corresponding sub-		For the MPLS TE LSP Objects listed above, the corresponding sub-
	objects are also applicable to this mechanism. Note that this list		objects are also applicable to this mechanism. Note that this list
	is not exhaustive, other MPLS TE LSP objects which reflect specific		is not exhaustive, other MPLS TE LSP objects which reflect specific
	skipping to change at page 17, line 42 ¶		skipping to change at page 17, line 43 ¶
	This section defines the various TLVs which enable the headend to		This section defines the various TLVs which enable the headend to
	report the state of an SR Policy, its CP(s), SID-List(s) and their		report the state of an SR Policy, its CP(s), SID-List(s) and their
	status. These TLVs are carried in the optional non-transitive BGP		status. These TLVs are carried in the optional non-transitive BGP
	Attribute "LINK_STATE Attribute" defined in [RFC7752] and enable the		Attribute "LINK_STATE Attribute" defined in [RFC7752] and enable the
	same consistent form of reporting for SR Policy state irrespective of		same consistent form of reporting for SR Policy state irrespective of
	the Protocol-Origin used to provision the policy. Detailed procedure		the Protocol-Origin used to provision the policy. Detailed procedure
	is described in Section 7 .		is described in Section 7 .
	6.1. SR Binding SID		6.1. SR Binding SID
	The SR Binding SID (BSID) TLV provides the BSID and its attributes		The SR Binding SID (BSID) is an optional TLV that provides the BSID
	for the SR Policy CP. The TLV MAY also optionally contain the		and its attributes for the SR Policy CP. The TLV MAY also optionally
	Provisioned BSID value for reporting when explicitly provisioned.		contain the Provisioned BSID value for reporting when explicitly
			provisioned.
	The TLV has the following format:		The TLV has the following format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BSID Flags | RESERVED |		| BSID Flags | RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 18, line 38 ¶		skipping to change at page 18, line 38 ¶
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|D|B|U|S|L|F| |		|D|B|U|S|L|F| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	* D-Flag : Indicates the dataplane for the BSIDs and if they are		* D-Flag : Indicates the dataplane for the BSIDs and if they are
	16 octet SRv6 SID when SET and are 4 octet SR/MPLS label value		16 octet SRv6 SID when set and are 4 octet SR/MPLS label value
	when CLEAR.		when clear.
	* B-Flag : Indicates the allocation of the value in the BSID		* B-Flag : Indicates the allocation of the value in the BSID
	field when SET and indicates that BSID is not allocated when		field when set and indicates that BSID is not allocated when
	CLEAR.		clear.
	* U-Flag : Indicates the provisioned BSID value is unavailable		* U-Flag : Indicates the provisioned BSID value is unavailable
	when SET.		when set.
	* S-Flag : Indicates the BSID value in use is specified or		* S-Flag : Indicates the BSID value in use is specified or
	provisioned value when SET and dynamically allocated value when		provisioned value when set and dynamically allocated value when
	CLEAR.		clear.
	* L-Flag : Indicates the BSID value is from the Segment Routing		* L-Flag : Indicates the BSID value is from the Segment Routing
	Local Block (SRLB) of the headend node when SET and is from the		Local Block (SRLB) of the headend node when set and is from the
	local label pool when CLEAR		local label pool when clear
	* F-Flag : Indicates the BSID value is one allocated from dynamic		* F-Flag : Indicates the BSID value is one allocated from dynamic
	range due to fallback (e.g. when specified BSID is unavailable)		range due to fallback (e.g. when specified BSID is unavailable)
	when SET.		when set.
	o RESERVED: 2 octets. SHOULD be set to 0 by originator and MUST be		o RESERVED: 2 octets. SHOULD be set to 0 by originator and MUST be
	ignored by receiver.		ignored by receiver.
	o Binding SID: It indicates the operational or allocated BSID value		o Binding SID: It indicates the operational or allocated BSID value
	for the CP based on the status flags.		for the CP based on the status flags.
	o Provisioned BSID: Optional field used to report the explicitly		o Provisioned BSID: Optional field used to report the explicitly
	provisioned BSID value as indicated by the S-Flag being SET.		provisioned BSID value as indicated by the S-Flag being clear.
	The BSID fields above are 4 octet carrying the MPLS Label or 16		The BSID fields above are 4 octet carrying the MPLS Label or 16
	octets carrying the SRv6 SID based on the BSID D-flag. When carrying		octets carrying the SRv6 SID based on the BSID D-flag. When carrying
	the MPLS Label, as shown in the figure below, the TC, S and TTL		the MPLS Label, as shown in the figure below, the TC, S and TTL
	(total of 12 bits) are RESERVED and SHOULD be set to 0 by originator		(total of 12 bits) are RESERVED and SHOULD be set to 0 by originator
	and MUST be ignored by the receiver.		and MUST be ignored by the receiver.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 20, line 9 ¶		skipping to change at page 20, line 9 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Preference (4 octets) |		| Preference (4 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: TBD (see IANA Considerations Section 9.3)
	o Length: 12 octets		o Length: 12 octets
	o Priority : 1 octet value which indicates the priority of the CP		o Priority : 1 octet value which indicates the priority of the CP.
			Refer Section 2.12 of [I-D.ietf-spring-segment-routing-policy].
	o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be		o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be
	ignored by receiver.		ignored by receiver.
	o Flags: 2 octet field that indicates attribute and status of the		o Flags: 2 octet field that indicates attribute and status of the
	CP. The following bit positions are defined and the semantics are		CP. The following bit positions are defined and the semantics are
	described in detail in [I-D.ietf-spring-segment-routing-policy].		described in detail in [I-D.ietf-spring-segment-routing-policy].
	Other bits SHOULD be cleared by originator and MUST be ignored by		Other bits SHOULD be cleared by originator and MUST be ignored by
	receiver.		receiver.
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S|A|B|E|V|O|D|C|I|T| |		|S|A|B|E|V|O|D|C|I|T| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	* S-Flag : Indicates the CP is in administrative shut state when		* S-Flag : Indicates the CP is in administrative shut state when
	SET		set
	* A-Flag : Indicates the CP is the active path (i.e. one		* A-Flag : Indicates the CP is the active path (i.e. one
	provisioned in the forwarding plane) for the SR Policy when SET		provisioned in the forwarding plane) for the SR Policy when set
	* B-Flag : Indicates the CP is the backup path (i.e. one		* B-Flag : Indicates the CP is the backup path (i.e. one
	identified for path protection of the active path) for the SR		identified for path protection of the active path) for the SR
	Policy when SET		Policy when set
	* E-Flag : Indicates that the CP has been evaluated for validity		* E-Flag : Indicates that the CP has been evaluated for validity
	(e.g. headend may evaluate CPs based on their preferences) when		(e.g. headend may evaluate CPs based on their preferences) when
	SET		set
	* V-Flag : Indicates the CP has at least one valid SID-List when		* V-Flag : Indicates the CP has at least one valid SID-List when
	SET		set
	* O-Flag : Indicates the CP was instantiated by the headend due		* O-Flag : Indicates the CP was instantiated by the headend due
	to an on-demand-nexthop trigger based on local template when		to an on-demand-nexthop trigger based on local template when
	SET		set. Refer Section 8.5 of
			[I-D.ietf-spring-segment-routing-policy].
	* D-Flag : Indicates the CP was delegated for computation to a		* D-Flag : Indicates the CP was delegated for computation to a
	PCE/controller when SET		PCE/controller when set
	* C-Flag : Indicates the CP was provisioned by a PCE/controller		* C-Flag : Indicates the CP was provisioned by a PCE/controller
	when SET		when set
	* I-Flag : Indicates the CP will perform the "drop upon invalid"		* I-Flag : Indicates the CP will perform the "drop upon invalid"
	behavior when no other active path is available for this SR		behavior when no other active path is available for this SR
	Policy and this path is the one with best preference amongst		Policy and this path is the one with best preference amongst
	the available CPs.		the available CPs. Refer Section 8.2 of
			[I-D.ietf-spring-segment-routing-policy].
	* T-Flag : Indicates the CP has been marked as eligible for use		* T-Flag : Indicates the CP has been marked as eligible for use
	as Transit Policy on the headend when SET		as Transit Policy on the headend when set. Refer Section 8.3
			of [I-D.ietf-spring-segment-routing-policy].
	o Preference : 4 octet value which indicates the preference of the		o Preference : 4 octet value which indicates the preference of the
	CP		CP. Refer Section 2.7 of
			[I-D.ietf-spring-segment-routing-policy].
	6.3. SR Candidate Path Name		6.3. SR Candidate Path Name
	The SR Candidate Path Name TLV is an optional TLV that is used to		The SR Candidate Path Name TLV is an optional TLV that is used to
	carry the symbolic name associated with the candidate path. The TLV		carry the symbolic name associated with the candidate path. The TLV
	has the following format:		has the following format:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 21, line 45 ¶		skipping to change at page 21, line 48 ¶
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: TBD (see IANA Considerations Section 9.3)
	o Length: variable		o Length: variable
	o CP Name : Symbolic name for the CP. It is a string of printable		o CP Name : Symbolic name for the CP. It is a string of printable
	ASCII characters without a NULL terminator.		ASCII characters without a NULL terminator.
	6.4. SR Candidate Path Constraints		6.4. SR Candidate Path Constraints
	The SR Candidate Path Constraints TLV is an optional TLV that is used		The SR Candidate Path Constraints TLV is an optional TLV that is used
	to report the contraints associated with the candidate path. The		to report the constraints associated with the candidate path. The
	constraints are generally applied to a dynamic candidate path which		constraints are generally applied to a dynamic candidate path which
	is computed by the headend. The constraints may also be applied to		is computed by the headend. The constraints may also be applied to
	an explicit path where the headend is expected to validate that the		an explicit path where the headend is expected to validate that the
	path expresses satisfies the specified constraints and the path is to		path expresses satisfies the specified constraints and the path is to
	be invalidated by the headend when the constraints are no longer met		be invalidated by the headend when the constraints are no longer met
	(e.g. due to topology changes).		(e.g. due to topology changes).
	The TLV has the following format:		The TLV has the following format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags | Algorithm | RESERVED |		| Flags | RESERVED |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| MTID | Algorithm | RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| sub-TLVs (variable) //		| sub-TLVs (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: TBD (see IANA Considerations Section 9.3)
	o Length: variable		o Length: variable
	o Flags: 2 octet field that indicates the constraints that are being		o Flags: 2 octet field that indicates the constraints that are being
	applied to the CP. The following bit positions are defined and		applied to the CP. The following bit positions are defined and
	the other bits SHOULD be cleared by originator and MUST be ignored		the other bits SHOULD be cleared by originator and MUST be ignored
	by receiver.		by receiver.
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|D|P|U|A| |		|D|P|U|A|T| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	* A-Flag : Indicates that the CP needs to use SRv6 dataplane when		* D-Flag : Indicates that the CP needs to use SRv6 dataplane when
	SET and SR/MPLS dataplane when CLEAR		set and SR/MPLS dataplane when clear
	* P-Flag : Indicates that the CP needs to use only protected SIDs		* P-Flag : Indicates that the CP needs to use only protected SIDs
	when SET		when set
	* U-Flag : Indicates that the CP needs to use only unprotected		* U-Flag : Indicates that the CP needs to use only unprotected
	SIDs when SET		SIDs when set
	* A-Flag : Indicates that the CP needs to use the SIDs belonging		* A-Flag : Indicates that the CP needs to use the SIDs belonging
	to the specified SR Algorithm only when SET		to the specified SR Algorithm only when set
			* T-Flag: Indicates that the CP needs to use the SIDs belonging
			to the specified topology only when set
			o RESERVED: 2 octet. SHOULD be set to 0 by originator and MUST be
			ignored by receiver.
			o MTID : Indicates the multi-topology identifier of the IGP topology
			that is preferred to be used when the path is setup. When the
			T-flag is set then the path is strictly useing the specified
			topology SIDs only.
	o Algorithm : Indicates the algorithm that is preferred to be used		o Algorithm : Indicates the algorithm that is preferred to be used
	when the path is setup. When the A-flag is SET then the path is		when the path is setup. When the A-flag is set then the path is
	strictly using the specified algorithm SIDs only.		strictly using the specified algorithm SIDs only.
	o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be		o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be
	ignored by receiver.		ignored by receiver.
	o sub-TLVs: optional sub-TLVs MAY be included in this TLV to		o sub-TLVs: optional sub-TLVs MAY be included in this TLV to
	describe other constraints.		describe other constraints.
	The following constraint sub-TLVs are defined for the SR CP		The following constraint sub-TLVs are defined for the SR CP
	Constraints TLV.		Constraints TLV.
	skipping to change at page 27, line 28 ¶		skipping to change at page 28, line 10 ¶
	6.5. SR Segment List		6.5. SR Segment List
	The SR Segment List TLV is used to report the SID-List(s) of a		The SR Segment List TLV is used to report the SID-List(s) of a
	candidate path. The TLV has following format:		candidate path. The TLV has following format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags | Algorithm | RESERVED |		| Flags | RESERVED |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| MTID | Algorithm | RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Weight (4 octets) |		| Weight (4 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| sub-TLVs (variable) //		| sub-TLVs (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: TBD (see IANA Considerations Section 9.3)
	o Length: variable		o Length: variable
	o Flags: 1 octet field that indicates attribute and status of the		o Flags: 2 octet field that indicates attribute and status of the
	SID-List.The following bit positions are defined and the semantics		SID-List.The following bit positions are defined and the semantics
	are described in detail in		are described in detail in
	[I-D.ietf-spring-segment-routing-policy]. Other bits SHOULD be		[I-D.ietf-spring-segment-routing-policy]. Other bits SHOULD be
	cleared by originator and MUST be ignored by receiver.		cleared by originator and MUST be ignored by receiver.
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|D|E|C|V|R|C|A| |		|D|E|C|V|R|F|A|T|M| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	* D-Flag : Indicates the SID-List is comprised of SRv6 SIDs when		* D-Flag : Indicates the SID-List is comprised of SRv6 SIDs when
	SET and indicates it is comprised of SR/MPLS labels when CLEAR.		set and indicates it is comprised of SR/MPLS labels when clear.
	* E-Flag : Indicates that SID-List is an explicit path when SET		* E-Flag : Indicates that SID-List is an explicit path when set
	and indicates dynamic path when CLEAR.		and indicates dynamic path when clear.
	* C-Flag : Indicates that SID-List has been computed for a		* C-Flag : Indicates that SID-List has been computed for a
	dynamic path when SET. It is always reported as SET for		dynamic path when set. It is always reported as set for
	explicit paths.		explicit paths.
	* V-Flag : Indicates the SID-List has passed verification or its		* V-Flag : Indicates the SID-List has passed verification or its
	verification was not required when SET and failed verification		verification was not required when set and failed verification
	when CLEAR.		when clear.
	* R-Flag : Indicates that the first Segment has been resolved		* R-Flag : Indicates that the first Segment has been resolved
	when SET and failed resolution when CLEAR.		when set and failed resolution when clear.
	* C-Flag : Indicates that the computation for the dynamic path		* F-Flag : Indicates that the computation for the dynamic path
	failed when SET and succeeded (or not required in case of		failed when set and succeeded (or not required in case of
	explicit path) when CLEAR		explicit path) when clear
	* A-Flag : Indicates that all the SIDs in the SID-List belong to		* A-Flag : Indicates that all the SIDs in the SID-List belong to
	the specified algorithm when SET.		the specified algorithm when set.
	o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be		* T-Flag : Indicates that all the SIDs in the SID-List belong to
			the specified topology (identified by the multi-topology ID)
			when set.
			* M-Flag : Indicates that the SID-list has been removed from the
			forwarding plane due to fault detection by a monitoring
			mechanism (e.g. BFD) when set and indicates no fault detected
			or monitoring is not being done when clear.
			o RESERVED: 2 octet. SHOULD be set to 0 by originator and MUST be
	ignored by receiver.		ignored by receiver.
			o MTID : 2 octet that indicates the multi-topology identifier of the
			IGP topology to be used when the T-flag is set.
	o Algorithm: 1 octet that indicates the algorithm of the SIDs used		o Algorithm: 1 octet that indicates the algorithm of the SIDs used
	in the SID-List when the A-flag is SET.		in the SID-List when the A-flag is set.
			o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be
			ignored by receiver.
	o Weight: 4 octet field that indicates the weight associated with		o Weight: 4 octet field that indicates the weight associated with
	the SID-List for weighted load-balancing		the SID-List for weighted load-balancing. Refer Section 2.2 and
			2.11 of [I-D.ietf-spring-segment-routing-policy].
	o Sub-TLVs : variable and contains the ordered set of Segments and		o Sub-TLVs : variable and contains the ordered set of Segments and
	any other optional attributes associated with the specific SID-		any other optional attributes associated with the specific SID-
	List.		List.
	The SR Segment sub-TLV (defined in Section 6.6) is the only currently		The SR Segment sub-TLV (defined in Section 6.6) MUST be included as
	defined sub-TLV for use with the SR Segment List TLV and it MUST be		an ordered set of sub-TLVs within the SR Segment List TLV when the
	included as an ordered set of sub-TLVs within the SR Segment List TLV		SID-List is not empty. A SID-List may be empty in certain cases
	when the SID-List is not empty. A SID-List may be empty in certain		(e.g. for a dynamic path) where the headend has not yet performed the
	cases (e.g. for a dynamic path) where the headend has not yet		computation and hence not derived the segments required for the path;
	performed the computation and hence not derived the segments required		in such cases, the SR Segment List TLV SHOULD NOT include any SR
	for the path; in such cases, the SR Segment List TLV SHOULD NOT		Segment sub-TLVs.
	include any SR Segment sub-TLVs.
	6.6. SR Segment		6.6. SR Segment
	The SR Segment sub-TLV describes a single segment in a SID-List. One		The SR Segment sub-TLV describes a single segment in a SID-List. One
	or more instances of this sub-TLV in an ordered manner constitute a		or more instances of this sub-TLV in an ordered manner constitute a
	SID-List for a SR Policy candidate path. It is a sub-TLV of the SR		SID-List for a SR Policy candidate path. It is a sub-TLV of the SR
	Segment List TLV and has following format:		Segment List TLV and has following format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Segment Type | RESERVED | Flags |		| Segment Type | RESERVED | Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SID (4 or 16 octets) //		| SID (4 or 16 octets) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// SID Descriptor (variable) //		// Segment Descriptor (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Sub-TLVs (variable) //		// Sub-TLVs (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: TBD (see IANA Considerations Section 9.3)
	o Length: variable		o Length: variable
	skipping to change at page 30, line 14 ¶		skipping to change at page 31, line 6 ¶
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S|E|V|R|A| |		|S|E|V|R|A| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	* S-Flag : Indicates the presence of SID value in the SID field		* S-Flag : Indicates the presence of SID value in the SID field
	when SET and that no value is indicated when CLEAR.		when set and that no value is indicated when clear.
	* E-Flag : Indicates the SID value is explicitly provisioned		* E-Flag : Indicates the SID value is explicitly provisioned
	value (locally on headend or via controller/PCE) when SET and		value (locally on headend or via controller/PCE) when set and
	is a dynamically resolved value by headend when CLEAR		is a dynamically resolved value by headend when clear
	* V-Flag : Indicates the SID has passed verification or did not		* V-Flag : Indicates the SID has passed verification or did not
	require verification when SET and failed verification when		require verification when set and failed verification when
	CLEAR.		clear.
	* R-Flag : Indicates the SID has been resolved or did not require		* R-Flag : Indicates the SID has been resolved or did not require
	resolution (e.g. because it is not the first SID) when SET and		resolution (e.g. because it is not the first SID) when set and
	failed resolution when CLEAR.		failed resolution when clear.
	* A-Flag : Indicates that the Algorithm indicated in the Segment		* A-Flag : Indicates that the Algorithm indicated in the Segment
	descriptor is valid when SET. When CLEAR, it indicates that		descriptor is valid when set. When clear, it indicates that
	the headend is unable to determine the algorithm of the SID.		the headend is unable to determine the algorithm of the SID.
	o SID : 4 octet carrying the MPLS Label or 16 octets carrying the		o SID : 4 octet carrying the MPLS Label or 16 octets carrying the
	SRv6 SID based on the F-flag. When carrying the MPLS Label, as		SRv6 SID based on the Segment Type. When carrying the MPLS Label,
	shown in the figure below, the TC, S and TTL (total of 12 bits)		as shown in the figure below, the TC, S and TTL (total of 12 bits)
	are RESERVED and SHOULD be set to 0 by originator and MUST be		are RESERVED and SHOULD be set to 0 by originator and MUST be
	ignored by the receiver.		ignored by the receiver.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Label | TC |S| TTL |		| Label | TC |S| TTL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o SID Descriptor : variable size SID descriptor based on the type of		o Segment Descriptor : variable size Segment descriptor based on the
	segment (refer Section 6.6.1 for details)		type of segment (refer Section 6.6.1 for details)
	o Sub-Sub-TLVs : variable and contains any other optional attributes		o Sub-Sub-TLVs : variable and contains any other optional attributes
	associated with the specific SID-List.		associated with the specific SID-List.
	Currently no Sub-Sub-TLV of the SR Segment sub-TLV is defined.		Currently no Sub-Sub-TLV of the SR Segment sub-TLV is defined.
	6.6.1. Segment Descriptors		6.6.1. Segment Descriptors
	[I-D.ietf-spring-segment-routing-policy] section 4 defines multiple		[I-D.ietf-spring-segment-routing-policy] section 4 defines multiple
	types of segments and their description. This section defines the		types of segments and their description. This section defines the
	skipping to change at page 32, line 6 ¶		skipping to change at page 32, line 45 ¶
	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
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Algorithm |		| Algorithm |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Where:		Where:
	o Algorithm: 1 octet value that indicates the algorithm used for		o Algorithm: 1 octet value that indicates the algorithm used for
	picking the SID. This is valid only when the A-flag has been SET		picking the SID. This is valid only when the A-flag has been set
	in the Segment TLV.		in the Segment TLV.
	6.6.1.2. Type 2: SRv6 SID		6.6.1.2. Type 2: SRv6 SID
	The Segment is SRv6 type and is specified simply as the SRv6 SID		The Segment is SRv6 type and is specified simply as the SRv6 SID
	address. The format of its Segment Descriptor is as follows:		address. The format of its Segment Descriptor is as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Algorithm |		| Algorithm |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Where:		Where:
	o Algorithm: 1 octet value that indicates the algorithm used for		o Algorithm: 1 octet value that indicates the algorithm used for
	picking the SID. This is valid only when the A-flag has been SET		picking the SID. This is valid only when the A-flag has been set
	in the Segment TLV.		in the Segment TLV.
	6.6.1.3. Type 3: SR-MPLS Prefix SID for IPv4		6.6.1.3. Type 3: SR-MPLS Prefix SID for IPv4
	The Segment is SR-MPLS Prefix SID type and is specified as an IPv4		The Segment is SR-MPLS Prefix SID type and is specified as an IPv4
	node address. The format of its Segment Descriptor is as follows:		node address. The format of its Segment Descriptor is as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	skipping to change at page 38, line 29 ¶		skipping to change at page 39, line 29 ¶
	MUST be ignored by receiver.		MUST be ignored by receiver.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|M|A|B|V| |		|M|A|B|V| |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	where:		where:
	* M-Flag : Indicates that the metric margin allowed for path		* M-Flag : Indicates that the metric margin allowed for path
	computation is specified when SET		computation is specified when set
	* A-Flag : Indicates that the metric margin is specified as an		* A-Flag : Indicates that the metric margin is specified as an
	absolute value when SET and is expressed as a percentage of the		absolute value when set and is expressed as a percentage of the
	minimum metric when CLEAR.		minimum metric when clear.
	* B-Flag : Indicates that the metric bound allowed for the path		* B-Flag : Indicates that the metric bound allowed for the path
	is specified when SET.		is specified when set.
	* V-Flag : Indicates that the metric value computed is being		* V-Flag : Indicates that the metric value computed is being
	reported when SET.		reported when set.
	o RESERVED: 2 octets. SHOULD be set to 0 by originator and MUST be		o RESERVED: 2 octets. SHOULD be set to 0 by originator and MUST be
	ignored by receiver.		ignored by receiver.
	o Metric Margin : 4 octets which indicate the metric margin value		o Metric Margin : 4 octets which indicate the metric margin value
	when M-flag is SET. The metric margin is specified as either an		when M-flag is set. The metric margin is specified as either an
	absolute value or as a percentage of the minimum computed path		absolute value or as a percentage of the minimum computed path
	metric based on the A-flag. The metric margin loosens the		metric based on the A-flag. The metric margin loosens the
	criteria for minimum metric path calculation up to the specified		criteria for minimum metric path calculation up to the specified
	metric to accomodate for other factors such as bandwidth		metric to accomodate for other factors such as bandwidth
	availability, minimal SID stack depth and maximizing of ECMP for		availability, minimal SID stack depth and maximizing of ECMP for
	the SR path computed.		the SR path computed.
	o Metric Bound : 4 octects which indicate the maximum metric value		o Metric Bound : 4 octects which indicate the maximum metric value
	that is allowed when B-flag is SET. If the computed path metric		that is allowed when B-flag is set. If the computed path metric
	crosses the specified bound value then the path is considered as		crosses the specified bound value then the path is considered as
	invalid.		invalid.
	o Metric Value : 4 octets which indicate the metric value of the		o Metric Value : 4 octets which indicate the metric value of the
	computed path when V-flag is SET. This value is available and		computed path when V-flag is set. This value is available and
	reported when the computation is successful and a valid path is		reported when the computation is successful and a valid path is
	available.		available.
	7. Procedures		7. Procedures
	The BGP-LS advertisements for the TE Policy NLRI are originated by		The BGP-LS advertisements for the TE Policy NLRI are originated by
	the headend node for the TE Policies that are instantiated on its		the headend node for the TE Policies that are instantiated on its
	local node.		local node.
	For MPLS TE LSPs signaled via RSVP-TE, the NLRI descriptor TLVs as		For MPLS TE LSPs signaled via RSVP-TE, the NLRI descriptor TLVs as
	skipping to change at page 42, line 15 ¶		skipping to change at page 43, line 15 ¶
	(suggested values, to be assigned by IANA):		(suggested values, to be assigned by IANA):
	+------------+---------------------------------------------------------+		+------------+---------------------------------------------------------+
	| Code Point | Protocol Origin |		| Code Point | Protocol Origin |
	+------------+---------------------------------------------------------+		+------------+---------------------------------------------------------+
	| 1 | PCEP |		| 1 | PCEP |
	| 2 | BGP SR Policy |		| 2 | BGP SR Policy |
	| 3 | Local (via CLI, Yang model through NETCONF, gRPC, etc.) |		| 3 | Local (via CLI, Yang model through NETCONF, gRPC, etc.) |
	+------------+---------------------------------------------------------+		+------------+---------------------------------------------------------+
	9.5. BGP-LS TE State Path Origin		9.5. BGP-LS TE State Object Origin
	This document requests IANA to maintain a new sub-registry under		This document requests IANA to maintain a new sub-registry under
	"Border Gateway Protocol - Link State (BGP-LS) Parameters". The new		"Border Gateway Protocol - Link State (BGP-LS) Parameters". The new
	registry is called "TE State Path Origin" and contains the codepoints		registry is called "TE State Path Origin" and contains the codepoints
	allocated to the "Path Origin" field defined in Section 5. The		allocated to the "Object Origin" field defined in Section 5. The
	registry contains the following codepoints (suggested values, to be		registry contains the following codepoints (suggested values, to be
	assigned by IANA):		assigned by IANA):
	+----------+------------------+		+----------+------------------+
	| Code | Path |		| Code | Object |
	| Point | Origin |		| Point | Origin |
	+----------+------------------+		+----------+------------------+
	| 1 | RSVP-TE |		| 1 | RSVP-TE |
	| 2 | PCEP |		| 2 | PCEP |
	| 3 | Local/Static |		| 3 | Local/Static |
	+----------+------------------+		+----------+------------------+
	9.6. BGP-LS TE State Dataplane		9.6. BGP-LS TE State Address Family
	This document requests IANA to maintain a new sub-registry under		This document requests IANA to maintain a new sub-registry under
	"Border Gateway Protocol - Link State (BGP-LS) Parameters". The new		"Border Gateway Protocol - Link State (BGP-LS) Parameters". The new
	registry is called "TE State Dataplane" and contains the codepoints		registry is called "TE State Address Family" and contains the
	allocated to the "dataplane" field defined in Section 5. The		codepoints allocated to the "Address Family" field defined in
	registry contains the following codepoints (suggested values, to be		Section 5. The registry contains the following codepoints (suggested
	assigned by IANA):		values, to be assigned by IANA):
	+----------+------------------+		+----------+------------------+
	| Code | Dataplane |		| Code | Address |
	| Point | |		| Point | Family |
	+----------+------------------+		+----------+------------------+
	| 1 | MPLS-IPv4 |		| 1 | MPLS-IPv4 |
	| 2 | MPLS-IPv6 |		| 2 | MPLS-IPv6 |
	+----------+------------------+		+----------+------------------+
	9.7. BGP-LS SR Segment Descriptors		9.7. BGP-LS SR Segment Descriptors
	This document requests IANA to maintain a new sub-registry under		This document requests IANA to maintain a new sub-registry under
	"Border Gateway Protocol - Link State (BGP-LS) Parameters". The new		"Border Gateway Protocol - Link State (BGP-LS) Parameters". The new
	registry is called "SR Segment Descriptor Types" and contains the		registry is called "SR Segment Descriptor Types" and contains the
	skipping to change at page 44, line 41 ¶		skipping to change at page 45, line 41 ¶
	Email: cfilsfil@cisco.com		Email: cfilsfil@cisco.com
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[I-D.ietf-spring-segment-routing-policy]		[I-D.ietf-spring-segment-routing-policy]
	Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,		Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
	bogdanov@google.com, b., and P. Mattes, "Segment Routing		bogdanov@google.com, b., and P. Mattes, "Segment Routing
	Policy Architecture", draft-ietf-spring-segment-routing-		Policy Architecture", draft-ietf-spring-segment-routing-
	policy-01 (work in progress), June 2018.		policy-02 (work in progress), October 2018.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.		[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1		Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
	Functional Specification", RFC 2205, DOI 10.17487/RFC2205,		Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
	September 1997, <https://www.rfc-editor.org/info/rfc2205>.		September 1997, <https://www.rfc-editor.org/info/rfc2205>.
	skipping to change at page 46, line 11 ¶		skipping to change at page 47, line 11 ¶
	Element (PCE) Communication Protocol (PCEP)", RFC 5440,		Element (PCE) Communication Protocol (PCEP)", RFC 5440,
	DOI 10.17487/RFC5440, March 2009,		DOI 10.17487/RFC5440, March 2009,
	<https://www.rfc-editor.org/info/rfc5440>.		<https://www.rfc-editor.org/info/rfc5440>.
	[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and		[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
	S. Ray, "North-Bound Distribution of Link-State and		S. Ray, "North-Bound Distribution of Link-State and
	Traffic Engineering (TE) Information Using BGP", RFC 7752,		Traffic Engineering (TE) Information Using BGP", RFC 7752,
	DOI 10.17487/RFC7752, March 2016,		DOI 10.17487/RFC7752, March 2016,
	<https://www.rfc-editor.org/info/rfc7752>.		<https://www.rfc-editor.org/info/rfc7752>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	13.2. Informative References		13.2. Informative References
	[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.		[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
	McManus, "Requirements for Traffic Engineering Over MPLS",		McManus, "Requirements for Traffic Engineering Over MPLS",
	RFC 2702, DOI 10.17487/RFC2702, September 1999,		RFC 2702, DOI 10.17487/RFC2702, September 1999,
	<https://www.rfc-editor.org/info/rfc2702>.		<https://www.rfc-editor.org/info/rfc2702>.
	[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering		[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
	(TE) Extensions to OSPF Version 2", RFC 3630,		(TE) Extensions to OSPF Version 2", RFC 3630,
	DOI 10.17487/RFC3630, September 2003,		DOI 10.17487/RFC3630, September 2003,
	skipping to change at page 47, line 13 ¶		skipping to change at page 48, line 13 ¶
	<https://www.rfc-editor.org/info/rfc7471>.		<https://www.rfc-editor.org/info/rfc7471>.
	[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path		[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
	Computation Element Communication Protocol (PCEP)		Computation Element Communication Protocol (PCEP)
	Extensions for Stateful PCE", RFC 8231,		Extensions for Stateful PCE", RFC 8231,
	DOI 10.17487/RFC8231, September 2017,		DOI 10.17487/RFC8231, September 2017,
	<https://www.rfc-editor.org/info/rfc8231>.		<https://www.rfc-editor.org/info/rfc8231>.
	Authors' Addresses		Authors' Addresses
	Stefano Previdi (editor)		Stefano Previdi
	Email: stefano@previdi.net		Email: stefano@previdi.net
	Ketan Talaulikar		Ketan Talaulikar (editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
			India
	Email: ketant@cisco.com		Email: ketant@cisco.com
	Jie Dong (editor)		Jie Dong (editor)
	Huawei Technologies		Huawei Technologies
	Huawei Campus, No. 156 Beiqing Rd.		Huawei Campus, No. 156 Beiqing Rd.
	Beijing 100095		Beijing 100095
	China		China
	Email: jie.dong@huawei.com		Email: jie.dong@huawei.com
	skipping to change at page 47, line 44 ¶		skipping to change at page 48, line 45 ¶
	China		China
	Email: mach.chen@huawei.com		Email: mach.chen@huawei.com
	Hannes Gredler		Hannes Gredler
	RtBrick Inc.		RtBrick Inc.
	Email: hannes@rtbrick.com		Email: hannes@rtbrick.com
	Jeff Tantsura		Jeff Tantsura
	Nuage Networks		Apstra
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
End of changes. 96 change blocks.
	153 lines changed or deleted		197 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/