Internet DRAFT - draft-bowers-isis-te-attribute-set
draft-bowers-isis-te-attribute-set
ISIS Working Group C. Bowers
Internet-Draft S. Hegde
Intended status: Standards Track Juniper Networks
Expires: January 4, 2018 July 3, 2017
Extensions to IS-IS to Associate TE Attributes with TE Attribute Sets
and SRLGs with SRLG Sets
draft-bowers-isis-te-attribute-set-00
Abstract
This document specifies encodings that allow traffic engineering
attributes to be associated with different TE attribute set
identifiers and SRLGs to be associated with SRLG set identifiers.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bowers & Hegde Expires January 4, 2018 [Page 1]
Internet-Draft ISIS TE Attribute Sets July 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Basic assumptions . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Minimize disruption . . . . . . . . . . . . . . . . . . . 2
2.2. Maximize flexibilty . . . . . . . . . . . . . . . . . . . 3
3. TE Link Attributes that would benefit from this new
functionality . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Link Attribute Set sub-TLV . . . . . . . . . . . . . . . . . 4
5. TE Attribute Set usage . . . . . . . . . . . . . . . . . . . 5
6. SRLG Set Scoped SRLG TLV . . . . . . . . . . . . . . . . . . 6
7. SRLG Set usage . . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Management Considerations . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
IS-IS encodings allow traffic engineering (TE) attributes, such as
bandwidth-related parameters and administrative groups, as well as
shared risk link groups (SRLGs) to be associated with different links
in the network topology. Different applications use these attributes
to decide how traffic should be directed across the network.
It can be useful for different applications to use different sets of
TE attributes and SRLGs to decide how traffic is directed across the
network. Existing IS-IS encodings only allow for one set of TE
attributes and SRLGs to be associated with a given link. This
document specifies encodings that allow different sets of TE
attributes and SRLGs to be associated with a given link.
2. Basic assumptions
There are several different approaches that one could take to enable
this functionality. The approach taken by this document is based on
the following assumptions about the use of this encoding.
2.1. Minimize disruption
The requirements of many current and future deployments of SR and
RSVP can be satisfied using the existing encodings that support a
single set of TE attributes and SRLGs. The encodings described here
allow the advertisement of multiple sets of TE attributes and SRLGs.
Bowers & Hegde Expires January 4, 2018 [Page 2]
Internet-Draft ISIS TE Attribute Sets July 2017
They do so in a way that minimizes the disruption and burden, in
terms of interoperability testing, software upgrades, and overall
complexity, on deployments that do not need this more complex
fucntionality.
2.2. Maximize flexibilty
Future applications are difficult to predict, especially as network
operators deploy their own customized, centralized controllers. The
encodings described here does not try to associate TE attributes and
SRLGs with particular applications. Instead, they allow TE
attributes and SRLGs to be organized into sets, using groupings that
make most sense for the network operator's particular use case. The
network advertises these TE attributes and SRLGs with their
associated TE attribute and SRLG set identifiers, and different
applications use this information as they see fit. The authors
believe that this approach provides the greatest flexibility for
those networks that are likely to require these more complex
capabilities.
3. TE Link Attributes that would benefit from this new functionality
There are currently 36 sub-TLVs defined for TLV#22 (as well as TLVs
#23, #141, #222, and #223.) We draw a distinction between two types
of sub-TLVs in TLV#22. Some sub-TLVs (such as the IPv4 interface
address and neighbor address sub-TLVs) are used to identify a link.
In this document, we refer to these as TE link identifier sub-TLVs.
Below is a complete list of the sub-TLVs in TLV#22 that we classify
as TE link identifier sub-TLVs.
Type Description
------- -----------------------------
4 Link Local/Remote Identifiers
6 IPv4 interface address
8 IPv4 neighbor address
12 IPv6 Interface Address
13 IPv6 Neighbor Address
sub-TLVs of TLV#22 classified as TE link identifier sub-TLVs
Since TE link identifier sub-TLVs are used to identify links, it does
not make sense to allow these sub-TLVs to be advertised more than
once with different values for a given link.
In principle, the remaining 31 sub-TLVs currently defined for TLV#22
are candidates for enabling the advertisment of different values
scoped by a TE attribute set identifier. However, for this document
Bowers & Hegde Expires January 4, 2018 [Page 3]
Internet-Draft ISIS TE Attribute Sets July 2017
we only specify this new functionality for the following subset of TE
link attributes.
Type Description
------- -----------------------------
3 Administrative group (color)
9 Maximum link bandwidth
10 Maximum reservable link bandwidth
11 Unreserved bandwidth
14 Extended Administrative Group
18 TE Default metric
33 Unidirectional Link Delay
34 Min/Max Unidirectional Link Delay
35 Unidirectional Delay Variation
36 Unidirectional Link Loss
37 Unidirectional Residual Bandwidth
38 Unidirectional Available Bandwidth
39 Unidirectional Utilized Bandwidth
Figure 1: TE link attributes sub-TLVs given the ability to be
advertised with different values scoped by TE attribute set
identifier
The new TE Attribute Set Identifier is a 32-bit value that identifies
a set of attributes. The TE Attribute Set Identifier with a value of
zero is special. Existing encodings for advertising attributes that
do not explicitly support the inclusion of the TE Attribute Set
Identifier are now understood to implicitly advertise attributes with
the TE Attribute Set Identifier set to zero. In this framework,
existing implementations using the existing encodings already support
the advertisement of attributes with the TE attibute set id = 0.
In order to ensure a consistent view of the attribute set scoped
attributes, for encodings that explicitly support the TE Attribute
Set Identifier, advertising an attribute with TE Attribute Set
Identifier set to zero is not allowed.
4. Link Attribute Set sub-TLV
The Link Attribute Set sub-TLV is a new sub-TLV for TLVs 22, 23, 141,
222, and 223. It allows multiple values of a given TE link attribute
to be advertised for the same link, scoped by the TE Attribute Set
ID.
Type: To be assigned by IANA (suggested value 101)
Length: Number of octets in the value field (1 octet)
Bowers & Hegde Expires January 4, 2018 [Page 4]
Internet-Draft ISIS TE Attribute Sets July 2017
Value:
TE Attribute Set Identifier: A 32-bit value containing the non-
zero TE Attribute Set Identifier that identifies a set of
attributes. The Link Attribute Set sub-TLV MUST be ignored if
the TE Attribute Set Identifier is zero. This ensures a
consistent view of the attribute set scoped link attributes,
where the Link Attribute sub-TLVs advertised directly in TLV#22
are now understood to be implicitly advertised with the TE
Attribute Set Identifier equal to zero.
Link Attribute sub-sub-TLVs: The format of these Link Attribute
sub-sub-TLVs matches the existing formats for the Link
Attribute sub-TLVs defined in [RFC5305] and [RFC7810]. Each
Link Attribute sub-sub-TLV advertised in a given Link Attribute
Set sub-TLV is associated with the TE Attribute Set Identifier
in the Link Attribute Set sub-TLV. Figure 1 shows the subset
of existing Link Attributes sub-TLVs that we are specifying in
this document.
5. TE Attribute Set usage
The TE attribute set uses a simple substitution semantics. We
consider the TE attribute set with identifier=0 to be the default TE
attribute set. An application receiving attributes in the default TE
attribute set will use those default TE attributes, unless it
receives attributes in the one non-default TE attribute set that it
has been configured or programmed to consider.
In many network scenarios, all of the applications will only need to
use a single common set of TE attributes advertised with their
existing encodings. In this framework, these applications will all
be using TE attribute set = 0, the default TE attribute set.
Application Atribute set id
----------- ---------------
A 0 (implicit)
B 0 (implicit)
C 0 (implicit)
Scenario where all applications use a single common set of TE
attributes
In some scenarios, a network operator will need to advertise
different values of a given attribute for a given link. Consider a
scenario where applications D, E, and F need common values for all TE
link attributes, except for sub-TLV#9 (Maximum link bandwidth).
Applications D and E use a common value for sub-TLV#9, while
Bowers & Hegde Expires January 4, 2018 [Page 5]
Internet-Draft ISIS TE Attribute Sets July 2017
application F needs a different value for sub-TLV#9. This scenario
is supported by having each link advertise all sub-TLVs in TLV#22 as
they are advertised today. These advertisements are understood to be
advertised with the TE attribute set id = 0. Applications D and E
only need to use these advertisements. Links also advertise sub-sub-
TLV#9 in the TE Atribute Set sub-TLV with TE attribute set id = 1.
Application F is configured to use attribute set id = 1. This means
that application F first looks for the value of each attribute scoped
for TE attribute set = 1. If it is present, application F uses that
attribute set scoped value. If it is not present, application F uses
the value in the default TE attribute set (id=0).
Application Atribute set id
----------- ---------------
D 0 (implicit)
E 0 (implicit)
F 1
Scenario where applications need different values for some attributes
From a standardization perspective, there is not intended to be any
fixed mapping between a given TE Attribute Set Identifier and a given
application. A network operator wishing to advertise different
attribute sets could configure the network equipment to advertise
attributes with different values of the TE Attribute Set Identifier
based on their objectives. The different applications (be they
controller-based applications or distributed applications) would make
use of the different attribute sets based on convention within that
network.
6. SRLG Set Scoped SRLG TLV
A new TLV is defined to allow SRLGs to be advertised for a given link
and associated with a specific SRLG set identifier. Although similar
in functionality to TLV 138 (defined by [RFC5307]) and TLV 139
(defined by [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.
Type: To be assigned by IANA (suggested value 238)
Length: Number of octets in the value field (1 octet)
Value:
Neighbor System-ID + pseudo-node ID (7 octets)
Bowers & Hegde Expires January 4, 2018 [Page 6]
Internet-Draft ISIS TE Attribute Sets July 2017
SRLG Set Identifier: A 32-bit value containing the non-zero SRLG
Set Identifier that identifies a set of SRLGs. The SRLG Set
Scoped SRLG TLV MUST be ignored if the SRLG Set Identifier is
zero. This ensures a consistent view of the SRLG set scoped
link attributes, where the SRLGs advertised directly in TLV#138
and TLV#139 are now understood to be implicitly advertised with
the TE Attribute Set Identifier equal to zero.
Length of sub-TLVs in octets (1 octet)
Link Identifier sub-TLVs (variable)
0 or more SRLG Values (Each value is 4 octets)
The following Link Identifier sub-TLVs are defined. The type
values are only suggested values. The actual values will be
assigned by IANA. However, as the formats are identical to
existing sub-TLVs defined for TLVs 22, 23, 141, 222, and 223 the
assignment of the suggested sub-TLV types is strongly encouraged.
Type Description
------- -----------------------------
4 Link Local/Remote Identifiers
6 IPv4 interface address
8 IPv4 neighbor address
12 IPv6 Interface Address
13 IPv6 Neighbor Address
At least one set of link identifiers (IPv4, IPv6, or unnumbered) MUST
be present. TLVs which do not meet this requirement MUST be ignored.
Multiple TLVs for the same link MAY be advertised.
7. SRLG Set usage
The new SRLG Set Identifier is a 32-bit value that identifies a set
of SRLGs. The SRLG Set Identifier with a value of zero is special.
Existing encodings for advertising SRLGs that do not explicitly
support the inclusion of the SRLG Set Identifier are now understood
to implicitly advertise SRLGs with the SRLG Set Identifier set to
zero. In this framework, existing implementations using the existing
encodings already support the advertisement of SRLGs with the SRLG
set id = 0.
In order to ensure a consistent view of the SRLG set scoped SRLGs,
for encodings that explicitly support the SRLG Set Identifier,
advertising an attribute with SRLG Set Identifier set to zero is not
allowed.
Bowers & Hegde Expires January 4, 2018 [Page 7]
Internet-Draft ISIS TE Attribute Sets July 2017
The SRLG set uses additive semantics. An application receiving SRLGs
scoped with different SRLG set identifiers will take the union of the
SRLGs in each SRLG set that the application is programmed to take
into consideration. Given the additive semantics of SRLG sets, we do
not use the SRLGs with SRLG set identifier = 0 as a default value in
the absence of other SRLGs with non-zero SRLG set identifier.
The following example illustrates the expected use of the advertising
SRLGs scoped with SRLG set identifiers. SRLGs in networks often
follow a natural grouping into sets. As a concrete example, assume
that one set of SRLGs corresponds to links within a metro area
(intra-city SRLGs). A second set of SRLGs corresponds to links
between metro area (inter-city SRLGs). A third set of SRLGs
corresponds to links between continents on undersea cables (inter-
continental SRLGs). A reasonable mapping of these natural SRLG
groupings to SRLG set identifier is shown below in Figure 2. The
network would be configured to advertise SRLGs scoped with these SRLG
set identifiers.
Natural SRLG groupings SRLG set id
----------------------- -----------
intra-city SRLGs 1
inter-city SRLGs 2
inter-continental SRLGs 3
Figure 2: Example mapping of natural SRLG groupings to SRLG set
identifier
Assume that the network operator starts out with two applications.
Application G should take into account all three groups of SRLGs as
path constraints: intra-city, inter-city, and inter-continental
SRLGs. Instead, application H should only take into account inter-
city and inter-continental SRLGs. This can be accomplished by having
application G use union of SRLG sets 1, 2, and 3, while application H
uses the union of SRLG sets 2 and 3, as shown in Figure 3.
Application SRLG set ids
----------------------- ------------
G 1+2+3
H 2+3
Figure 3: Example usage of SRLG sets by applications
This accomplishes the goals of the network operator in a very natural
way.
Now suppose that the network operator introduces a third application,
application J, that should only take into account intra-city and
Bowers & Hegde Expires January 4, 2018 [Page 8]
Internet-Draft ISIS TE Attribute Sets July 2017
inter-city SRLGs. This can be accomplished without modifying any of
the SRLG advertisements. The new application J need only be
programmed or configured to take use the union of SRLG sets 1 and 2,
as as shown in Figure 4.
Application SRLG set ids
----------------------- ------------
G 1+2+3
H 2+3
J 1+2
Figure 4: The simplicity of adding a new application
If application J is a centralized controller-based application, the
new application can be introduced with even touching the network
itself.
8. IANA Considerations
IANA is requested to create a new sub-TLV, the Link Attribute Set
sub-TLV for TLVs 22, 23, 141, 222, and 223.
Type Description 22 23 141 222 223 Ref.
------- --------------------------- -- -- --- --- --- -------
TBA1 Link Attribute Set sub-TLV y y y y y [This
draft]
IANA is requested to create a new TLV, the SRLG Set Scoped SRLG TLV.
Type Description IIH SNP LSP Purge Ref.
------- ----------------------- --- --- --- ----- ------
TBA2 TE Attribute Set Scoped n n y n [This
SRLG TLV draft]
9. Management Considerations
TBD
10. Security Considerations
TBD
11. Acknowledgements
The basic format for the encoding of the Link Attribute Set sub-TLV
and the TE Attribute Set Scoped SRLG TLV follows the basic format of
the encodings in [I-D.ginsberg-isis-te-app].
Bowers & Hegde Expires January 4, 2018 [Page 9]
Internet-Draft ISIS TE Attribute Sets July 2017
12. References
12.1. Normative References
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<http://www.rfc-editor.org/info/rfc5307>.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
February 2011, <http://www.rfc-editor.org/info/rfc6119>.
[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,
<http://www.rfc-editor.org/info/rfc7810>.
12.2. Informative References
[I-D.ginsberg-isis-te-app]
Ginsberg, L., Psenak, P., Previdi, S., and W. Henderickx,
"IS-IS TE Attributes per application", draft-ginsberg-
isis-te-app-00 (work in progress), February 2017.
Authors' Addresses
Chris Bowers
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: cbowers@juniper.net
Shraddha Hegde
Juniper Networks
Embassy Business Park
Bangalore, KA 560093
India
Email: shraddha@juniper.net
Bowers & Hegde Expires January 4, 2018 [Page 10]
