IS-IS TE Attributes per
applicationCisco Systems821 Alder DriveMilpitas95035CAUSAginsberg@cisco.comCisco SystemsApollo Business Center Mlynske nivy 43Bratislava821 09Slovakiappsenak@cisco.comHuaweistefano@previdi.netNokiaCopernicuslaan 50Antwerp2018 94089Belgiumwim.henderickx@nokia.comJuniper Networksjdrake@juniper.net
Routing Area
Networking Working GroupExisting traffic engineering related link attribute advertisements
have been defined and are used in RSVP-TE deployments. Since the
original RSVP-TE use case was defined, additional applications (e.g.,
Segment Routing Traffic Engineering, Loop Free Alternate) have been
defined which also make use of the link attribute advertisements. In
cases where multiple applications wish to make use of these link
attributes the current advertisements do not support application
specific values for a given attribute nor do they support indication of
which applications are using the advertised value for a given link. This
document introduces new link attribute advertisements which address both
of these shortcomings.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
[RFC2119] [RFC8174] when, and only when, they appear in all capitals, as
shown here.Advertisement of link attributes by the
Intermediate-System-to-Intermediate-System (IS-IS) protocol in support
of traffic engineering (TE) was introduced by [RFC5305] and extended by
[RFC5307], [RFC6119], [RFC7308], and [RFC8570]. Use of these extensions
has been associated with deployments supporting Traffic Engineering over
Multiprotocol Label Switching (MPLS) in the presence of the Resource
Reservation Protocol (RSVP) - more succinctly referred to as RSVP-TE
.For the purposes of this document an application is a technology
which makes use of link attribute advertisements - examples of which are
listed in .In recent years new applications have been introduced which have use
cases for many of the link attributes historically used by RSVP-TE. Such
applications include Segment Routing Traffic Engineering (SRTE) and Loop Free
Alternates (LFA) . This has introduced ambiguity
in that if a deployment includes a mix of RSVP-TE support and SRTE
support (for example) it is not possible to unambiguously indicate which
advertisements are to be used by RSVP-TE and which advertisements are to
be used by SRTE. If the topologies are fully congruent this may not be
an issue, but any incongruence leads to ambiguity.An additional issue arises in cases where both applications are
supported on a link but the link attribute values associated with each
application differ. Current advertisements do not support advertising
application specific values for the same attribute on a specific
link.This document defines extensions which address these issues. Also, as
evolution of use cases for link attributes can be expected to continue
in the years to come, this document defines a solution which is easily
extensible to the introduction of new applications and new use
cases.As stated previously, evolution of use cases for link attributes can
be expected to continue - so any discussion of existing use cases is
limited to requirements which are known at the time of this writing.
However, in order to determine the functionality required beyond what
already exists in IS-IS, it is only necessary to discuss use cases which
justify the key points identified in the introduction - which are:Support for indicating which applications are using the link
attribute advertisements on a linkSupport for advertising application specific values for the same
attribute on a link[RFC7855] discusses use cases/requirements for SR. Included
among these use cases is SRTE which is defined in . If both RSVP-TE and
SRTE are deployed in a network, link attribute advertisements can be
used by one or both of these applications. As there is no requirement
for the link attributes advertised on a given link used by SRTE to be
identical to the link attributes advertised on that same link used by
RSVP-TE, there is a clear requirement to indicate independently which
link attribute advertisements are to be used by each application.As the number of applications which may wish to utilize link
attributes may grow in the future, an additional requirement is that the
extensions defined allow the association of additional applications to
link attributes without altering the format of the advertisements or
introducing new backwards compatibility issues.Finally, there may still be many cases where a single attribute value
can be shared among multiple applications, so the solution must minimize
advertising duplicate link/attribute pairs whenever possible.There are existing advertisements used in support of RSVP-TE. These
advertisements include sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223
and TLVs for Shared Risk Link Group(SRLG) advertisement.Sub-TLV values are defined in
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
and
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml
.Note that [RFC6119] prohibits the use of TLV 139 when it is
possible to use TLV 138.Two new code points are defined in support of Application Specific
Link Attribute Advertisements:1) Application Specific Link Attributes sub-TLV for TLVs 22, 23, 25,
141, 222, and 223 (defined in ).2)Application Specific Shared Risk Link Group (SRLG) TLV (defined in
).In support of these new advertisements, an application identifier bit
mask is defined which identifies the application(s) associated with a
given advertisement (defined in ).The following sections define the format of these new
advertisements.Identification of the set of applications associated with link
attribute advertisements utilizes two bit masks. One bit mask is for
standard applications where the definition of each bit is defined in a
new IANA controlled registry. A second bit mask is for non-standard
User Defined Applications (UDAs).The encoding defined below is used by both the Application Specific
Link Attributes sub-TLV and the Application Specific SRLG TLV.NOTE: SABM/UDABM Length is arbitrarily limited to 8 octets
in order to insure that sufficient space is left to advertise link
attributes without overrunning the maximum length of a sub-TLV.Standard Application Identifier Bits are defined/sent starting with
Bit 0. Undefined bits MUST be transmitted as 0 and MUST be ignored on
receipt. Bits that are NOT transmitted MUST be treated as if they are
set to 0 on receipt. Bits that are not supported by an implementation
MUST be ignored on receipt.User Defined Application Identifier Bits have no relationship to
Standard Application Identifier 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 to minimize the number of octets required to
advertise all UDAs.A new sub-TLV for TLVs 22, 23, 25, 141, 222, and 223 is defined
which supports specification of the applications and application
specific attribute values.When the L-flag is set in the Application Identifier Bit Mask, all
of the applications specified in the bit mask MUST use the legacy
advertisements for the corresponding link found in TLVs 22, 23, 25,
141, 222, and 223 or TLV 138 or TLV 139 as appropriate. Link attribute
sub-sub-TLVs for the corresponding link attributes MUST NOT be
advertised for the set of applications specified in the Standard/User
Application Identifier Bit Masks and all such advertisements MUST be
ignored on receipt.Multiple Application Specific Link Attribute sub-TLVs for the same
link MAY be advertised. When multiple sub-TLVs for the same link are
advertised, they SHOULD advertise non-conflicting
application/attribute pairs. A conflict exists when the same
application is associated with two different values of the same link
attribute for a given link. In cases where conflicting values for the
same application/attribute/link are advertised all the conflicting
values MUST be ignored.For a given application, the setting of the L-flag MUST be the same
in all sub-TLVs for a given link. In cases where this constraint is
violated, the L-flag MUST be considered set for this application.A new registry of sub-sub-TLVs is to be created by IANA which
defines the link attribute sub-sub-TLV code points. This document
defines a sub-sub-TLV for each of the existing sub-TLVs listed in
except as noted below. The format of the
sub-sub-TLVs matches the format of the corresponding legacy sub-TLV
and IANA is requested to assign the legacy sub-TLV identifier to the
corresponding sub-sub-TLV.Maximum link bandwidth is an application independent attribute of
the link. When advertised using the Application Specific Link
Attributes sub-TLV, multiple values for the same link MUST NOT be
advertised. This can be accomplished most efficiently by having a
single advertisement for a given link where the Application
Identifier Bit Mask identifies all the applications which are making
use of the value for that link.It is also possible to advertise the same value for a given link
multiple times with disjoint sets of applications specified in the
Application Identifier Bit Mask. This is less efficient but still
valid.If different values for Maximum Link Bandwidth for a given link
are advertised, all values MUST be ignored.Maximum Reservable Link Bandwidth and Unreserved Bandwidth are
attributes specific to RSVP-TE. When advertised using the
Application Specific Link Attributes sub-TLV, bits other than the
RSVP-TE (R-bit) MUST NOT be set in the Application Identifier Bit
Mask. If an advertisement of Maximum Reservable Link Bandwidth or
Unreserved Bandwidth is received with bits other than the RSVP-TE
bit set, the advertisement MUST be ignored. defines a number of dynamic performance
metrics associated with a link. It is conceivable that such metrics
could be measured specific to traffic associated with a specific
application. Therefore this document includes support for
advertising these link attributes specific to a given application.
However, in practice it may well be more practical to have these
metrics reflect the performance of all traffic on the link
regardless of application. In such cases, advertisements for these
attributes will be associated with all of the applications utilizing
that link.A new TLV is defined to advertise application specific SRLGs for a
given link. Although similar in functionality to TLV 138 [RFC5307] and
TLV 139 [RFC6119], a single TLV provides support for IPv4, IPv6, and
unnumbered identifiers for a link. Unlike TLVs 138/139, it utilizes
sub-TLVs to encode the link identifiers in order to provide the
flexible formatting required to support multiple link identifier
types.At least one set of link identifiers (IPv4, IPv6, or Link
Local/Remote) MUST be present. TLVs which do not meet this requirement
MUST be ignored.Multiple TLVs for the same link MAY be advertised.When the L-flag is set in the Application Identifier Bit Mask, SRLG
values MUST NOT be included in the TLV. Any SRLG values which are
advertised MUST be ignored. Based on the link identifiers advertised
the corresponding legacy TLV (see ) can be
identified and the SRLG values advertised in the legacy TLV MUST be
used by the set of applications specified in the Application
Identifier Bit Mask.For a given application, the setting of the L-flag MUST be the same
in all TLVs for a given link. In cases where this constraint is
violated, the L-flag MUST be considered set for this application.This document defines extensions to support the advertisement of
application specific link attributes.Whether the presence of link attribute advertisements for a given
application indicates that the application is enabled on that link
depends upon the application. Similarly, whether the absence of link
attribute advertisements indicates that the application is not enabled
depends upon the application.In the case of RSVP-TE, the advertisement of application specific
link attributes implies that RSVP is enabled on that link. The absence
of RSVP-TE application specific link attributes in combination with the
absence of legacy advertisements implies that RSVP is NOT enabled on
that link.In the case of SRTE, advertisement of application specific link
attributes does NOT indicate enablement of SRTE. The advertisements are
only used to support constraints which may be applied when specifying an
explicit path. SRTE is implicitly enabled on all links which are part of
the Segment Routing enabled topology independent of the existence of
link attribute advertisementsIn the case of LFA, advertisement of application specific link
attributes does NOT indicate enablement of LFA on that link. Enablement
is controlled by local configuration.If, in the future, additional standard applications are defined to
use this mechanism, the specification defining this use MUST define the
relationship between application specific link attribute advertisements
and enablement for that application.This document allows the advertisement of application specific link
attributes with no application identifiers i.e., both the Standard
Application Identifier Bit Mask and the User Defined Application
Identifier Bit Mask are not present (See Section 4.1). This supports the
use of the link attribute by any application. In the presence of an
application where the advertisement of link attribute advertisements is
used to infer the enablement of an application on that link (e.g.,
RSVP-TE), the absence of the application identifier leaves ambiguous
whether that application is enabled on such a link. This needs to be
considered when making use of the "any application" encoding.This section discuss deployment considerations associated with the
use of application specific link attribute advertisements.Bit Identifiers for Standard Applications are defined in . All of the identifiers defined in this document are
associated with applications which were already deployed in some
networks prior to the writing of this document. Therefore, such
applications have been deployed using the legacy advertisements. The
Standard Applications defined in this document may continue to use
legacy advertisements for a given link so long as at least one of the
following conditions is true:The application is RSVP-TEThe application is SRTE or LFA and RSVP-TE is not deployed
anywhere in the networkThe application is SRTE or LFA, RSVP-TE is deployed in the
network, and both the set of links on which SRTE and/or LFA
advertisements are required and the attribute values used by SRTE
and/or LFA on all such links is fully congruent with the links and
attribute values used by RSVP-TEUnder the conditions defined above, implementations which support
the extensions defined in this document have the choice of using
legacy advertisements or application specific advertisements in
support of SRTE and/or LFA. This will require implementations to
provide controls specifying which type of advertisements are to be
sent/processed on receive for these applications. Further discussion
of the associated issues can be found in .New applications which future documents define to make use of the
advertisements defined in this document MUST NOT make use of legacy
advertisements. This simplifies deployment of new applications by
eliminating the need to support multiple ways to advertise attributes
for the new applications.If link attributes are advertised associated with zero length
Application Identifier Bit Masks for both standard applications and
user defined applications, then any Standard Application and/or any
User Defined Application is permitted to use that set of link
attributes so long as there is not another set of attributes
advertised on that same link which is associated with a non-zero
length Application Identifier Bit Mask with a matching Application
Identifier Bit set. If support for a new application is introduced on
any node in a network in the presence of such advertisements, these
advertisements are permitted to be used by the new application. If
this is not what is intended, then existing advertisements MUST be
readvertised with an explicit set of applications specified before a
new application is introduced.Existing deployments of RSVP-TE, SRTE, and/or LFA utilize the
legacy advertisements listed in Section 3. Routers which do not
support the extensions defined in this document will only process
legacy advertisements and are likely to infer that RSVP-TE is enabled
on the links for which legacy advertisements exist. It is expected
that deployments using the legacy advertisements will persist for a
significant period of time. Therefore deployments using the extensions
defined in this document must be able to co-exist with use of the
legacy advertisements by routers which do not support the extensions
defined in this document. The following sub-sections discuss
interoperability and backwards compatibility concerns for a number of
deployment scenarios.In cases where multiple applications are utilizing a given link,
one of the applications is RSVP-TE, and all link attributes for a
given link are common to the set of applications utilizing that
link, interoperability is achieved by using legacy advertisements
and sending application specific advertisements with L-flag set and
no link attribute values. This avoids duplication of link attribute
advertisements.In cases where one or more applications other than RSVP-TE are
utilizing a given link and one or more link attribute values are NOT
shared with RSVP-TE, it is necessary to use application specific
advertisements as defined in this document. Attributes for
applications other than RSVP-TE MUST be advertised using application
specific advertisements which have the L-flag clear. In cases where
some link attributes are shared with RSVP-TE, this requires
duplicate advertisements for those attributes.The discussion in this section applies to cases where RSVP-TE is
NOT using any advertised attributes on a link and to cases where
RSVP-TE is using some link attribute advertisements on the link but
some link attributes cannot be shared with RSVP-TE.For the applications defined in this document, routers which do
not support the extensions defined in this document will send and
receive only legacy link attribute advertisements. So long as there
is any legacy router in the network which has any of the
applications enabled, all routers MUST continue to advertise link
attributes using legacy advertisements. In addition, the link
attribute values associated with the set of applications supported
by legacy routers (RSVP-TE, SRTE, and/or LFA) are always shared
since legacy routers have no way of advertising or processing
application specific values. Once all legacy routers have been
upgraded, migration from legacy advertisements to application
specific advertisements can be achieved via the following steps:1)Send application specific advertisements while continuing to
advertise using legacy (all advertisements are then duplicated).
Receiving routers continue to use legacy advertisements.2)Enable the use of the application specific advertisements on
all routers3)Remove legacy advertisementsWhen the migration is complete, it then becomes possible to
advertise incongruent values per application on a given link.Note that the use of the L-flag is of no value in the
migration.Documents defining new applications which make use of the
application specific advertisements defined in this document MUST
discuss interoperability and backwards compatibility issues that
could occur in the presence of routers which do not support the new
application.The extensions defined in this document support RSVP-TE as one of
the supported applications. This allows that RSVP-TE could
eventually utilize the application specific advertisements. This can
be done in the following step-wise manner:1)Upgrade all routers to support the extensions in this
document2)Advertise all legacy link attributes using application specific
advertisements with L-flag clear and R-bit set.3)Remove legacy advertisementsThis section lists the protocol code point changes introduced by this
document and the related IANA changes required.For new registries defined under IS-IS TLV Codepoints Registry with
registration procedure "Expert Review", guidance for designated experts
can be found in .This document defines a new sub-TLV in the Sub-TLVs for TLVs 22,
23, 25, 141, 222, and 223 registry.This document defines one new TLV in the IS-IS TLV Codepoints
Registry.This document requests a new IANA registry under the IS-IS TLV
Codepoints Registry be created to control the assignment of
sub-sub-TLV codepoints for the Application Specific Link Attributes
sub-TLV defined in . The suggested name of the
new registry is "sub-sub-TLV code points for application specific link
attributes". The registration procedure is "Expert Review" as defined
in . The following assignments are made by
this document:Note to IANA: For future codepoints, in cases where the document
which defines the encoding is different from the document which
assigns the codepoint, the encoding reference MUST be to the document
which defines the encoding.Note to designated experts: If a link attribute can be advertised
both as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 and as a
sub-sub-TLV of the Application Specific Link Attributes sub-TLV
defined in this document, then the same numerical code should be
assigned to the link attribute whenever possible.This document requests a new IANA registry be created, under the
category of "Interior Gateway Protocol (IGP) Parameters", to control
the assignment of Application Identifier Bits. The suggested name of
the new registry is "Link Attribute Applications". The registration
policy for this registry is "Standards Action" . Bit definitions SHOULD be assigned in ascending
bit order beginning with Bit 0 so as to minimize the number of octets
that will need to be transmitted. The following assignments are made
by this document:This document requests a new IANA registry be created under the
IS-IS TLV Codepoints Registry to control the assignment of sub-TLV
types for the application specific SRLG TLV. The suggested name of the
new registry is "Sub-TLVs for TLV 238". The registration procedure is
"Expert Review" as defined in . The following
assignments are made by this document:Note to IANA: For future codepoints, in cases where the
document which defines the encoding is different from the document
which assigns the codepoint, the encoding reference MUST be to the
document which defines the encoding.Security concerns for IS-IS are addressed in , , and .This document defines a new way to advertise link attributes.
Tampering with the information defined in this document may have an
effect on applications using it, including impacting Traffic
Engineering. This is similar in nature to the impacts associated with
(for example) . As the advertisements defined in
this document limit the scope to specific applications, the impact of
tampering is similarly limited in scope.The authors would like to thank Eric Rosen and Acee Lindem for their
careful review and content suggestions.Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in conjunction with
the protocol for providing the connectionless-mode Network Service
(ISO 8473)International Organization for
Standardization