[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/