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/