< 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: January 9, 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		July 8, 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 January 9, 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 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: TBD (see IANA Considerations Section 9.3)
	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 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 46, line 41 ¶		skipping to change at page 46, line 41 ¶
	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. 14 change blocks.
	19 lines changed or deleted		19 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/