ISIS Segment Routing Flexible Algorithm
draft-hegdeppsenak-isis-sr-flex-algo-01

Document Type Active Internet-Draft (individual)
Last updated 2017-10-23
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                     P. Psenak, Ed.
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                           S. Hegde, Ed.
Expires: April 26, 2018                           Juniper Networks, Inc.
                                                             C. Filsfils
                                                     Cisco Systems, Inc.
                                                                A. Gulko
                                                         Thomson Reuters
                                                        October 23, 2017

                ISIS Segment Routing Flexible Algorithm
              draft-hegdeppsenak-isis-sr-flex-algo-01.txt

Abstract

   IGP protocols traditionally compute best paths over the network based
   on the IGP metric assigned to the links.  Many network deployments
   use RSVP based or Segment Routing based Traffic Engineering to
   enforce traffic over a path that is computed using different metrics
   or constrains then IGP path.  Various mechanisms are used to steer
   the traffic towards such traffic engineered paths.  This document
   proposes a solution that allows IGPs itself to compute constrained
   based path over the network without the usage of the traffic
   engineering.

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 https://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 April 26, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Psenak, et al.           Expires April 26, 2018                 [Page 1]
Internet-Draft     ISIS Segment Routing Flex Algorithm      October 2017

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements notation . . . . . . . . . . . . . . . . . .   3
   2.  Flexible Algorithm  . . . . . . . . . . . . . . . . . . . . .   3
   3.  Flexible Algorithm Advertisement  . . . . . . . . . . . . . .   3
   4.  Flexible Algorithm Definition Advertisement . . . . . . . . .   4
     4.1.  Flexible Algorithm Definition TLV . . . . . . . . . . . .   4
     4.2.  Flexible Algorithm Exclude Admin Group Sub-TLV  . . . . .   7
   5.  Calculation of Flexible Algorithm Paths . . . . . . . . . . .   7
   6.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . .   9
     8.2.  New TLV Codepoint and Sub-TLV registry  . . . . . . . . .   9
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   IGP computed path based on the shortest IGP metric must often be
   replaced by traffic engineered path due to the traffic requirements
   which are not reflected in the IGP metric.  Some networks engineer
   the IGP metric assignments in a way that the IGP Metric reflects the
   link bandwidth or delay.  If, for example, the IGP metric is
   reflecting the bandwidth on the link and the application traffic is
   delay sensitive, the best IGP path may not reflect the best path from
   such application's perspective.

   To overcome such IGP limitation, various sorts of traffic engineering
Show full document text