< draft-ietf-idr-te-lsp-distribution-11.txt		draft-ietf-idr-te-lsp-distribution-12.txt >
	Network Working Group S. Previdi		Network Working Group S. Previdi
	Internet-Draft		Internet-Draft
	Intended status: Standards Track K. Talaulikar, Ed.		Intended status: Standards Track K. Talaulikar, Ed.
	Expires: November 3, 2019 Cisco Systems, Inc.		Expires: April 16, 2020 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
	Apstra		Apstra
	May 2, 2019		October 14, 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-11		draft-ietf-idr-te-lsp-distribution-12
	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 Link State (BGP-LS) updates. Such		node and advertise it into BGP Link State (BGP-LS) updates. Such
	information can be used by external components for path computation,		information can be used by external components for path computation,
	re-optimization, service placement, network visualization, etc.		re-optimization, service placement, network visualization, etc.
	Requirements Language		Requirements Language
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 November 3, 2019.		This Internet-Draft will expire on April 16, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 4 ¶
	6.4. SR Candidate Path Constraints . . . . . . . . . . . . . . 22		6.4. SR Candidate Path Constraints . . . . . . . . . . . . . . 22
	6.4.1. SR Affinity Constraint . . . . . . . . . . . . . . . 24		6.4.1. SR Affinity Constraint . . . . . . . . . . . . . . . 24
	6.4.2. SR SRLG Constraint . . . . . . . . . . . . . . . . . 25		6.4.2. SR SRLG Constraint . . . . . . . . . . . . . . . . . 25
	6.4.3. SR Bandwidth Constraint . . . . . . . . . . . . . . . 26		6.4.3. SR Bandwidth Constraint . . . . . . . . . . . . . . . 26
	6.4.4. SR Disjoint Group Constraint . . . . . . . . . . . . 26		6.4.4. SR Disjoint Group Constraint . . . . . . . . . . . . 26
	6.5. SR Segment List . . . . . . . . . . . . . . . . . . . . . 28		6.5. SR Segment List . . . . . . . . . . . . . . . . . . . . . 28
	6.6. SR Segment . . . . . . . . . . . . . . . . . . . . . . . 31		6.6. SR Segment . . . . . . . . . . . . . . . . . . . . . . . 31
	6.6.1. Segment Descriptors . . . . . . . . . . . . . . . . . 32		6.6.1. Segment Descriptors . . . . . . . . . . . . . . . . . 32
	6.7. SR Segment List Metric . . . . . . . . . . . . . . . . . 39		6.7. SR Segment List Metric . . . . . . . . . . . . . . . . . 39
	7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 41		7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 41
	8. Manageability Considerations . . . . . . . . . . . . . . . . 42		8. Manageability Considerations . . . . . . . . . . . . . . . . 41
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
	9.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 42		9.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 42
	9.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 42		9.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 42
	9.3. BGP-LS TLVs . . . . . . . . . . . . . . . . . . . . . . . 43		9.3. BGP-LS TLVs . . . . . . . . . . . . . . . . . . . . . . . 42
	9.4. BGP-LS SR Policy Protocol Origin . . . . . . . . . . . . 43		9.4. BGP-LS SR Policy Protocol Origin . . . . . . . . . . . . 43
	9.5. BGP-LS TE State Object Origin . . . . . . . . . . . . . . 44		9.5. BGP-LS TE State Object Origin . . . . . . . . . . . . . . 44
	9.6. BGP-LS TE State Address Family . . . . . . . . . . . . . 44		9.6. BGP-LS TE State Address Family . . . . . . . . . . . . . 44
	9.7. BGP-LS SR Segment Descriptors . . . . . . . . . . . . . . 45		9.7. BGP-LS SR Segment Descriptors . . . . . . . . . . . . . . 44
	9.8. BGP-LS Metric Type . . . . . . . . . . . . . . . . . . . 45		9.8. BGP-LS Metric Type . . . . . . . . . . . . . . . . . . . 45
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 46		10. Security Considerations . . . . . . . . . . . . . . . . . . . 45
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 46		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 46
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 46		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
	13.1. Normative References . . . . . . . . . . . . . . . . . . 46		13.1. Normative References . . . . . . . . . . . . . . . . . . 46
	13.2. Informative References . . . . . . . . . . . . . . . . . 48		13.2. Informative References . . . . . . . . . . . . . . . . . 48
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
	1. Introduction		1. Introduction
	In many network environments, traffic engineering (TE) policies are		In many network environments, traffic engineering (TE) policies are
	skipping to change at page 5, line 50 ¶		skipping to change at page 5, line 50 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| NLRI Type | Total NLRI Length |		| NLRI Type | Total NLRI Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	// Link-State NLRI (variable) //		// Link-State NLRI (variable) //
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	A new "NLRI Type" is defined for TE Policy Information as following:		A new "NLRI Type" is defined for TE Policy Information as following:
	o NLRI Type: TE Policy NLRI (value TBD see IANA Considerations		o NLRI Type: TE Policy NLRI value 5.
	Section 9.1).
	The format of this new NLRI type is defined in Section 3 below.		The format of this new NLRI type is defined in Section 3 below.
	3. TE Policy NLRI		3. TE Policy NLRI
	This document defines the new TE Policy NLRI-Type and its format as		This document defines the new TE Policy NLRI-Type and its format as
	shown in the following figure:		shown in the following figure:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	skipping to change at page 6, line 29 ¶		skipping to change at page 6, line 27 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Headend (Node Descriptors) //		// Headend (Node Descriptors) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// TE Policy Descriptors (variable) //		// TE Policy Descriptors (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Protocol-ID field specifies the component that owns the TE Policy		o Protocol-ID field specifies the component that owns the TE Policy
	state in the advertising node. The following new Protocol-IDs are		state in the advertising node. The following new Protocol-IDs are
	defined (values TBD see IANA Considerations Section 9.2) and apply		defined and apply to the TE Policy NLRI:
	to the TE Policy NLRI:
	+-------------+----------------------------------+		+-------------+----------------------------------+
	| Protocol-ID | NLRI information source protocol |		| Protocol-ID | NLRI information source protocol |
	+-------------+----------------------------------+		+-------------+----------------------------------+
	| TBD | RSVP-TE |		| 8 | RSVP-TE |
	| TBD | Segment Routing |		| 9 | 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 Local Node Descriptor (TLV 256) as defined		o "Headend" consists of a Local Node Descriptor (TLV 256) as defined
	in [RFC7752].		in [RFC7752].
	o "TE Policy Descriptors" consists of one or more of the TLVs listed		o "TE Policy Descriptors" consists of one or more of the TLVs listed
	as below: (values TBD see IANA Considerations Section 9.3):		as below:
	+-----------+----------------------------------+		+-----------+----------------------------------+
	| Codepoint | Descriptor TLVs |		| Codepoint | Descriptor TLVs |
	+-----------+----------------------------------+		+-----------+----------------------------------+
	| TBD | Tunnel ID |		| 550 | Tunnel ID |
	| TBD | LSP ID |		| 551 | LSP ID |
	| TBD | IPv4/6 Tunnel Head-end address |		| 552 | IPv4/6 Tunnel Head-end address |
	| TBD | IPv4/6 Tunnel Tail-end address |		| 553 | IPv4/6 Tunnel Tail-end address |
	| TBD | SR Policy Candidate Path |		| 554 | SR Policy Candidate Path |
	| TBD | Local MPLS Cross Connect |		| 555 | Local MPLS Cross Connect |
	+-----------+----------------------------------+		+-----------+----------------------------------+
	The Local Node Descriptor TLV MUST include the following Node		The Local Node Descriptor TLV MUST include the following Node
	Descriptor TLVs:		Descriptor TLVs:
	o BGP Router-ID (TLV 516) [I-D.ietf-idr-bgpls-segment-routing-epe],		o BGP Router-ID (TLV 516) [I-D.ietf-idr-bgpls-segment-routing-epe],
	which contains a valid BGP Identifier of the local node.		which contains a valid BGP Identifier of the local node.
	o Autonomous System Number (TLV 512) [RFC7752], which contains the		o Autonomous System Number (TLV 512) [RFC7752], which contains the
	ASN or AS Confederation Identifier (ASN) [RFC5065], if		ASN or AS Confederation Identifier (ASN) [RFC5065], if
	skipping to change at page 8, line 21 ¶		skipping to change at page 8, line 21 ¶
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Tunnel ID |		| Tunnel ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 550
	o Length: 2 octets.		o Length: 2 octets.
	o Tunnel ID: 2 octets as defined in [RFC3209].		o Tunnel ID: 2 octets as defined in [RFC3209].
	4.2. LSP Identifier (LSP ID)		4.2. LSP Identifier (LSP ID)
	The LSP Identifier TLV contains the LSP ID defined in [RFC3209] and		The LSP Identifier TLV contains the LSP ID defined in [RFC3209] and
	is used for RSVP-TE protocol TE Policies. It has the following		is used for RSVP-TE protocol TE Policies. It has the following
	format:		format:
	skipping to change at page 8, line 43 ¶		skipping to change at page 8, line 43 ¶
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LSP ID |		| LSP ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 551
	o Length: 2 octets.		o Length: 2 octets.
	o LSP ID: 2 octets as defined in [RFC3209].		o LSP ID: 2 octets as defined in [RFC3209].
	4.3. IPv4/IPv6 Tunnel Head-End Address		4.3. IPv4/IPv6 Tunnel Head-End Address
	The IPv4/IPv6 Tunnel Head-End Address TLV contains the Tunnel Head-		The IPv4/IPv6 Tunnel Head-End Address TLV contains the Tunnel Head-
	End Address defined in [RFC3209] and is used for RSVP-TE protocol TE		End Address defined in [RFC3209] and is used for RSVP-TE protocol TE
	Policies. It has following format:		Policies. It has following format:
	skipping to change at page 9, line 21 ¶		skipping to change at page 9, line 21 ¶
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// IPv4/IPv6 Tunnel Head-End Address (variable) //		// IPv4/IPv6 Tunnel Head-End Address (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 552
	o Length: 4 or 16 octets.		o Length: 4 or 16 octets.
	When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv4		When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv4
	address, its length is 4 (octets).		address, its length is 4 (octets).
	When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv6		When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv6
	address, its length is 16 (octets).		address, its length is 16 (octets).
	4.4. IPv4/IPv6 Tunnel Tail-End Address		4.4. IPv4/IPv6 Tunnel Tail-End Address
	skipping to change at page 9, line 47 ¶		skipping to change at page 9, line 47 ¶
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// IPv4/IPv6 Tunnel Tail-End Address (variable) //		// IPv4/IPv6 Tunnel Tail-End Address (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 553
	o Length: 4 or 16 octets.		o Length: 4 or 16 octets.
	When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv4		When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv4
	address, its length is 4 (octets).		address, its length is 4 (octets).
	When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv6		When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv6
	address, its length is 16 (octets).		address, its length is 16 (octets).
	4.5. SR Policy Candidate Path Descriptor		4.5. SR Policy Candidate Path Descriptor
	skipping to change at page 10, line 35 ¶		skipping to change at page 10, line 35 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Originator AS Number (4 octets) |		| Originator AS Number (4 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Originator Address (4 or 16 octets) //		| Originator Address (4 or 16 octets) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Discriminator (4 octets) |		| Discriminator (4 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 554
	o Length: variable (valid values are 24, 36 or 48 octets)		o Length: variable (valid values are 24, 36 or 48 octets)
	o Protocol-Origin : 1 octet field which identifies the protocol or		o Protocol-Origin : 1 octet field which identifies the protocol or
	component which is responsible for the instantiation of this path.		component which is responsible for the instantiation of this path.
	Following protocol-origin codepoints are defined in this document.		Following protocol-origin codepoints are defined in this document.
	+------------+---------------------------------------------------------+		+------------+---------------------------------------------------------+
	| Code Point | Protocol Origin |		| Code Point | Protocol Origin |
	+------------+---------------------------------------------------------+		+------------+---------------------------------------------------------+
	skipping to change at page 12, line 19 ¶		skipping to change at page 12, line 19 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Incoming label (4 octets) |		| Incoming label (4 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Outgoing label (4 octets) |		| Outgoing label (4 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Sub-TLVs (variable) //		// Sub-TLVs (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 555
	o Length: variable.		o Length: variable.
	o Incoming and Outgoing labels: 4 octets each.		o Incoming and Outgoing labels: 4 octets each.
	o Sub-TLVs: following Sub-TLVs are defined:		o Sub-TLVs: following Sub-TLVs are defined:
	* Interface Sub-TLV		* Interface Sub-TLV
	* Forwarding Equivalent Class (FEC)		* Forwarding Equivalent Class (FEC)
	skipping to change at page 12, line 48 ¶		skipping to change at page 12, line 48 ¶
	MUST contain at least one Interface Sub-TLV having the I-flag		MUST contain at least one Interface Sub-TLV having the I-flag
	unset.		unset.
	MAY contain multiple Interface Sub-TLV having the I-flag unset.		MAY contain multiple Interface Sub-TLV having the I-flag unset.
	This is the case of a multicast MPLS cross connect.		This is the case of a multicast MPLS cross connect.
	MAY contain a FEC Sub-TLV.		MAY contain a FEC Sub-TLV.
	The following sub-TLVs are defined for the Local MPLS Cross Connect		The following sub-TLVs are defined for the Local MPLS Cross Connect
	TLV (values TBD see IANA Considerations Section 9.3):		TLV:
	+-----------+----------------------------------+		+-----------+----------------------------------+
	| Codepoint | Descriptor TLV |		| Codepoint | Descriptor TLV |
	+-----------+----------------------------------+		+-----------+----------------------------------+
	| TBD | MPLS Cross Connect Interface |		| 556 | MPLS Cross Connect Interface |
	| TBD | MPLS Cross Connect FEC |		| 557 | MPLS Cross Connect FEC |
	+-----------+----------------------------------+		+-----------+----------------------------------+
	These are defined in the following sub-sections.		These are defined in the following sub-sections.
	4.6.1. MPLS Cross Connect Interface		4.6.1. MPLS Cross Connect Interface
	The MPLS Cross Connect Interface sub-TLV is optional and contains the		The MPLS Cross Connect Interface sub-TLV is optional and contains the
	identifier of the interface (incoming or outgoing) in the form of an		identifier of the interface (incoming or outgoing) in the form of an
	IPv4 address or an IPv6 address.		IPv4 address or an IPv6 address.
	skipping to change at page 13, line 40 ¶		skipping to change at page 13, line 40 ¶
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Interface Identifier (4 octets) |		| Local Interface Identifier (4 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Interface Address (4 or 16 octets) //		// Interface Address (4 or 16 octets) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 556
	o Length: 9 or 21.		o Length: 9 or 21.
	o Flags: 1 octet of flags defined as follows:		o Flags: 1 octet of flags defined as follows:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|I| |		|I| |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	skipping to change at page 14, line 33 ¶		skipping to change at page 14, line 33 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags | Masklength | Prefix (variable) //		| Flags | Masklength | Prefix (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Prefix (variable) //		// Prefix (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 557
	o Length: variable.		o Length: variable.
	o Flags: 1 octet of flags defined as follows:		o Flags: 1 octet of flags defined as follows:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|4| |		|4| |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	skipping to change at page 15, line 36 ¶		skipping to change at page 15, line 36 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// 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: 1200
	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 Object-origin: identifies the component (or protocol) from which		o Object-origin: identifies the component (or protocol) from which
	the contained object originated. This allows for objects defined		the contained object originated. This allows for objects defined
	in different components to be collected while avoiding the		in different components to be collected while avoiding the
	possible codepoint collisions among these components. Following		possible codepoint collisions among these components. Following
	object-origin codepoints are defined in this document.		object-origin codepoints are defined in this document.
	skipping to change at page 19, line 14 ¶		skipping to change at page 19, line 14 ¶
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Binding SID (4 or 16 octets) //		| Binding SID (4 or 16 octets) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Provisioned Binding SID (optional, 4 or 16 octets) //		| Provisioned Binding SID (4 or 16 octets) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 1201
	o Length: variable (valid values are 12, 16, 24 or 40 octets)		o Length: variable (valid values are 12 or 36 octets)
	o BSID Flags: 2 octet field that indicates attribute and status of		o BSID Flags: 2 octet field that indicates attribute and status of
	the Binding SID (BSID) associated with this CP. The following bit		the Binding SID (BSID) associated with this CP. The following bit
	positions are defined and the semantics are described in detail in		positions are defined and the semantics 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|B|U|S|L|F| |		|D|B|U|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
	provisioned value when set and dynamically allocated value when
	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 dynamic 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)		label pool due to fallback (e.g. when specified BSID is
	when set.		unavailable) 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: It is used to report the explicitly provisioned
	provisioned BSID value as indicated by the S-Flag being clear.		BSID value regardless of whether it is successfully allocated or
			not. The field is set to value 0 when BSID has not been specified
			or provisioned for the CP.
	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 21, line 5 ¶		skipping to change at page 20, line 50 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Priority | RESERVED | Flags |		| Priority | RESERVED | Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Preference (4 octets) |		| Preference (4 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 1202
			o Length: 8 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].		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].
	skipping to change at page 21, line 44 ¶		skipping to change at page 21, line 41 ¶
	* 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. When the E-Flag is clear (i.e. the CP has not been
			evaluated), then this flag MUST be set to 0 by the originator
			and ignored by the receiver.
	* 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. Refer Section 8.5 of		set. Refer Section 8.5 of
	[I-D.ietf-spring-segment-routing-policy].		[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
	skipping to change at page 22, line 38 ¶		skipping to change at page 22, line 38 ¶
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Candidate Path Symbolic Name (variable) //		| Candidate Path Symbolic Name (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 1203
	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 constraints associated with the candidate path. The		to report the constraints associated with the candidate path. The
	skipping to change at page 23, line 23 ¶		skipping to change at page 23, line 23 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags | RESERVED |		| Flags | RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MTID | Algorithm | RESERVED |		| MTID | Algorithm | RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| sub-TLVs (variable) //		| sub-TLVs (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 1204
	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
	skipping to change at page 25, line 5 ¶		skipping to change at page 25, line 5 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Exclude-Any EAG (optional, variable) //		| Exclude-Any EAG (optional, variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Include-Any EAG (optional, variable) //		| Include-Any EAG (optional, variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Include-All EAG (optional, variable) //		| Include-All EAG (optional, variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 1208
	o Length: variable, dependent on the size of the Extended Admin		o Length: variable, dependent on the size of the Extended Admin
	Group. MUST be a multiple of 4 octets.		Group. MUST be a multiple of 4 octets.
	o Exclude-Any-Size : one octet to indicate the size of Exclude-Any		o Exclude-Any-Size : one octet to indicate the size of Exclude-Any
	EAG bitmask size in multiples of 4 octets. (e.g. value 0		EAG bitmask size in multiples of 4 octets. (e.g. value 0
	indicates the Exclude-Any EAG field is skipped, value 1 indicates		indicates the Exclude-Any EAG field is skipped, value 1 indicates
	that 4 octets of Exclude-Any EAG is included)		that 4 octets of Exclude-Any EAG is included)
	o Include-Any-Size : one octet to indicate the size of Include-Any		o Include-Any-Size : one octet to indicate the size of Include-Any
	skipping to change at page 26, line 5 ¶		skipping to change at page 26, line 5 ¶
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SRLG Values (variable, multiples of 4 octets) //		| SRLG Values (variable, multiples of 4 octets) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 1209
	o Length: variable, dependent on the number of SRLGs encoded. MUST		o Length: variable, dependent on the number of SRLGs encoded. MUST
	be a multiple of 4 octets.		be a multiple of 4 octets.
	o SRLG Values : One or more SRLG values (each of 4 octets).		o SRLG Values : One or more SRLG values (each of 4 octets).
	6.4.3. SR Bandwidth Constraint		6.4.3. SR Bandwidth Constraint
	The SR Bandwidth Constraint sub-TLV is an optional sub-TLV that is		The SR Bandwidth Constraint sub-TLV is an optional sub-TLV that is
	used to indicate the desired bandwidth availability that needs to be		used to indicate the desired bandwidth availability that needs to be
	skipping to change at page 26, line 28 ¶		skipping to change at page 26, line 28 ¶
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Bandwidth |		| Bandwidth |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 1210
	o Length: 8 octects		o Length: 4 octects
	o Bandwidth : 4 octets which specify the desired bandwidth in unit		o Bandwidth : 4 octets which specify the desired bandwidth in unit
	of bytes per second in IEEE floating point format.		of bytes per second in IEEE floating point format.
	6.4.4. SR Disjoint Group Constraint		6.4.4. SR Disjoint Group Constraint
	The SR Disjoint Group Constraint sub-TLV is an optional sub-TLV that		The SR Disjoint Group Constraint sub-TLV is an optional sub-TLV that
	is used to carry the disjointness constraint associated with the		is used to carry the disjointness constraint associated with the
	candidate path. The disjointness between two SR Policy Candidate		candidate path. The disjointness between two SR Policy Candidate
	Paths is expressed by associating them with the same disjoint group		Paths is expressed by associating them with the same disjoint group
	skipping to change at page 27, line 17 ¶		skipping to change at page 27, line 17 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Request-Flags | Status-Flags | RESERVED |		| Request-Flags | Status-Flags | RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Disjoint Group Identifier |		| Disjoint Group Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 1211
	o Length: 12 octets		o Length: 8 octets
	o Request Flags : one octet to indicate the level of disjointness		o Request Flags : one octet to indicate the level of disjointness
	requested as specified in the form of flags. The following flags		requested as specified in the form of flags. The following flags
	are defined and the other bits SHOULD be cleared by originator and		are defined and the other bits SHOULD be cleared by originator and
	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
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|S|N|L|F|I| |		|S|N|L|F|I| |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	skipping to change at page 29, line 21 ¶		skipping to change at page 29, line 21 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MTID | Algorithm | 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: 1205
	o Length: variable		o Length: variable
	o Flags: 2 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
	skipping to change at page 31, line 28 ¶		skipping to change at page 31, line 28 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SID (4 or 16 octets) //		| SID (4 or 16 octets) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Segment Descriptor (variable) //		// Segment Descriptor (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// Sub-TLVs (variable) //		// Sub-TLVs (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 1206
	o Length: variable		o Length: variable
	o Segment Type : 1 octet which indicates the type of segment (refer		o Segment Type : 1 octet which indicates the type of segment (refer
	Section 6.6.1 for details)		Section 6.6.1 for details)
	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
	skipping to change at page 33, line 5 ¶		skipping to change at page 33, line 5 ¶
	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
	encoding of the Segment Descriptors for each of those Segment types		encoding of the Segment Descriptors for each of those Segment types
	to be used in the Segment sub-TLV describes previously in		to be used in the Segment sub-TLV describes previously in
	Section 6.6.		Section 6.6.
	The following types are currently defined (suggested values, to be		The following types are currently defined:
	assigned by IANA):
	+-------+--------------------------------------------------------------+		+-------+--------------------------------------------------------------+
	| Type | Segment Description |		| Type | Segment Description |
	+-------+--------------------------------------------------------------+		+-------+--------------------------------------------------------------+
	| 0 | Invalid |		| 0 | Invalid |
	| 1 | SR-MPLS Label |		| 1 | SR-MPLS Label |
	| 2 | SRv6 SID as IPv6 address |		| 2 | SRv6 SID as IPv6 address |
	| 3 | SR-MPLS Prefix SID as IPv4 Node Address |		| 3 | SR-MPLS Prefix SID as IPv4 Node Address |
	| 4 | SR-MPLS Prefix SID as IPv6 Node Global Address |		| 4 | SR-MPLS Prefix SID as IPv6 Node Global Address |
	| 5 | SR-MPLS Adjacency SID as IPv4 Node Address & Local |		| 5 | SR-MPLS Adjacency SID as IPv4 Node Address & Local |
	skipping to change at page 39, line 48 ¶		skipping to change at page 39, line 38 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Metric Margin |		| Metric Margin |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Metric Bound |		| Metric Bound |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Metric Value |		| Metric Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: TBD (see IANA Considerations Section 9.3)		o Type: 1207
			o Length: 16 octets
	o Length: variable
	o Metric Type : 1 octet field which identifies the type of metric		o Metric Type : 1 octet field which identifies the type of metric
	used for path computation. Following metric type codepoints are		used for path computation. Following metric type codepoints are
	defined in this document.		defined in this document.
	+------------+-----------------------------------------+		+------------+-----------------------------------------+
	| Code Point | Metric Type |		| Code Point | Metric Type |
	+------------+-----------------------------------------+		+------------+-----------------------------------------+
	| 0 | IGP Metric |		| 0 | IGP Metric |
	| 1 | Min Unidirectional Link Delay [RFC7471] |		| 1 | Min Unidirectional Link Delay [RFC7471] |
	| 2 | TE Metric [RFC3630] |		| 2 | TE Metric [RFC3630] |
	skipping to change at page 42, line 33 ¶		skipping to change at page 42, line 23 ¶
	9. IANA Considerations		9. IANA Considerations
	This document requires new IANA assigned codepoints.		This document requires new IANA assigned codepoints.
	9.1. BGP-LS NLRI-Types		9.1. BGP-LS NLRI-Types
	IANA maintains a registry called "Border Gateway Protocol - Link		IANA maintains a registry called "Border Gateway Protocol - Link
	State (BGP-LS) Parameters" with a sub-registry called "BGP-LS NLRI-		State (BGP-LS) Parameters" with a sub-registry called "BGP-LS NLRI-
	Types".		Types".
	The following codepoints is suggested (for early allocation by IANA):		The following codepoints have been assigned by early allocation
			process by IANA:
	+------+----------------------------+---------------+		+------+----------------------------+---------------+
	| Type | NLRI Type | Reference |		| Type | NLRI Type | Reference |
	+------+----------------------------+---------------+		+------+----------------------------+---------------+
	| 5 | TE Policy NLRI type | this document |		| 5 | TE Policy NLRI type | this document |
	+------+----------------------------+---------------+		+------+----------------------------+---------------+
	9.2. BGP-LS Protocol-IDs		9.2. BGP-LS Protocol-IDs
	IANA maintains a registry called "Border Gateway Protocol - Link		IANA maintains a registry called "Border Gateway Protocol - Link
	State (BGP-LS) Parameters" with a sub-registry called "BGP-LS		State (BGP-LS) Parameters" with a sub-registry called "BGP-LS
	Protocol-IDs".		Protocol-IDs".
	The following Protocol-ID codepoints are suggested (for early		The following Protocol-ID codepoints have been assigned by early
	allocation by IANA):		allocation process by IANA:
	+-------------+----------------------------------+---------------+		+-------------+----------------------------------+---------------+
	| Protocol-ID | NLRI information source protocol | Reference |		| Protocol-ID | NLRI information source protocol | Reference |
	+-------------+----------------------------------+---------------+		+-------------+----------------------------------+---------------+
	| 8 | RSVP-TE | this document |		| 8 | RSVP-TE | this document |
	| 9 | Segment Routing | this document |		| 9 | Segment Routing | this document |
	+-------------+----------------------------------+---------------+		+-------------+----------------------------------+---------------+
	9.3. BGP-LS TLVs		9.3. BGP-LS TLVs
	IANA maintains a registry called "Border Gateway Protocol - Link		IANA maintains a registry called "Border Gateway Protocol - Link
	State (BGP-LS) Parameters" with a sub-registry called "Node Anchor,		State (BGP-LS) Parameters" with a sub-registry called "Node Anchor,
	Link Descriptor and Link Attribute TLVs".		Link Descriptor and Link Attribute TLVs".
	The following TLV codepoints are suggested (for early allocation by		The following TLV codepoints have been assigned by early allocation
	IANA):		process by IANA:
	+----------+----------------------------------------+---------------+		+----------+----------------------------------------+---------------+
	| TLV Code | Description | Value defined |		| TLV Code | Description | Value defined |
	| Point | | in |		| Point | | in |
	+----------+----------------------------------------+---------------+		+----------+----------------------------------------+---------------+
	| 550 | Tunnel ID TLV | this document |		| 550 | Tunnel ID TLV | this document |
	| 551 | LSP ID TLV | this document |		| 551 | LSP ID TLV | this document |
	| 552 | IPv4/6 Tunnel Head-end address TLV | this document |		| 552 | IPv4/6 Tunnel Head-end address TLV | this document |
	| 553 | IPv4/6 Tunnel Tail-end address TLV | this document |		| 553 | IPv4/6 Tunnel Tail-end address TLV | this document |
	| 554 | SR Policy CP Descriptor TLV | this document |		| 554 | SR Policy CP Descriptor TLV | this document |
	skipping to change at page 44, line 4 ¶		skipping to change at page 43, line 40 ¶
	| 1210 | SR Bandwidth Constraint sub-TLV | this document |		| 1210 | SR Bandwidth Constraint sub-TLV | this document |
	| 1211 | SR Disjoint Group Constraint sub-TLV | this document |		| 1211 | SR Disjoint Group Constraint sub-TLV | this document |
	+----------+----------------------------------------+---------------+		+----------+----------------------------------------+---------------+
	9.4. BGP-LS SR Policy Protocol Origin		9.4. BGP-LS SR Policy Protocol 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 "SR Policy Protocol Origin" and contains the		registry is called "SR Policy Protocol Origin" and contains the
	codepoints allocated to the "Protocol Origin" field defined in		codepoints allocated to the "Protocol Origin" field defined in
	Section 4.5. The registry contains the following codepoints		Section 4.5. The registry contains the following codepoints, with
	(suggested values, to be assigned by IANA):		initial 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 Object 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 "Object 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, with initial values, to
	assigned by IANA):		be assigned by IANA:
	+----------+------------------+		+----------+------------------+
	| Code | Object |		| 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 Address Family		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 Address Family" and contains the		registry is called "TE State Address Family" and contains the
	codepoints allocated to the "Address Family" field defined in		codepoints allocated to the "Address Family" field defined in
	Section 5. The registry contains the following codepoints (suggested		Section 5. The registry contains the following codepoints, with
	values, to be assigned by IANA):		initial values, to be assigned by IANA:
	+----------+------------------+		+----------+------------------+
	| Code | Address |		| Code | Address |
	| Point | Family |		| 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
	codepoints allocated to the "Segment Type" field defined in		codepoints allocated to the "Segment Type" field defined in
	Section 6.6 and described in Section 6.6.1. The registry contains		Section 6.6 and described in Section 6.6.1. The registry contains
	the following codepoints (suggested values, to be assigned by IANA):		the following codepoints, with initial values, to be assigned by
			IANA:
	+-------+--------------------------------------------------------------+		+-------+--------------------------------------------------------------+
	| Code | Segment Description |		| Code | Segment Description |
	| Point | |		| Point | |
	+-------+--------------------------------------------------------------+		+-------+--------------------------------------------------------------+
	| 0 | Invalid |		| 0 | Invalid |
	| 1 | SR-MPLS Label |		| 1 | SR-MPLS Label |
	| 2 | SRv6 SID as IPv6 address |		| 2 | SRv6 SID as IPv6 address |
	| 3 | SR-MPLS Prefix SID as IPv4 Node Address |		| 3 | SR-MPLS Prefix SID as IPv4 Node Address |
	| 4 | SR-MPLS Prefix SID as IPv6 Node Global Address |		| 4 | SR-MPLS Prefix SID as IPv6 Node Global Address |
	skipping to change at page 45, line 44 ¶		skipping to change at page 45, line 35 ¶
	| 11 | SRv6 END.X SID as pair of IPv6 Global Addresses for the |		| 11 | SRv6 END.X SID as pair of IPv6 Global Addresses for the |
	| | Local & Remote Interface |		| | Local & Remote Interface |
	+-------+--------------------------------------------------------------+		+-------+--------------------------------------------------------------+
	9.8. BGP-LS Metric Type		9.8. BGP-LS Metric Type
	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 "Metric Type" and contains the codepoints		registry is called "Metric Type" and contains the codepoints
	allocated to the "metric type" field defined in Section 6.7. The		allocated to the "metric type" field defined in Section 6.7. The
	registry contains the following codepoints (suggested values, to be		registry contains the following codepoints, with initial values, to
	assigned by IANA):		be assigned by IANA:
	+------------+-----------------------------------------+		+------------+-----------------------------------------+
	| Code Point | Metric Type |		| Code Point | Metric Type |
	+------------+-----------------------------------------+		+------------+-----------------------------------------+
	| 0 | IGP Metric |		| 0 | IGP Metric |
	| 1 | Min Unidirectional Link Delay [RFC7471] |		| 1 | Min Unidirectional Link Delay [RFC7471] |
	| 2 | TE Metric [RFC3630] |		| 2 | TE Metric [RFC3630] |
	+------------+-----------------------------------------+		+------------+-----------------------------------------+
	10. Security Considerations		10. Security Considerations
	skipping to change at page 46, line 41 ¶		skipping to change at page 46, line 28 ¶
	and Dhanendra Jain for their review and valuable comments.		and Dhanendra Jain for their review and valuable comments.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[I-D.ietf-idr-bgpls-segment-routing-epe]		[I-D.ietf-idr-bgpls-segment-routing-epe]
	Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray,		Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray,
	S., and J. Dong, "BGP-LS extensions for Segment Routing		S., and J. Dong, "BGP-LS extensions for Segment Routing
	BGP Egress Peer Engineering", draft-ietf-idr-bgpls-		BGP Egress Peer Engineering", draft-ietf-idr-bgpls-
	segment-routing-epe-18 (work in progress), March 2019.		segment-routing-epe-19 (work in progress), May 2019.
	[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-02 (work in progress), October 2018.		policy-03 (work in progress), May 2019.
	[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>.
End of changes. 58 change blocks.
	81 lines changed or deleted		79 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/