Internet DRAFT - draft-ginsberg-isis-route-preference

draft-ginsberg-isis-route-preference







Networking Working Group                                     L. Ginsberg
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                            S. Litkowski
Expires: January 3, 2015                         Orange Business Service
                                                              S. Previdi
                                                           Cisco Systems
                                                           July 02, 2014


      IS-IS Route Preference for Extended IP and IPv6 Reachability
              draft-ginsberg-isis-route-preference-00.txt

Abstract

   Existing specifications as regards route preference are not explicit
   when applied to IP/IPv6 Extended Reachability TLVs.  There are also
   inconsistencies in the definition of how the up/down bit applies to
   route preference when the prefix advertisement appears in Level 2
   LSPs.  This document addresses these issues.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 3, 2015.

Copyright Notice

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




Ginsberg, et al.         Expires January 3, 2015                [Page 1]

Internet-Draft draft-ginsberg-isis-route-preference-00.txt     July 2014


   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Use of the up/down Bit in Level 2 LSPs  . . . . . . . . . . .   3
   3.  Types of Routes in IS-IS Supported by Extended Reachability
       TLVs  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Types of Routes Supported by TLVs 135 and 235 . . . . . .   4
     3.2.  Types of Routes Supported by TLVs 236 and 237 . . . . . .   5
     3.3.  Order of Preference for all types of routes supported by
           TLVs 135 and 235  . . . . . . . . . . . . . . . . . . . .   6
     3.4.  Order of Preference for all types of routes supported by
           TLVs 236 and 237  . . . . . . . . . . . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Appendix A.  Example Interoperability Issue . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   [RFC5302] defines the route preferences rules as they apply to
   Type/Length/Value(TLV)s 128 and 130.  [RFC5305] introduced the IP
   Extended Reachability TLV 135 but did not explicitly adapt the route
   preference rules defined in [RFC5302] for the new TLV.  [RFC5308]
   defines the IPv6 Reachability TLV 236 and does include an explicit



Ginsberg, et al.         Expires January 3, 2015                [Page 2]

Internet-Draft draft-ginsberg-isis-route-preference-00.txt     July 2014


   statement as regards route preference - but the statement introduces
   use of the up/down bit in advertisements which appear in Level 2 Link
   State Protocol Data Units(LSPs) which is inconsistent with statements
   made in [RFC5302] and [RFC5305].  This document defines explicit
   route preference rules for TLV 135, revises the route preferences
   rules for TLV 236, and clarifies the usage of the up/down bit when it
   appears in TLVs in Level 2 LSPs.  This document is viewed as a
   clarification (NOT correction) of [RFC5302] and [RFC5305] and a
   correction of the route preference rules defined in [RFC5308] to be
   consistent with the rules for IPv4.  It also makes explicit that the
   same rules apply for the Multi-Topology(MT) equivalent TLVs 235 and
   237.

2.  Use of the up/down Bit in Level 2 LSPs

   The up/down bit was introduced in support of leaking prefixes
   downwards in the IS-IS level hierarchy.  Routes which are leaked
   downwards have the bit set to 1.  Such prefixes MUST NOT be leaked
   upwards in the hierarchy.  So long as we confine ourselves to a
   single IS-IS instance and the current number of supported levels
   (two) it is impossible to have a prefix advertised in a Level 2 LSP
   and have the up/down bit set to 1.  However, because [RFC5302]
   anticipated a future extension to IS-IS which might support
   additional levels it allowed for the possibility that the up/down bit
   might be set in a Level-2 LSP and in support of easier migration in
   the event such an extension was introduced Section 3.3 stated:

   "...it is RECOMMENDED that implementations ignore the up/down bit in
   L2 LSPs, and accept the prefixes in L2 LSPs regardless of whether the
   up/down bit is set."

   [RFC5305] addressed an additional case wherein an implementation
   included support for multiple virtual routers running IS-IS in
   different areas.  In such a case it is possible to redistribute
   prefixes between two IS-IS instances in the same manner that prefixes
   are redistributed from other protocols into IS-IS.  This introduced
   the possibility that a prefix could be redistributed from Level 1 to
   Level 1 (as well as between Level 2 and Level 2) and in the event the
   redistributed route was leaked from Level 1 to Level 2 two different
   routers in different areas would be advertising the same prefix into
   the Level 2 sub-domain.  To prevent this [RFC5305] specified in
   Section 4.1:

   "If a prefix is advertised from one area to another at the same
   level, then the up/down bit SHALL be set to 1."

   However, the statement in [RFC5302] that the up/down bit is ignored
   in Level 2 LSPs is not altered by [RFC5305].



Ginsberg, et al.         Expires January 3, 2015                [Page 3]

Internet-Draft draft-ginsberg-isis-route-preference-00.txt     July 2014


   The conclusion then is that there is no "L2 inter-area route" - and
   indeed no such route type is defined by [RFC5302].  However,
   [RFC5308] ignored this fact and introduced such a route type in
   Section 5 when it specified a preference for " Level 2 down prefix".
   This is an error which this document corrects.

3.  Types of Routes in IS-IS Supported by Extended Reachability TLVs

   [RFC5302] is the authoritative reference for the types of routes
   supported by TLVs 128 and 130.  However, a number of attributes
   supported by those TLVs are NOT supported by TLVs 135, 235, 236, 237.
   Distinction between internal/external metrics is not supported.  In
   the case of IPv4 TLVs (135 and 235) the distinction between internal
   and external route types is not supported.  It is therefore useful to
   explicitly state the supported route types for these TLVs.

3.1.  Types of Routes Supported by TLVs 135 and 235

   This section defines the types of route supported for IPv4 when using
   TLV 135 [RFC5305] and/or TLV 235 [RFC5120].  The text follows as
   closely as possible the original text from [RFC5302].

   L1 intra-area routes: These are advertised in L1 LSPs, in TLV 135 or
   TLV 235.  The up/down bit is set to zero.  These IP prefixes are
   directly connected to the advertising router.  These routes are
   indistinguishable from L1 external routes.

   L1 external routes: These are advertised in L1 LSPs, in TLV 135 or
   TLV 235.  The up/down bit is set to zero.  These IP prefixes are
   learned from other protocols and are usually not directly connected
   to the advertising router.  These routes are indistinguishable from
   L1 intra-area routes.

   L2 intra-area routes: These are advertised in L2 LSPs, in TLV 135 or
   TLV 235.  The up/down bit is set to zero.  These IP prefixes are
   directly connected to the advertising router.  These prefixes cannot
   be distinguished from L1->L2 inter-area routes and/or L2 external
   routes.

   L1->L2 inter-area routes: These are advertised in L2 LSPs, in TLV 135
   or TLV 235.  The up/down bit is set to zero.  These IP prefixes are
   learned via L1 routing and were derived during the L1 Shortest Path
   First (SPF) computation from prefixes advertised in L1 LSPs in TLV
   135 or TLV 235.  These prefixes cannot be distinguished from L2
   intra-area routes and/or L2 external routes.

   L2 external routes: These are advertised in L2 LSPs, in TLV 135 or
   TLV 235.  The up/down bit is set to zero.  These IP prefixes are



Ginsberg, et al.         Expires January 3, 2015                [Page 4]

Internet-Draft draft-ginsberg-isis-route-preference-00.txt     July 2014


   learned from other protocols and are usually not directly connected
   to the advertising router.  These routes are indistinguishable from
   L2 intra-area routes and/or L1->l2 inter-area routes.

   L2->L1 inter-area routes: These are advertised in L1 LSPs, in TLV 135
   or TLV 235.  The up/down bit is set to one.  These IP prefixes are
   learned via L2 routing and were derived during the L2 SPF computation
   from prefixes advertised in TLV 135 or TLV 235.  These routes are
   indistinguishable from L1->L1 inter-area routes.

   L1->L1 inter-area routes: These are advertised in L1 LSPs, in TLV 135
   or TLV 235.  The up/down bit is set to one.  These IP prefixes are
   learned from another IS-IS instance operating in another area.  These
   routes are indistinguishable from L2->L1 inter-area routes.

   L2->L2 inter-area routes: These are advertised in L2 LSPs, in TLV 135
   or TLV 235.  The up/down bit is set to one but is ignored and treated
   as if it were set to 0.  These IP prefixes are learned from another
   IS-IS instance operating in another area.

3.2.  Types of Routes Supported by TLVs 236 and 237

   This section defines the types of route supported for IPv6 when using
   TLV 236 [RFC5308] and/or TLV 237 [RFC5120].

   L1 intra-area routes: These are advertised in L1 LSPs, in TLV 236 or
   TLV 237.  The up/down bit is set to zero.  The eXternal bit is set to
   0.  These IPv6 prefixes are directly connected to the advertising
   router.

   L1 external routes: These are advertised in L1 LSPs, in TLV 236 or
   TLV 237.  The up/down bit is set to zero.  The eXternal bit is set to
   1.  These IPv6 prefixes are learned from other protocols and are
   usually not directly connected to the advertising router.

   L2 intra-area routes: These are advertised in L2 LSPs, in TLV 236 or
   TLV 237.  The up/down bit is set to zero.  The eXternal bit is set to
   0.  These IPv6 prefixes are directly connected to the advertising
   router.  These prefixes cannot be distinguished from L1->L2 inter-
   area routes.

   L1->L2 inter-area routes: These are advertised in L2 LSPs, in TLV 236
   or TLV 237.  The up/down bit is set to zero.  The eXternal bit is set
   to 0.  These IPv6 prefixes are learned via L1 routing and were
   derived during the L1 Shortest Path First (SPF) computation from
   prefixes advertised in L1 LSPs in TLV 236 or TLV 237.  These prefixes
   cannot be distinguished from L2 intra-area routes.




Ginsberg, et al.         Expires January 3, 2015                [Page 5]

Internet-Draft draft-ginsberg-isis-route-preference-00.txt     July 2014


   L2 external routes: These are advertised in L2 LSPs, in TLV 236 or
   TLV 237.  The up/down bit is set to zero. the eXternal bit is set to
   1.  These IPv6 prefixes are learned from other protocols and are
   usually not directly connected to the advertising router.

   L1->L2 external routes: These are advertised in L2 LSPs, in TLV 236
   or TLV 237.  The up/down bit is set to zero.  The eXternal bit is set
   to 1.  These IPv6 prefixes are learned via L1 routing and were
   derived during the L1 Shortest Path First (SPF) computation from L1
   external routes advertised in L1 LSPs in TLV 236 or TLV 237.  These
   prefixes cannot be distinguished from L2 external routes.

   L2->L1 inter-area routes: These are advertised in L1 LSPs, in TLV 236
   or TLV 237.  The up/down bit is set to one.  The eXternal bit is set
   to 0.  These IPv6 prefixes are learned via L2 routing and were
   derived during the L2 SPF computation from prefixes advertised in TLV
   236 or TLV 237.  These routes are indistinguishable from L1->L1
   inter-area routes.

   L2->L1 external routes: These are advertised in L1 LSPs, in TLV 236
   or TLV 237.  The up/down bit is set to one.  The eXternal bit is set
   to 1.  These IPv6 prefixes are learned via L2 routing and were
   derived during the L2 SPF computation from prefixes advertised in TLV
   236 or TLV 237.

   L1->L1 inter-area routes.  These are advertised in L1 LSPs, in TLV
   236 or TLV 237.  The up/down bit is set to one.  The eXternal bit is
   set to 0.  These IP prefixes are learned from another IS-IS instance
   operating in another area.  These routes are indistinguishable from
   L2->L1 inter-area routes.

   L2->L2 inter-area routes.  These are advertised in L2 LSPs, in TLV
   236 or TLV 237.  The up/down bit is set to one but is ignored and
   treated as if it were set to 0.  The eXternal bit is set to 0.  These
   IP prefixes are learned from another IS-IS instance operating in
   another area.

3.3.  Order of Preference for all types of routes supported by TLVs 135
      and 235

   This document defines the following route preferences for IPv4 routes
   advertised in TLVs 135 or 235.

   1.  L1 intra-area routes; L1 external routes

   2.  L2 intra-area routes; L2 external routes; L1->L2 inter-area
   routes; L2-L2 inter-area routes




Ginsberg, et al.         Expires January 3, 2015                [Page 6]

Internet-Draft draft-ginsberg-isis-route-preference-00.txt     July 2014


   3.  L2->L1 inter-area routes; L1->L1 inter-area routes

3.4.  Order of Preference for all types of routes supported by TLVs 236
      and 237

   This document defines the following route preferences for IPv6 routes
   advertised in TLVs 236 or 237.

   1.  L1 intra-area routes; L1 external routes

   2.  L2 intra-area routes; L2 external routes; L1->L2 inter-area
   routes; L1-L2 external routes;L2-L2 inter-area routes

   3.  L2->L1 inter-area routes; L2->L1 external routes;L1->L1 inter-
   area routes

4.  IANA Considerations

   No IANA actions required.

5.  Security Considerations

   None.

6.  Acknowledgements

   TBD

7.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120, February 2008.

   [RFC5302]  Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix
              Distribution with Two-Level IS-IS", RFC 5302, October
              2008.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, October 2008.

   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
              2008.





Ginsberg, et al.         Expires January 3, 2015                [Page 7]

Internet-Draft draft-ginsberg-isis-route-preference-00.txt     July 2014


Appendix A.  Example Interoperability Issue

   This documents a real world interoperability issue which occurs
   because implementations from different vendors have interpreted the
   use of the up/down bit in Level 2 LSPs inconsistently.

           L2       L2       L2     L2|L2      L2
    10/8 - R0 ----- R1 ----- R2 ----- R3 ----- R4 ---- 10/8
                                      |
                   Figure 1

   Considering Figure 1, both R0 and R4 are advertising the prefix 10/8.
   Two ISIS Level 2 instances are running on R3 to separate the network
   into two areas.  R3 is performing route-leaking and advertises
   prefixes from R4 to the other Level 2 process.  The network is using
   extended metrics (TLV135 defined in [RFC5305]).  R0 is advertising
   10/8 with metric 2000 and R3 advertises 10/8 with metric 100.  All
   links have a metric of 1.  When advertising 10/8 in its Level 2 LSP,
   R3 sets the down bit as specified in [RFC5305].

   R1, R2 and R3 are from three different vendors (R1->Vendor1,
   R2->Vendor2, R3->Vendor3).  During interoperability testing, routing
   loops are observed in this scenario.

   o  R2 has two possible paths to reach 10/8, Level 2 route with metric
      2002, up/down bit is 0 (from R0) and Level 2 route with metric
      101, up/down bit is 1 (from R3).  R2 selects R1 as nexthop to 10/8
      because it prefers the route which does NOT have up/down bit set.

   o  R3 has two possible paths to reach 10/8, Level 2 route with metric
      2003, up/down bit is 0 (from R0) and Level 2 route with metric
      101, up/down bit is 0 (from R4).  R3 selects R4 as nexthop due to
      lowest metric.

   o  R1 has two possible paths to reach 10/8, Level 2 route with metric
      2001, up/down bit is 0 (from R0) and Level 2 metric 102, up/down
      bit is 1 (from R3).  R1 selects R2 as nexthop due to lowest
      metric.

   When R1 or R2 try to send traffic to 10/8, packets are looping due to
   inconsistent routing decision between R1 and R2.

Authors' Addresses








Ginsberg, et al.         Expires January 3, 2015                [Page 8]

Internet-Draft draft-ginsberg-isis-route-preference-00.txt     July 2014


   Les Ginsberg
   Cisco Systems
   510 McCarthy Blvd.
   Milpitas, CA  95035
   USA

   Email: ginsberg@cisco.com


   Stephane Litkowski
   Orange Business Service

   Email: stephane.litkowski@orange.com


   Stefano Previdi
   Cisco Systems
   Via Del Serafico 200
   Rome  0144
   Italy

   Email: sprevidi@cisco.com





























Ginsberg, et al.         Expires January 3, 2015                [Page 9]