IS-IS Multi Topology Deployment Considerations
draft-chunduri-lsr-isis-mt-deployment-cons-00

LSR Working Group                                            U. Chunduri
Internet-Draft                                                Huawei USA
Intended status: Informational                               J. Tantsura
Expires: October 26, 2018                                 Nuage Networks
                                                          April 24, 2018

             IS-IS Multi Topology Deployment Considerations
             draft-chunduri-lsr-isis-mt-deployment-cons-00

Abstract

   This document analyzes IS-IS Multi Topology (MT) considerations in
   various deployments (Core/Mobile Backhaul/Data Center underlay).
   This document explores nuances around various IS-IS address families,
   topologies and considerations while choosing the right combination
   for a specific DC/mobile backhaul deployment.

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 RFC2119 [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 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 October 26, 2018.

Copyright Notice

   Copyright (c) 2018 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

Chunduri & Tantsura     Expires October 26, 2018                [Page 1]
Internet-DrafIS-IS Multi Topology Deployment Considerations   April 2018

   (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
   2.  Need for MT in IS-IS networks . . . . . . . . . . . . . . . .   3
   3.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Topologies and Address Families . . . . . . . . . . . . . . .   3
     4.1.  Single Topology Mode and Multiple Address Families  . . .   4
     4.2.  Multiple Topology Mode  and Multiple Address Families . .   5
       4.2.1.  Transition Mode . . . . . . . . . . . . . . . . . . .   5
     4.3.  IPv6 Only Topology  . . . . . . . . . . . . . . . . . . .   6
   5.  IS-IS MT and LFA  . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   ISIS originally developed for OSI [ISO10589], extensions have been
   made available to support IPv4 [RFC1195].  A method for exchanging
   IPv6 routing information using the IS-IS routing protocol is
   specified in [RFC5308].  How to run a set of independent IP
   topologies with topology specific adjacencies, within a single IS-IS
   domain has been defined in IS-IS MT [RFC5120].

   Multiple mobile backhaul network user plane proposals like
   [I-D.ietf-dmm-srv6-mobile-uplane] and [I-D.herbert-ila-mobile] use
   IPv6 only solution using source routing, address transformation
   respectively.  It is possible to conceive, various parts of the
   backhaul networks use IPv4 and appropriate migration strategy needed
   before eventually moving towards IPv6 only network.  While any IGP
   can be used in these networks, this document covers only IS-IS
   protocol aspects.

   Various layer-3 DC fabric routing options (refs: openfabric, spine-
   leaf, controller-based) by changing or optimizing some aspects w.r.t
   adjacency formation, flooding optimizations, or/and mechanisms to

Chunduri & Tantsura     Expires October 26, 2018                [Page 2]
Internet-DrafIS-IS Multi Topology Deployment Considerations   April 2018

   automatically compute the location of the node in the fat tree
   topology are proposed recently and this document brings some of the
   multi topology deployment aspects relevant to these networks.  Please
   note part of the discussion around IS-IS MT is not specific to DC or
   CLOS fabrics and generally applicable to any IS-IS deployment but
   discussed here because of multiple proposals to use various forms of
   IS-IS in this context.

2.  Need for MT in IS-IS networks

   For mobile transport backhaul networks seeking only IPv6 network or
   transitioning from parts of the network with only IPv4, IS-IS MT is
   needed.  For DC fabric underlay, which provide reachability, only one
   address family (either IPv4 or IPv6) SHOULD be sufficient.  However
   if either only IPv6 address family is needed in the underlay or
   deploying both IPv4 and IPv6 address families are desired discussion
   in Section 4 is relevant.

   It is an unlikely requirement, where DC fabric to be partitioned
   logically to have different topologies in the underlay.  If one does
   to meet a particular requirement, this does introduce manageability
   complexity of these logical topologies.  IS-IS MT [RFC 5120] also
   designed to address the above need and discussion in Section 4.2 is
   relevant.  It is worth noting, majority of the IS-IS deployments (non
   DC) use MT primarily to have a separate logical topology for IPv6
   address family.

3.  Acronyms

          IIH : IS-IS Hello Protocol Data Unit

          LSP : Link State PDU

          MT : Multi Topology

          SPF : Shortest Path First

4.  Topologies and Address Families

   Terminology around IS-IS topologies and address families is somewhat
   confusing at best.  Just to give an example, MT ID #2 defined in [RFC
   5120] says, it is "Reserved for IPv6 routing topology".  While
   multiple MT ID's can be deployed in a network with IPv6 topologies,
   MT ID #2, perhaps referring to a first such topology with IPv6 only
   address family.  This section details various topology and address
   family options possible with currently available IS-IS specifications
   with respective defined TLVs.

Chunduri & Tantsura     Expires October 26, 2018                [Page 3]
Internet-DrafIS-IS Multi Topology Deployment Considerations   April 2018

4.1.  Single Topology Mode and Multiple Address Families

   IS-IS with IPv4 address family and with wide-metrics [RFC 5305] is
   widely deployed, with TLV 22 defined for IS Reachability and TLV 135
   for IP (IPv4) reachability information . This is essentially a single
   topology for the entire IS-IS area/domain with a single address
   family (IPv4 unicast).

   IS-IS can also be enabled with IPv6 unicast address family in a
   single topology mode along with IPv4 unicast address family.  Here
   IPv6 uses the same underlying topology that is used for IPv4 and this
   can be done as specified in IS-IS IPv6 [RFC5308] which introduces TLV
   236, an IPv6 reachability TLV.  It is important to note same IS-IS
   adjacency is used for both address families and with a single SPF
   (decision process) both IPv4 and IPv6 reachability would be computed.

   However, for the above to work effectively, both IPv4 and IPv6
   address families MUST share a common network topology.  That is to
   use IS-IS for IPv4 and IPv6 routing, any interface configured for
   IPv4 IS-IS MUST also be configured for IPv6 IS-IS, and vice versa.
   All routers within an IS-IS area (Level 1 routing) or domain (Level 2
   routing) MUST also support the same set of address families: IPv4
   only, IPv6 only, or both IPv4 and IPv6.  Any discrepancy in the
   configuration w.r.t above can cause routing black holes and one such
   scenario is discussed below.

                         | /         \|
                      ...Rx          Ry...
                         | \          /
                         |   \      / |
                         |     \  /   |
                         |      /\    |
                         |    /    \  |
                         |  /        \|
                     ... R1          R2...
                         | \        / |

              Figure 1: IS-IS with multiple address families

   As shown, in the above diagram all routers in the network enabled
   with both IPv4 and IPv6 unicast address families at the IS level and
   single topology would be built.  However, at a link level all but
   except one link, say if IPv6 is not configured on the link between
   the routers Rx and R2; due to a single IS-IS topology, the shortest
   path between Rx and R2 is the direct link and since IPv6 is not

Chunduri & Tantsura     Expires October 26, 2018                [Page 4]
Internet-DrafIS-IS Multi Topology Deployment Considerations   April 2018

   enabled on that link, Rx and R2 cannot exchange IPv6 data traffic
   even though there's an alternate path between them in the topology
   through Rx, R1, Ry and R2.

   Hence to summarize the restrictions, as laid out above: all routers
   in the topology MUST support only IPv4, only IPv6 or both IPv4 and
   IPv6 address families on all links and node.  In other words, network
   MUST be congruent.  While this model is to simpler to operate, might
   not be flexible enough for some IS-IS deployments.

4.2.  Multiple Topology Mode and Multiple Address Families

   Multi-topology IS-IS uses multiple SPFs to compute routes and removes
   the restriction that all interfaces MUST support all configured
   address families and that all routers in an IS-IS area or domain MUST
   support the same set of address families.  This introduces the
   concept of topology specific adjacency with MT IS Reachability TLV
   222 and MT capable IPv4 Reachability with TLV 235 and MT capable IPv6
   Reachability with TLV 237.

   When MT IS-IS is enabled with IPv4 and IPv6 address families, the
   routers build two topologies, one for each address family (IPv4 and
   IPv6) and can find the optimum path for each address family even when
   some links in the network support only one of them.  IS-IS MT [RFC
   5120] defines MT ID #0 for backward compatibility, as the "standard"
   topology and this essentially operate as IS-IS single topology mode
   as specified in Section 4.1 and supports both IPv4 and IPv6 address
   families.  MT ID #2 [RFC 5120] is defined for IPv6 address family in
   MT mode.

4.2.1.  Transition Mode

   Most of the vendors supported MT transition feature (though some
   vendors disabled to avoid confusion around this) in the IS-IS
   networks to facilitate MT deployments without disrupting the single
   topology mode.  The MT transition mode allows a network operating in
   single topology IS-IS IPv6 [RFC 5308] to continue to work while
   upgrading routers to include MT IS-IS IPv6 support i.e., MT ID #2
   with [RFC 5120] . While in transition mode, both types of TLVs
   (single-topology with TLV 236 and MT with TLV 237) are sent in LSPs
   for all configured IPv6 addresses, nodes can continue to operate in
   single topology mode though being in MT mode ("standard" IS-IS
   topology with MT ID #0).  After all routers in the area or domain
   have been upgraded to support MT IPv6 transition mode can be removed
   from the configuration.  Once all routers in the area or domain are
   operating in MT IPv6 mode, the topological restrictions of single-
   topology mode are no longer in effect.

Chunduri & Tantsura     Expires October 26, 2018                [Page 5]
Internet-DrafIS-IS Multi Topology Deployment Considerations   April 2018

   When transition mode is enabled, the router advertises both MT TLVs
   and the old style IS-IS IPv6 TLVs but the topological restrictions of
   the single topology mode discussed above are in effect with MT
   transition mode.  However, there were instances while this is enabled
   and folks expect a different result in the actual deployments.

4.3.  IPv6 Only Topology

   Though it is theoretically possible to build IPv6 only underlay (with
   TLV 236 for IPv6 reachability prefixes) in single topology mode as
   discussed in Section 4.1, lot of legacy implementations require IPv4
   address families too be configured in single topology mode (ingrained
   code structures for IPv4 address family).  IPv6 only DC underlay
   network can be built with multi topology adjacencies (TLV 222) and
   reachability prefixes (TLV 237) with MT ID #2 as discussed above in
   Section 4.2.  With this any other address family can be introduced
   including "standard" topology MT ID #0 (Single topology mode with
   both address families) and there are no restrictions on which address
   family has to enable on which link as specified in Section 4.1.

5.  IS-IS MT and LFA

   IP Fast Reroute (FRR) or Loop Free Alternative (LFA) computation in
   MT mode are described in detail in Section 5.2 of
   [I-D.ietf-rtgwg-multihomed-prefix-lfa].

6.  Acknowledgements

   Thanks to .. TBD.

7.  IANA Considerations

   This document has no actions for IANA.

8.  Security Considerations

   Security concerns for IS-IS are addressed in [RFC5304]and [RFC5310].
   Further security analysis for IS-IS protocol is done in [RFC7645].

   This document does not introduce any change in any of the IS-IS
   protocol or IS-IS protocol extensions.  This document also does not
   introduce any new security issues other than as noted in the
   referenced IS-IS protocol extensions.

Chunduri & Tantsura     Expires October 26, 2018                [Page 6]
Internet-DrafIS-IS Multi Topology Deployment Considerations   April 2018

9.  References

9.1.  Normative References

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, DOI 10.17487/RFC1195,
              December 1990, <https://www.rfc-editor.org/info/rfc1195>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

9.2.  Informative References

   [I-D.herbert-ila-mobile]
              Herbert, T. and K. Bogineni, "Identifier Locator
              Addressing for Mobile User-Plane", draft-herbert-ila-
              mobile-01 (work in progress), March 2018.

   [I-D.ietf-dmm-srv6-mobile-uplane]
              Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,
              daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing
              IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile-
              uplane-01 (work in progress), March 2018.

   [I-D.ietf-rtgwg-multihomed-prefix-lfa]
              Sarkar, P., Hegde, S., Chunduri, U., Tantsura, J., and H.
              Gredler, "LFA selection for Multi-Homed Prefixes", draft-
              ietf-rtgwg-multihomed-prefix-lfa-06 (work in progress),
              February 2018.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120,
              DOI 10.17487/RFC5120, February 2008,
              <https://www.rfc-editor.org/info/rfc5120>.

   [RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
              Authentication", RFC 5304, DOI 10.17487/RFC5304, October
              2008, <https://www.rfc-editor.org/info/rfc5304>.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
              2008, <https://www.rfc-editor.org/info/rfc5305>.

Chunduri & Tantsura     Expires October 26, 2018                [Page 7]
Internet-DrafIS-IS Multi Topology Deployment Considerations   April 2018

   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
              DOI 10.17487/RFC5308, October 2008,
              <https://www.rfc-editor.org/info/rfc5308>.

   [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
              and M. Fanto, "IS-IS Generic Cryptographic
              Authentication", RFC 5310, DOI 10.17487/RFC5310, February
              2009, <https://www.rfc-editor.org/info/rfc5310>.

   [RFC7645]  Chunduri, U., Tian, A., and W. Lu, "The Keying and
              Authentication for Routing Protocol (KARP) IS-IS Security
              Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015,
              <https://www.rfc-editor.org/info/rfc7645>.

Authors' Addresses

   Uma Chunduri
   Huawei USA
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Email: uma.chunduri@huawei.com

   Jeff Tantsura
   Nuage Networks
   755 Ravendale Drive
   Mountain View, CA  94043
   USA

   Email: jefftant.ietf@gmail.com

Chunduri & Tantsura     Expires October 26, 2018                [Page 8]