Internet Engineering Task Force                           Tony Przygienda
INTERNET DRAFT                                               Naiming Shen
                                                         Redback Networks
                                                            Nischal Sheth
                                                         Juniper Networks
                                                             January 2002

                 M-ISIS: Multi Topology Routing in IS-IS
               <draft-ietf-isis-wg-multi-topology-02.txt>


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.



Abstract

    This draft describes an optional implementation technique within
    IS-IS [ISO90 , Cal90a , Cal90b] used today by many ISPs for
    routing within their clouds.  IS-IS is an interior gateway routing
    protocol developed originally by OSI and used with IP extensions as
    IGP. This draft describes how to run within a single ISIS domain a
    set of independent IP topologies that we call Multi-Topologies
    (MTs), or Multiple views of Topology.  This MT extension can be used
    for variety of purposes such as an in-band management network
    ``on top'' of the original IGP topology, transport multiple
    overlapping IP address spaces in the same protocol, force a subset
    of an address space to follow a different topology, or finally,
    even maintain a restricted number of protocol based VPNs.


1.  Introduction

    Maintaining multiple MTs for ISIS in a backwards-compatible manner
    necessitates several extensions to the packet encoding and
    additional SPF procedures.  The problem can be partitioned into


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


Internet Draft                     M-ISIS                    January 2002


    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 computations.  The following sections
    describe each of the problems separately.  To simplify the text,
    ``normal'' IS-IS topology is defined to be MT ID #0 (zero).


2.  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.  And 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 adjacencies 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 packets on the interface.


2.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 MAY not form
    adjacency if they don't have at least one common MT set over the
    interface.


2.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.
    A MT capable router MUST include according MT PNode in its LSP MT IS
    Reachable TLV if there is at least one adjacency on the LAN interface
    which belongs to this MT or it MAY include this MT PNode in it's LSP
    if the LAN interface participates in this MT set.




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


Internet Draft                     M-ISIS                     January 2002


    Two Routers on a LAN SHOULD 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
    may not contain 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.


3.  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 MAY
    announce the adjacency of IS TLVs for a given MT if this interface
    participates in the LAN or it MUST announce the IS TLV when there is
    at least one adjacency on the interface belongs to this MT.

    Since it is not possible to prevent a router that does not understand
    MT extensions from being responsible for generation of the according
    PNode, it is not possible either to introduce special TLVs in the
    PNode LSPs nor run distinct DIS elections per MT. Therefore, a
    generated PNode 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.


4.  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.  MT other than ID #0 must use the same overload bit
    during the computation.  Attached bit is part of the MT TLV being
    distributed within a node's LSP fragment 0.


5.  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
    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 [LS99].



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


Internet Draft                     M-ISIS                    January 2002


6.  Multi-Topology SPF Computation

    Each MT must run each own instance of the decision process.
    Overload bit and LAN PNode LSPs are shared for 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 MAY be stored in a separate RIB
    if 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.


7.  LSP Flooding

    The LSP flooding mechanism is not changed by 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. If a receiving interface and an outgoing
    interface don't share any common MT set, the LSP MAY not need to
    be flooded 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 LSP MAY not need to be flooded out on
    that interface. An implementation MAY want to have the operators to
    control those optimization base on network environment to ensure the
    LSP flooding reliability.


8.  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 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,
    for this extension, we have a choice not to take away more space
    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 ``normal'' IPv4 topology without going through long standard
    process to redefine them per topology.



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


Internet Draft                     M-ISIS                    January 2002


8.1.  Multi-Topology TLV

    TLV number of this TLV is 229.  It contains one or more
    multi-topology the router is participating in (including MT ID #0)
    the following structure

         x code   - 229
         x length - total length of the value field, it should be 2
                    times the number of topology.
         x value  - 2 bytes of MT ID and control starting from most
                    significant bits.
                    1 bit indicating the existence of sub-TLVs for the MT
                    1 bit presenting the ATTACH bit for the MT
                     (only valid in LSP fragment #0 and for MTs other
                      than ID #0, otherwise reserved)
                    2 reserved bits
                    12 least significant bits are the MT ID

    This MT TLV can advertise up to 127 topologies and it can occur
    multiple times if needed within IIHs and LSP fragment 0.  Any other
    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 topologies it
    participate in, specifically including topology ID #0 also.


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

         2 bytes of MT membership
                  4 bits (most significant) are reserved
                 12 least significant bits are the MT ID
         0-251 octets of structures used in TLV type 22.

    This TLV can occur multiple times.


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

         2 bytes of MT membership
                  4 bits (most significant) are reserved
                 12 least significant bits are the MT ID
         0-251 octets of structures used in TLV type 135.



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


Internet Draft                     M-ISIS                    January 2002

    This TLV can occur multiple times.

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

         Sub-TLV type    117
         Length          4 octets
         Name            MT IPv4 Prefix Color

         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, a MT based
    SPF computation MAY also need to install this prefix into the
    ``standard'' or ``management'' RIB. This MAY be necessary for
    example in the case of MT based network management.


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

         2 bytes of MT membership
                  4 bits (most significant) are reserved
                 12 least significant bits are the MT ID
         0-251 octets of structures used in TLV type 236 [H01].

    This TLV can occur multiple times.

    This TLV is used for general purpose IPv6 topologies. For ``normal''
    or ``default'' IPv6 topology, MT ID #2, the router MAY advertise
    either the TLV type 236 [H01] or TLV type 237 with MT ID #2 as its
    membership, or advertise both of them. The ``default'' IPv6 topology
    MUST understand both Reachable IPv6 Prefixes TLVs.


8.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 Multicast Routing Topology.
     -  MT ID #4-#8190:  Reserved for IETF consensus.
     -  MT ID #8191:     Reserved for development, experimental and
                         proprietary features.


9.  Acknowledgments

    The authors would like to thank Andrew Partan, Dino Farinacci,
    Derek Yeung, Alex Zinin, Stefano Previdi, Heidi Ou, Steve Luong,

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


Internet Draft                     M-ISIS                    January 2002

    and Mike Shand for the discussion, their review, comments and
    contributions to this draft.


10.  Security Consideration

    ISIS security applies to the work presented.  No specific security
    issues with the proposed solutions are known.


11.  References

    [Cal90a]  R. Callon.  OSI ISIS Intradomain Routing Protocol.
              INTERNET-RFC, Internet Engineering Task Force, February
              1990.

    [Cal90b]  R. Callon.  Use of OSI ISIS for Routing in TCP/IP and Dual
              Environments.  INTERNET-RFC, Internet Engineering Task
              Force, December 1990.

    [ISO90]   ISO.  Information Technology - Telecommunications and
              Information Exchange between Systems - Intermediate System
              to Intermediate System Routing Exchange Protocol for
              Use in Conjunction with the Protocol for Providing the
              Connectionless-Mode Network Service.  ISO, 1990.

    [LS99]    T. Li and H. Smit.  IS-IS Extensions for Traffic
              Engineering.  work-in-progress, Internet Engineering Task
              Force, 1999.

    [H01]     C. Hoops. Routing IPv6 with IS-IS. work-in-progress,
              Internet Engineering Task Force, 2001


12.  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 July 2002                 [Page 7]