[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 5120

Network Working Group                           Tony Przygienda (Redback)
Internet Draft                                     Naiming Shen (Redback)
<draft-ietf-isis-wg-multi-topology-04.txt>        Nischal Sheth (Juniper)
June 2002
Expires: December 2002




              M-ISIS: Multi Topology (MT) Routing in IS-IS




1. Status of This Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.  Internet-Drafts are working
    documents of the Internet Engineering Task Force (IETF), its areas,
    and its working groups.  Note that other groups may also distribute
    working documents as Internet-Drafts.

    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."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.


2. Abstract

    This draft describes an optional mechanism within ISIS used today
    by many ISPs for IGP routing within their clouds. This draft
    describes how to run within a single ISIS domain a set of
    independent IP topologies that we call Multi-Topologies (MTs).
    This MT extension can be used for variety of purposes such as an
    in-band management network ``on top'' of the original IGP topology,
    maintain separate IGP routing domains for isolated multicast or
    IPv6 islands within the backbone, or force a subset of an address
    space to follow a different topology.


3. Specification of Requirements

   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].



Przygienda, Shen, Sheth     Expires December 2002                [Page 1]


Internet Draft                   M-ISIS                         June 2002


4.  Introduction

    Maintaining multiple MTs for ISIS [ISO10589 , RFC1195] in a
    backwards-compatible manner necessitates several extensions to the
    packet encoding and additional SPF procedures.  The problem can
    be partitioned into forming of adjacencies, and advertising of
    prefixes and reachable intermediate systems within each topology.
    Having put all the necessary additional information in place, it
    must be properly used by MT capable SPF computation. The following
    sections describe each of the problems separately. To simplify the
    text, ``standard'' ISIS topology is defined to be MT ID #0 (zero).


5.  Maintaining MT Adjacencies

    Each adjacency formed MUST be classified as belonging to a set of
    MTs on the interface.  This is achieved by adding a new TLV into
    IIH packets that advertises which topologies the interface belongs
    to.  If MT #0 is the only MT on the interface, it is optional to
    advertise it in the new TLV. Thus not including such a TLV in the
    IIH implies MT ID #0 capability only. Through this exchange of MT
    capabilities, a router is able to advertise the IS TLVs in LSPs
    with common MT set over those adjacencies.

    As a simplifying side-effect, boundaries between levels will be the
    same for all MTs.

    In the case of adjacency contains multiple MTs on an interface, and
    if there exists overlapping IP address space among the topologies,
    additional mechanism MAY be used to resolve the topology identity of
    the incoming IP packets on the interface.

5.1.  Forming Adjacencies on Point-to-Point Interfaces

    Adjacencies on point-to-point interfaces are formed as usual with
    ISIS routers not implementing MT extensions.  If local router does
    not participate in certain MTs, it will not advertise those MTIDs
    in it's IIHs and thus will not include that neighbor within it's
    topology based LSPs.  On the other hand, if a MTID is not
    detected in remote side's IIHs, the local router MUST NOT include
    that neighbor within it's MT LSPs. The local router SHOULD NOT form
    adjacency if they don't have at least one common MT set over the
    interface.

5.2.  Forming Adjacencies on Broadcast Interfaces

    On a LAN, all the routers on the LAN which implement the MT
    extension MAY advertise their MT capability TLV in their IIHs.
    If there is at least one adjacency on the LAN interface which
    belongs to this MT, the MT capable router MUST include according
    MT IS Reachable TLV in its LSP, otherwise it MAY include this MT


Przygienda, Shen, Sheth     Expires December 2002                 [Page 2]


Internet Draft                   M-ISIS                          June 2002


    IS Reachable TLV in it's LSP if the LAN interface participates in
    this MT set.

    Two Routers on a LAN SHALL always establish adjacency regardless
    whether they have common MT set or not. This is to ensure all
    the routers on the LAN can correctly elect the same DIS. The IS
    SHOULD NOT include the MT IS TLV in its LSP if none of the
    adjacencies on the LAN contains this MT.

    The DIS, CSNP and PSNP functions are not changed by MT extension.


6.  Advertising MT Reachable Intermediate Systems in LSPs

    A router MUST include within its LSPs in the Reachable Intermediate
    Systems TLVs only adjacent nodes that are participating in the
    according topology and advertise such TLVs only if it participates
    itself in the according topology.  Standard Reachable Intermediate
    Systems TLV is acting here as MT ID #0 equivalent of the newly
    introduced MT Reachable Intermediate Systems TLV. A router MUST
    announce the MT IS TLV when there is at least one adjacency on the
    interface that belongs to this MT, otherwise it MAY announce the MT
    IS TLV of an adjacency for a given MT if this interface participates
    in the LAN.

    Since it is not possible to prevent a router that does not understand
    MT extensions from being responsible for generation of the according
    pseudo-node, it is not possible either to introduce special TLVs in
    the pseudo-node LSPs nor run distinct DIS elections per MT.
    Therefore, a generated pseudo-node LSP by DIS MUST contain in its
    IS Reachable TLV all nodes on the LAN as usual regardless of their
    MT capabilities. In other words, there is no change to the
    pseudo-node LSP construction.


7.  MTs and Overload, Partition and Attached Bits

    As stated earlier, all MTs share the same set of L1-L2 boundaries and
    NETs.  However, a router could for each of the MTs become potentially
    partitioned, overloaded and attached independently.  To prevent
    unnecessary complexity, MT extensions does not support partition
    repair.  Besides that, overload bit is assumed to be shared for all
    topologies. Attached bit is part of the MT TLV being distributed
    within a node's LSP fragment 0. Since each adjacency can belong to
    different MTs, it is possible that some MTs are L2 attached, and
    others are not on the same router.


8.  Advertising MT Specific IP Prefixes

    Each of the MTs commands its own address space so a new TLV is
    necessary for prefixes stored in MTs other than MT ID #0.  To


Przygienda, Shen, Sheth     Expires December 2002                [Page 3]


Internet Draft                   M-ISIS                         June 2002


    make the encoding less confusing when same prefixes are present in
    multiple MTs and accelerate SPF per MT, rather than adding a sub-TLV
    in TE extensions, a new TLV is introduced for that purpose that
    closely follows TE encoding [LS01].


9.  MT SPF Computation

    Each MT MUST run its own instance of the decision process.
    The LSP overload bit and pseudo-node LSPs are used by all topologies
    during computation.  Reverse connectivity check within SPF MUST
    follow the according MT to assure the bi-directional reachability.
    The results of each computation MUST be stored in a separate RIB,
    otherwise overlapping addresses in different topologies could
    lead to undesirable routing behavior such as forwarding loops. The
    forwarding logic and configuration need to ensure the same MT is
    traversed from the source to the destination for packets. The
    nexthops derived from the MT SPF MUST belong to the adjacencies
    conforming to the same MT for correct forwarding.

9.1 Generic MT SPF (GSPF) for Network Management

    When multiple ISIS topologies exist within a domain, some of the
    routers can be configured to participate in a subset of the MTs
    in the network. For example, some routers can be IPv4 multicast MT
    only. Since each MT SPF installs the routes exclusively into the
    RIB belonging to their corresponding topology, there may not exist
    a routing path to reach some of those routers from the network
    management or troubleshooting point of view.

    To allow for management access to all routers irregardless of their
    MT configuration, we introduce here the concept of MT Management
    Colored Prefix and Generic MT SPF. A MT Management Colored Prefix is
    a MT IPv4 Reachable Prefix attached with the MT Management Prefix
    Color sub-TLV in LSPs. For example, a loopback interface IP adress
    of a MT based router can be configured with this MT Management
    Prefix Color to allow network management access to this router.
    The optional Generic MT SPF is an ISIS decision process that runs
    SPF algorithm with all the LSPs of routers which support Generic
    MT SPF, and it understands all the Reachable IS TLVs regardless of
    their MT property (including MT ID #0). It searches through all the
    LSPs for MT based Reachable IPv4 Prefixes TLV with the MT Management
    Color and installs them into the ``standard'' or ``management''
    RIB during the Generic MT SPF. The router's Generic MT SPF
    capability is indicated with a bit inside all the MT capability TLVs
    within the node LSP fragment 0.

    The reverse connectivity check of Generic MT SPF MUST match
    the same MT between the two nodes.

    Implementations SHOULD allow the administrator to control the
    setting of MT Management Color to specific prefixes of the router


Przygienda, Shen, Sheth     Expires December 2002                [Page 4]


Internet Draft                   M-ISIS                         June 2002


    and the setting of Generic MT SPF to install the MT Mangement
    colored routes into specific RIB. It is recommended for the
    administrator's to ensure consistent configuration of all routers
    in the domain to prevent undesirable forwarding behavior.


10.  LSP Flooding

    The LSP flooding mechanism is not changed by this MT extension.

    An implementation MAY have the option to use additional MT
    information in the LSP and on the adjacency to reduce some of the
    unnecessary LSP flooding over the point-to-point links. If a
    receiving interface and an outgoing interface don't share any
    common MT set, the implementation MAY have the option not to flood
    this LSP out on that interface. Since the fragment zero LSP
    contains the MTID, the MT capability of any LSP can be identified.
    If the LSP and the adjacencies of an outgoing interface do not
    share any common MT capability, the implementation MAY have the
    option not to flood this LSP out on that interface. An
    implementation MAY want to have the operators to control those
    optimization base on network topology and environment to ensure
    the LSP flooding reliability. For the neighbors have the Generic
    MT SPF enabled, this flooding optimization SHOULD NOT be used
    over the links to those neighbors.

    When there is an adjacency MT set change over an point-to-point
    link and the adjacency is in UP state, both sides SHOULD force an
    exchange of one set of CSNPs over that link.


11.  Packet Encoding

    Three new TLVs are added to support MT extensions.  One of them is
    common for the LSPs and IIHs.  Encoding of Intermediate System TLV
    and IPv4 Reachable Prefixes is tied to traffic engineering
    extensions [LS01] to simplify the implementation effort. The main
    reasons we choose using new TLVs instead of using sub-TLVs inside
    existing TLV type-22 and type-135 are: In many cases,
    multi-topologies are non-congruent, using sub-TLV approach will
    not save LSP space; Many sub-TLVs are already being used in TLV
    type-22, and many more are being proposed while there is a maximum
    limit on the TLV size, from the existing TLVs; If traffic
    engineering or some other applications are being applied per
    topology level later, the new TLVs can automatically inherit the
    same attributes already defined for the ``standard'' IPv4 topology
    without going through long standard process to redefine them per
    topology.





Przygienda, Shen, Sheth     Expires December 2002                [Page 5]


Internet Draft                   M-ISIS                         June 2002


11.1.  Multi-Topology TLV

    TLV number of this TLV is 229.  It contains one or more MTs
    the router is participating in the following structure:

      x  CODE - 229
      x  LENGTH - total length of the value field, it should be 2
                    times the number of MT components.
      x  VALUE - one or more 2-byte MT components, structured
                   as follows:
                                              No. of Octets
          +--------------------------------+
          |G |A |R |R |        MT ID       |      2
          +--------------------------------+

          Bits R are reserved, should be set to 0 on transmission
          and ignored on receipt.

          Bit G represents the router Generic MT SPF (only valid
          in LSP fragment #0, otherwise should be set to 0 on
          transmission and ignored on receipt.) If the router is
          configured for GSPF, all the MT TLV occurrences in the LSP
          MUST set this G bit; if any of the MT TLV has this G bit
          cleared, the router will be completely disregarded during
          GSPF computation.

          Bit A represents the ATTACH bit for the MT (only valid
          in LSP fragment #0 for MTs other than ID #0, otherwise
          should be set to 0 on transmission and ignored on receipt.)

          MT ID is a 12-bit field containing the ID of the topology
          being announced.

    This MT TLV can advertise up to 127 MTs and it can occur multiple
    times if needed within IIHs and LSP fragment 0.  The result MT set
    should be the union of all the MT TLV occurrence in the packet. Any
    other ISIS PDU occurrence of this TLV MUST be ignored. Lack of
    MT TLV in hellos and fragment 0 LSP MUST be interpreted as
    participation of the advertising interface or router in
    MT ID #0 only. If a router advertises MT TLV, it has to advertise
    all the MTs it participates in, specifically including topology
    ID #0 also.

11.2.  MT Intermediate Systems TLV

    TLV number of this TLV is 222.  It is aligned with extended IS
    reachability TLV type 22 beside an additional two bytes in front at
    the beginning of the TLV.

      x  CODE - 222
      x  LENGTH - total length of the value field


Przygienda, Shen, Sheth     Expires December 2002                [Page 6]


Internet Draft                   M-ISIS                         June 2002


      x  VALUE - 2-byte MT membership plus the format of extended IS
                 reachability TLV, structured as follows:

                                              No. of Octets
          +--------------------------------+
          |R |R |R |R |        MT ID       |      2
          +--------------------------------+
          | extended IS TLV format         |    11 - 253
          +--------------------------------+
          .                                .
          .                                .
          +--------------------------------+
          | extended IS TLV format         |    11 - 253
          +--------------------------------+

          Bits R are reserved, should be set to 0 on transmission
          and ignored on receipt.

          MT ID is a 12-bit field containing the ID of the topology
          being announced.

          After the 2-byte MT membership format, the MT IS content is
          in the same format as extended IS TLV, type 22 [LS01]. It
          can contain up to 23 neighbors of the same MT if no sub-TLVs
          are used.

    This TLV can occur multiple times.

11.3.  Multi-Topology Reachable IPv4 Prefixes TLV

    TLV number of this TLV is 235.  It is aligned with extended IS
    reachability TLV type 135 beside an additional two bytes in front.

      x  CODE - 235
      x  LENGTH - total length of the value field
      x  VALUE - 2-byte MT membership plus the format of extended
                 extended IP reachability TLV, structured as follows:

                                              No. of Octets
          +--------------------------------+
          |R |R |R |R |        MT ID       |      2
          +--------------------------------+
          | extended IP TLV format         |    5 - 253
          +--------------------------------+
          .                                .
          .                                .
          +--------------------------------+
          | extended IP TLV format         |    5 - 253
          +--------------------------------+

          Bits R are reserved, should be set to 0 on transmission


Przygienda, Shen, Sheth     Expires December 2002                [Page 7]


Internet Draft                   M-ISIS                         June 2002


          and ignored on receipt.

          MT ID is a 12-bit field containing the ID of the topology
          being announced.

          After the 2-byte MT membership format, the MT IPv4 content
          is in the same format as extended IP reachability TLV,
          type 135 [LS01].

    This TLV can occur multiple times.

    A new sub-TLV for this MT Reachable IPv4 Prefixes TLV is proposed:

      x Sub-TLV CODE - 117
      x LENGTH - 4 octets
      x VALUE - The value of 1 of this sub-TLV is reserved for
                  MT Management Prefix Color.

                                              No. of Octets
          +--------------------------------+
          |  MT IPv4 Prefix Color Value    |       4
          +--------------------------------+

          The value of 1 of this sub-TLV is reserved for MT Management
          Prefix Color.

    If the MT Management Prefix color is present in this TLV, and the
    router announces this TLV has the Generic MT SPF enabled, the local
    router MAY need to install this prefix into the ``standard'' or
   ``management'' RIB as described in section 9.1.

11.4.  Multi-Topology Reachable IPv6 Prefixes TLV

    TLV number of this TLV is 237.  It is aligned with IPv6 Reachability
    TLV type 236 beside an additional two bytes in front.

      x  CODE - 237
      x  LENGTH - total length of the value field
      x  VALUE - 2-byte MT membership plus the format of IPv6
                 Reachability TLV, structured as follows:

                                              No. of Octets
          +--------------------------------+
          |R |R |R |R |        MT ID       |      2
          +--------------------------------+
          | IPv6 Reachability format       |    6 - 253
          +--------------------------------+
          .                                .
          .                                .
          +--------------------------------+
          | IPv6 Reachability format       |    6 - 253
          +--------------------------------+


Przygienda, Shen, Sheth     Expires December 2002                [Page 8]


Internet Draft                   M-ISIS                         June 2002


          Bits R are reserved, should be set to 0 on transmission
          and ignored on receipt.

          MT ID is a 12-bit field containing the ID of the topology
          being announced.

          After the 2-byte MT membership format, the MT IPv6 context
          is in the same format as IPv6 Reachability TLV,
          type 236 [H01].

    This TLV can occur multiple times.

11.5.  Reserved MT ID Values

    Certain MT topologies are assigned to serve pre-determined purposes:

     -  MT ID #0:          Equivalent to the ``standard'' topology.
     -  MT ID #1:          Reserved for in-band management purposes.
     -  MT ID #2:          Reserved for IPv6 routing topology.
     -  MT ID #3:          Reserved for IPv4 multicast routing topology.
     -  MT ID #4-#3995:    Reserved for IETF consensus.
     -  MT ID #3996-#4095: Reserved for development, experimental and
                           proprietary features.


12.  Acknowledgments

    The authors would like to thank Andrew Partan, Dino Farinacci,
    Derek Yeung, Alex Zinin, Stefano Previdi, Heidi Ou, Steve Luong,
    and Mike Shand for the discussion, their review, comments and
    contributions to this draft.


13.  Security Consideration

    ISIS security applies to the work presented.  No specific security
    issues with the proposed solutions are known. The authentication
    procedure for ISIS PDUs is the same regardless of MT information
    inside the ISIS PDUs.


14.  Normative References

    [ISO10589] ISO.  Intermediate System to Intermediate System Routing
               Exchange Protocol for Use in Conjunction with the Protocol
               for Providing the Connectionless-Mode Network Service.
               ISO 10589, 1992.

    [RFC1195]  R. Callon.  Use of OSI ISIS for Routing in TCP/IP and
               Dual Environments. RFC 1195, December 1990.



Przygienda, Shen, Sheth     Expires December 2002                [Page 9]


Internet Draft                   M-ISIS                         June 2002


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

    [LS01]     T. Li and H. Smit.  IS-IS Extensions for Traffic
               Engineering. draft-ietf-isis-traffic-04.txt, August 2001
               (work in progress)

    [H01]      C. Hopps. Routing IPv6 with IS-IS.
               draft-ietf-isis-ipv6-02.txt, April 2001
               (work in progress)


15.  Authors' Addresses

    Tony Przygienda
    Redback Networks
    350 Holger Way
    San Jose, CA, 95134 USA
    prz@redback.com

    Naiming Shen
    Redback Networks
    350 Holger Way
    San Jose, CA, 95134 USA
    naiming@redback.com

    Nischal Sheth
    Juniper Networks
    1194 North Mathilda Avenue
    Sunnyvale, CA 94089 USA
    nsheth@juniper.net






















Przygienda, Shen, Sheth     Expires December 2002               [Page 10]


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