draft-ietf-isis-te-app-05.txt		draft-ietf-isis-te-app-06.txt
	Networking Working Group L. Ginsberg		Networking Working Group L. Ginsberg
	Internet-Draft P. Psenak		Internet-Draft P. Psenak
	Intended status: Standards Track Cisco Systems		Intended status: Standards Track Cisco Systems
	Expires: April 20, 2019 S. Previdi		Expires: October 10, 2019 S. Previdi
	Huawei		Huawei
	W. Henderickx		W. Henderickx
	Nokia		Nokia
	J. Drake		J. Drake
	Juniper Networks		Juniper Networks
	October 17, 2018		April 8, 2019
	IS-IS TE Attributes per application		IS-IS TE Attributes per application
	draft-ietf-isis-te-app-05.txt		draft-ietf-isis-te-app-06.txt
	Abstract		Abstract
	Existing traffic engineering related link attribute advertisements		Existing traffic engineering related link attribute advertisements
	have been defined and are used in RSVP-TE deployments. In cases		have been defined and are used in RSVP-TE deployments. In cases
	where multiple applications wish to make use of these link attributes		where multiple applications wish to make use of these link attributes
	the current advertisements do not support application specific values		the current advertisements do not support application specific values
	for a given attribute nor do they support indication of which		for a given attribute nor do they support indication of which
	applications are using the advertised value for a given link.		applications are using the advertised value for a given link.
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at 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 April 20, 2019.		This Internet-Draft will expire on October 10, 2019.
	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 3, line 13 ¶		skipping to change at page 3, line 13 ¶
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	11.1. Normative References . . . . . . . . . . . . . . . . . . 15		11.1. Normative References . . . . . . . . . . . . . . . . . . 15
	11.2. Informative References . . . . . . . . . . . . . . . . . 16		11.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	Advertisement of link attributes by the Intermediate-System-to-		Advertisement of link attributes by the Intermediate-System-to-
	Intermediate-System (IS-IS) protocol in support of traffic		Intermediate-System (IS-IS) protocol in support of traffic
	engineering (TE) was introduced by [RFC5305] and extended by		engineering (TE) was introduced by [RFC5305] and extended by
	[RFC5307], [RFC6119], and [RFC7810]. Use of these extensions has		[RFC5307], [RFC6119], and [RFC8570]. Use of these extensions has
	been associated with deployments supporting Traffic Engineering over		been associated with deployments supporting Traffic Engineering over
	Multiprotocol Label Switching (MPLS) in the presence of Resource		Multiprotocol Label Switching (MPLS) in the presence of Resource
	Reservation Protocol (RSVP) - more succinctly referred to as RSVP-TE.		Reservation Protocol (RSVP) - more succinctly referred to as RSVP-TE.
	In recent years new applications have been introduced which have use		In recent years new applications have been introduced which have use
	cases for many of the link attributes historically used by RSVP-TE.		cases for many of the link attributes historically used by RSVP-TE.
	Such applications include Segment Routing Traffic Engineering (SRTE)		Such applications include Segment Routing Traffic Engineering (SRTE)
	and Loop Free Alternates (LFA). This has introduced ambiguity in		and Loop Free Alternates (LFA). This has introduced ambiguity in
	that if a deployment includes a mix of RSVP-TE support and SRTE		that if a deployment includes a mix of RSVP-TE support and SRTE
	support (for example) it is not possible to unambiguously indicate		support (for example) it is not possible to unambiguously indicate
	skipping to change at page 4, line 13 ¶		skipping to change at page 4, line 13 ¶
	are:		are:
	1. Support for indicating which applications are using the link		1. Support for indicating which applications are using the link
	attribute advertisements on a link		attribute advertisements on a link
	2. Support for advertising application specific values for the same		2. Support for advertising application specific values for the same
	attribute on a link		attribute on a link
	[RFC7855] discusses use cases/requirements for SR. Included among		[RFC7855] discusses use cases/requirements for SR. Included among
	these use cases is SRTE which is defined in		these use cases is SRTE which is defined in
	[I-D.filsfils-spring-segment-routing-policy]. If both RSVP-TE and		[I-D.ietf-spring-segment-routing-policy]. If both RSVP-TE and SRTE
	SRTE are deployed in a network, link attribute advertisements can be		are deployed in a network, link attribute advertisements can be used
	used by one or both of these applications. As there is no		by one or both of these applications. As there is no requirement for
	requirement for the link attributes advertised on a given link used		the link attributes advertised on a given link used by SRTE to be
	by SRTE to be identical to the link attributes advertised on that		identical to the link attributes advertised on that same link used by
	same link used by RSVP-TE, there is a clear requirement to indicate		RSVP-TE, there is a clear requirement to indicate independently which
	independently which link attribute advertisements are to be used by		link attribute advertisements are to be used by each application.
	each application.
	As the number of applications which may wish to utilize link		As the number of applications which may wish to utilize link
	attributes may grow in the future, an additional requirement is that		attributes may grow in the future, an additional requirement is that
	the extensions defined allow the association of additional		the extensions defined allow the association of additional
	applications to link attributes without altering the format of the		applications to link attributes without altering the format of the
	advertisements or introducing new backwards compatibility issues.		advertisements or introducing new backwards compatibility issues.
	Finally, there may still be many cases where a single attribute value		Finally, there may still be many cases where a single attribute value
	can be shared among multiple applications, so the solution must		can be shared among multiple applications, so the solution must
	minimize advertising duplicate link/attribute pairs whenever		minimize advertising duplicate link/attribute pairs whenever
	skipping to change at page 8, line 18 ¶		skipping to change at page 8, line 18 ¶
	Application bits and are NOT managed by IANA or any other standards		Application bits and are NOT managed by IANA or any other standards
	body. It is recommended that bits are used starting with Bit 0 so as		body. It is recommended that bits are used starting with Bit 0 so as
	to minimize the number of octets required to advertise all UDAs.		to minimize the number of octets required to advertise all UDAs.
	4.2. Application Specific Link Attributes sub-TLV		4.2. Application Specific Link Attributes sub-TLV
	A new sub-TLV for TLVs 22, 23, 141, 222, and 223 is defined which		A new sub-TLV for TLVs 22, 23, 141, 222, and 223 is defined which
	supports specification of the applications and application specific		supports specification of the applications and application specific
	attribute values.		attribute values.
	Type: 16 (suggested value - to be assigned by IANA)		Type: 16 (temporarily assigned by IANA)
	Length: Variable (1 octet)		Length: Variable (1 octet)
	Value:		Value:
	Application Bit Mask (as defined in Section 3.1)		Application Bit Mask (as defined in Section 3.1)
	Link Attribute sub-sub-TLVs - format matches the		Link Attribute sub-sub-TLVs - format matches the
	existing formats defined in [RFC5305] and [RFC7810]		existing formats defined in [RFC5305] and [RFC8570]
	When the L-flag is set in the Application Identifiers, all of the		When the L-flag is set in the Application Identifiers, all of the
	applications specified in the bit mask MUST use the link attribute		applications specified in the bit mask MUST use the link attribute
	sub-TLV advertisements listed in Section 3.1 for the corresponding		sub-TLV advertisements listed in Section 3.1 for the corresponding
	link. Application specific link attribute sub-sub-TLVs for the		link. Application specific link attribute sub-sub-TLVs for the
	corresponding link attributes MUST NOT be advertised for the set of		corresponding link attributes MUST NOT be advertised for the set of
	applications specified in the Standard/User Application Bit Masks and		applications specified in the Standard/User Application Bit Masks and
	all such advertisements MUST be ignored on receipt.		all such advertisements MUST be ignored on receipt.
	Multiple sub-TLVs for the same link MAY be advertised. When multiple		Multiple sub-TLVs for the same link MAY be advertised. When multiple
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 5 ¶
	4.3. Application Specific SRLG TLV		4.3. Application Specific SRLG TLV
	A new TLV is defined to advertise application specific SRLGs for a		A new TLV is defined to advertise application specific SRLGs for a
	given link. Although similar in functionality to TLV 138 (defined by		given link. Although similar in functionality to TLV 138 (defined by
	[RFC5307]) and TLV 139 (defined by [RFC6119], a single TLV provides		[RFC5307]) and TLV 139 (defined by [RFC6119], a single TLV provides
	support for IPv4, IPv6, and unnumbered identifiers for a link.		support for IPv4, IPv6, and unnumbered identifiers for a link.
	Unlike TLVs 138/139, it utilizes sub-TLVs to encode the link		Unlike TLVs 138/139, it utilizes sub-TLVs to encode the link
	identifiers in order to provide the flexible formatting required to		identifiers in order to provide the flexible formatting required to
	support multiple link identifier types.		support multiple link identifier types.
	Type: 238 (Suggested value - to be assigned by IANA)		Type: 238 (Temporarily assigned by IANA)
	Length: Number of octets in the value field (1 octet)		Length: Number of octets in the value field (1 octet)
	Value:		Value:
	Neighbor System-ID + pseudo-node ID (7 octets)		Neighbor System-ID + pseudo-node ID (7 octets)
	Application Bit Mask (as defined in Section 3.1)		Application Bit Mask (as defined in Section 3.1)
	Length of sub-TLVs (1 octet)		Length of sub-TLVs (1 octet)
	Link Identifier sub-TLVs (variable)		Link Identifier sub-TLVs (variable)
	0 or more SRLG Values (Each value is 4 octets)		0 or more SRLG Values (Each value is 4 octets)
	The following Link Identifier sub-TLVs are defined. The type		The following Link Identifier sub-TLVs are defined. The type
	values are suggested and will be assigned by IANA - but as		values are suggested and will be assigned by IANA - but as
	skipping to change at page 11, line 36 ¶		skipping to change at page 11, line 36 ¶
	the existence of link attribute advertisements		the existence of link attribute advertisements
	In the case of LFA, advertisement of application specific link		In the case of LFA, advertisement of application specific link
	attributes does NOT indicate enablement of LFA on that link.		attributes does NOT indicate enablement of LFA on that link.
	Enablement is controlled by local configuration.		Enablement is controlled by local configuration.
	In the case of Flex-Algo, advertisement of application specific link		In the case of Flex-Algo, advertisement of application specific link
	attributes does NOT indicate enablement of Flex-Algo. Rather the		attributes does NOT indicate enablement of Flex-Algo. Rather the
	attributes are used to determine what links are included/excluded in		attributes are used to determine what links are included/excluded in
	the algorithm specific constrained SPF. This is fully specified in		the algorithm specific constrained SPF. This is fully specified in
	[I-D.hegdeppsenak-isis-sr-flex-algo].		[I-D.ietf-lsr-flex-algo].
	If, in the future, additional standard applications are defined to		If, in the future, additional standard applications are defined to
	use this mechanism, the specification defining this use MUST define		use this mechanism, the specification defining this use MUST define
	the relationship between application specific link attribute		the relationship between application specific link attribute
	advertisements and enablement for that application.		advertisements and enablement for that application.
	This document allows the advertisement of application specific link		This document allows the advertisement of application specific link
	attributes with no application identifiers i.e., both the Standard		attributes with no application identifiers i.e., both the Standard
	Application Bit Mask and the User Defined Application Bit Mask are		Application Bit Mask and the User Defined Application Bit Mask are
	not present (See Section 4.1). This supports the use of the link		not present (See Section 4.1). This supports the use of the link
	skipping to change at page 16, line 18 ¶		skipping to change at page 16, line 18 ¶
	2009, <https://www.rfc-editor.org/info/rfc5310>.		2009, <https://www.rfc-editor.org/info/rfc5310>.
	[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic		[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
	Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,		Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
	February 2011, <https://www.rfc-editor.org/info/rfc6119>.		February 2011, <https://www.rfc-editor.org/info/rfc6119>.
	[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code		[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
	Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January		Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
	2014, <https://www.rfc-editor.org/info/rfc7120>.		2014, <https://www.rfc-editor.org/info/rfc7120>.
	[RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
	Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
	RFC 7810, DOI 10.17487/RFC7810, May 2016,
	<https://www.rfc-editor.org/info/rfc7810>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
			D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
			Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
			2019, <https://www.rfc-editor.org/info/rfc8570>.
	11.2. Informative References		11.2. Informative References
	[I-D.filsfils-spring-segment-routing-policy]		[I-D.ietf-lsr-flex-algo]
	Filsfils, C., Sivabalan, S., Hegde, S.,		Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
	daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com,		A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
	b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B.,		algo-01 (work in progress), November 2018.
	Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste,
	J., Clad, F., and K. Raza, "Segment Routing Policy
	Architecture", draft-filsfils-spring-segment-routing-
	policy-06 (work in progress), May 2018.
	[I-D.hegdeppsenak-isis-sr-flex-algo]		[I-D.ietf-spring-segment-routing-policy]
	Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS		Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
	Segment Routing Flexible Algorithm", draft-hegdeppsenak-		bogdanov@google.com, b., and P. Mattes, "Segment Routing
	isis-sr-flex-algo-02 (work in progress), February 2018.		Policy Architecture", draft-ietf-spring-segment-routing-
			policy-02 (work in progress), October 2018.
	[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,		[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
	Litkowski, S., Horneffer, M., and R. Shakir, "Source		Litkowski, S., Horneffer, M., and R. Shakir, "Source
	Packet Routing in Networking (SPRING) Problem Statement		Packet Routing in Networking (SPRING) Problem Statement
	and Requirements", RFC 7855, DOI 10.17487/RFC7855, May		and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
	2016, <https://www.rfc-editor.org/info/rfc7855>.		2016, <https://www.rfc-editor.org/info/rfc7855>.
	Authors' Addresses		Authors' Addresses
	Les Ginsberg		Les Ginsberg
End of changes. 15 change blocks.
	35 lines changed or deleted		31 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/