doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc5120.txt b/doc/rfc/rfc5120.txt
new file mode 100644
index 0000000..0f25b57
--- /dev/null
+++ b/doc/rfc/rfc5120.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                      T. Przygienda
+Request for Comments: 5120                                       Z2 Sagl
+Category: Standards Track                                        N. Shen
+                                                           Cisco Systems
+                                                                N. Sheth
+                                                        Juniper Networks
+                                                           February 2008
+
+
+                M-ISIS: Multi Topology (MT) Routing in
+          Intermediate System to Intermediate Systems (IS-ISs)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes an optional mechanism within Intermediate
+   System to Intermediate Systems (IS-ISs) used today by many ISPs for
+   IGP routing within their clouds.  This document describes how to run,
+   within a single IS-IS domain, a set of independent IP topologies that
+   we call Multi-Topologies (MTs).  This MT extension can be used for a
+   variety of purposes, such as an in-band management network "on top"
+   of the original IGP topology, maintaining separate IGP routing
+   domains for isolated multicast or IPv6 islands within the backbone,
+   or forcing a subset of an address space to follow a different
+   topology.
+
+1.  Introduction
+
+   Maintaining multiple MTs for IS-IS [ISO10589] [RFC1195] in a
+   backwards-compatible manner necessitates several extensions to the
+   packet encoding and additional Shortest Path First (SPF) procedures.
+   The problem can be partitioned into the 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" IS-IS topology is defined to be MT ID
+   #0 (zero).
+
+
+
+
+
+
+Przygienda, et al.          Standards Track                     [Page 1]
+
+RFC 5120                         M-ISIS                    February 2008
+
+
+1.1.  Conventions Used in This Document
+
+   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].
+
+1.2.  Definitions of Terms Used in This Document
+
+   CSNP Complete Sequence Number Packet.  Used to describe all the
+        contents of a link state database of IS-IS.
+
+   DIS  Designated Intermediate System.  The intermediate system elected
+        to advertise the pseudo-node for a broadcast network.
+
+   IIH  IS-IS Hello.  Packets that are used to discover adjacent
+        intermediate systems.
+
+   LSP  Link State Packet.  Packet generated by an intermediate system
+        and lists adjacent systems, prefixes, and other information.
+
+   PSNP Partial Sequence Number Packet.  Used to request information
+        from an adjacent intermediate system's link state database.
+
+   SPF  Shortest Path First.  An algorithm that takes a database of
+        nodes within a domain and builds a tree of connectivity along
+        the shortest paths through the entire network.
+
+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 to which topologies the interface belongs.
+   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.
+
+   The case of adjacency contains multiple MTs on an interface, and if
+   there exists an overlapping IP address space among the topologies,
+   additional mechanisms MUST be used to resolve the topology identity
+   of the incoming IP packets on the interface.  See further discussion
+   in Section 8.2.2 of this document.
+
+
+
+
+
+
+
+
+Przygienda, et al.          Standards Track                     [Page 2]
+
+RFC 5120                         M-ISIS                    February 2008
+
+
+2.1.  Forming Adjacencies on Point-to-Point Interfaces
+
+   Adjacencies on point-to-point interfaces are formed as usual with
+   IS-IS routers not implementing MT extensions.  If a local router does
+   not participate in certain MTs, it will not advertise those MT IDs in
+   its IIHs and thus will not include that neighbor within its LSPs.  On
+   the other hand, if an MT ID is not detected in the remote side's
+   IIHs, the local router MUST NOT include that neighbor within its
+   LSPs.  The local router SHOULD NOT form an adjacency if they don't
+   have at least one common MT over the interface.
+
+2.2.  Forming Adjacencies on Broadcast Interfaces
+
+   On a LAN, all the routers on the LAN that implement the MT extension
+   MAY advertise their MT capability TLV in their IIHs.  If there is at
+   least one adjacency on the LAN interface that belongs to this MT, the
+   MT capable router MUST include the corresponding MT IS Reachable TLV
+   in its LSP, otherwise it MAY include this MT IS Reachable TLV in its
+   LSP if the LAN interface participates in this MT set.
+
+   Two routers on a LAN SHALL always establish adjacency, regardless of
+   whether or not they have a common MT.  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 contain 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 TLV-only adjacent nodes that are participating in the
+   corresponding topology and advertise such TLVs only if it
+   participates itself in the corresponding topology.  The Standard
+   Reachable Intermediate Systems TLV is acting here as MT ID #0, the
+   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 the generation of the
+   according pseudo-node, it is possible to neither 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
+
+
+
+
+
+Przygienda, et al.          Standards Track                     [Page 3]
+
+RFC 5120                         M-ISIS                    February 2008
+
+
+   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
+
+   For each of the MTs, a router could become potentially partitioned,
+   overloaded, and attached independently.  To prevent unnecessary
+   complexity, MT extensions do not support MT based partition repair.
+   The overload, partition, and attached bits in the LSP header only
+   reflect the status of the default topology.
+
+   Attached bit and overload bit are part of the MT TLV being
+   distributed within a node's LSP fragment zero.  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.  The overload bit in
+   the MT TLV can be used to signal the topology being overloaded.  An
+   MT-based system is considered overloaded if the overload bit in the
+   MT is set.
+
+   Route leaking between the levels SHOULD only be performed within the
+   same MT.
+
+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 Traffic Engineered (TE) extensions, a new TLV is introduced for
+   that purpose that closely follows TE encoding [RFC3784].
+
+6.  MT SPF Computation
+
+   Each MT MUST run its own instance of the decision process.  The
+   pseudo-node LSPs are used by all topologies during computation.  Each
+   non-default topology MAY have its attached bit and overload bit set
+   in the MT TLV.  A reverse-connectivity check within SPF MUST follow
+   the according MT to assure the bi-directional reachability within the
+   same MT.
+
+   The results of each computation SHOULD be stored in a separate
+   Routing Information Base (RIB), in normal cases, 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
+
+
+
+Przygienda, et al.          Standards Track                     [Page 4]
+
+RFC 5120                         M-ISIS                    February 2008
+
+
+   conforming to the same MT for correct forwarding.  It is recommended
+   for the administrators to ensure consistent configuration of all
+   routers in the domain to prevent undesirable forwarding behavior.
+
+   No attempt is made in this document to allow one topology to
+   calculate routes using the routing information from another topology
+   inside SPF.  Even though it is possible to redistribute and leak
+   routes from another IS-IS topology or from external sources, the
+   exact mechanism is beyond the scope of this document.
+
+7.  Packet Encoding
+
+   Four 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
+   [RFC3784] to simplify the implementation effort.  The main reasons we
+   chose to use new TLVs instead of using sub-TLVs inside existing TLV
+   type-22 and type-135 are:
+
+      1.  In many cases, multi-topologies are non-congruent, using the
+          sub-TLV approach will not save LSP space;
+
+      2.  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;
+
+      3.  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" topology without going through long standard
+          process to redefine them per topology.
+
+7.1.  Multi-Topology TLV
+
+   The 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
+                      +--------------------------------+
+                      |O |A |R |R |        MT ID       |      2
+                      +--------------------------------+
+
+
+
+
+
+Przygienda, et al.          Standards Track                     [Page 5]
+
+RFC 5120                         M-ISIS                    February 2008
+
+
+      Bit O represents the OVERLOAD bit for the MT (only valid in LSP
+      fragment zero for MTs other than ID #0, otherwise SHOULD be set to
+      0 on transmission and ignored on receipt).
+
+      Bit A represents the ATTACH bit for the MT (only valid in LSP
+      fragment zero for MTs other than ID #0, otherwise SHOULD be set to
+      0 on transmission and ignored on receipt).
+
+      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.
+
+   This MT TLV can advertise up to 127 MTs.  It is announced in IIHs and
+   LSP fragment 0, and can occur multiple times.  The resulting MT set
+   SHOULD be the union of all the MT TLV occurrences in the packet.  Any
+   other IS-IS PDU occurrence of this TLV MUST be ignored.  Lack of MT
+   TLV in hellos and fragment zero LSPs 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.
+
+7.2.  MT Intermediate Systems TLV
+
+   The 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
+      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.
+
+
+
+
+Przygienda, et al.          Standards Track                     [Page 6]
+
+RFC 5120                         M-ISIS                    February 2008
+
+
+      MT ID is a 12-bit field containing the non-zero MT ID of the
+      topology being announced.  The TLV MUST be ignored if the ID is
+      zero.  This is to ensure the consistent view of the standard
+      unicast topology.
+
+      After the 2-byte MT membership format, the MT IS content is in the
+      same format as extended IS TLV, type 22 [RFC3784].  It can contain
+      up to 23 neighbors of the same MT if no sub-TLVs are used.
+
+   This TLV can occur multiple times.
+
+7.3.  Multi-Topology Reachable IPv4 Prefixes TLV
+
+   The TLV number of this TLV is 235.  It is aligned with extended IP
+   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 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 and
+      ignored on receipt.
+
+      MT ID is a 12-bit field containing the non-zero ID of the topology
+      being announced.  The TLV MUST be ignored if the ID is zero.  This
+      is to ensure the consistent view of the standard unicast topology.
+
+      After the 2-byte MT membership format, the MT IPv4 content is in
+      the same format as extended IP reachability TLV, type 135
+      [RFC3784].
+
+   This TLV can occur multiple times.
+
+
+
+
+
+
+Przygienda, et al.          Standards Track                     [Page 7]
+
+RFC 5120                         M-ISIS                    February 2008
+
+
+7.4.  Multi-Topology Reachable IPv6 Prefixes TLV
+
+   The 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
+                 +--------------------------------+
+
+      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.  The TLV MUST be ignored if the ID is zero.
+
+      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.
+
+7.5.  Reserved MT ID Values
+
+   Certain MT topologies are assigned to serve predetermined purposes:
+
+   -  MT ID #0:          Equivalent to the "standard" topology.
+   -  MT ID #1:          Reserved for IPv4 in-band management
+                         purposes.
+   -  MT ID #2:          Reserved for IPv6 routing topology.
+   -  MT ID #3:          Reserved for IPv4 multicast routing topology.
+   -  MT ID #4:          Reserved for IPv6 multicast routing topology.
+   -  MT ID #5:          Reserved for IPv6 in-band management
+                         purposes.
+   -  MT ID #6-#3995:    Reserved for IETF consensus.
+   -  MT ID #3996-#4095: Reserved for development, experimental and
+                         proprietary features [RFC3692].
+
+
+
+
+Przygienda, et al.          Standards Track                     [Page 8]
+
+RFC 5120                         M-ISIS                    February 2008
+
+
+8.  MT IP Forwarding Considerations
+
+   Using MT extension for IS-IS routing can result in multiple RIBs on
+   the system.  In this section, we list some of the known
+   considerations for IP forwarding in various MT scenarios.  Certain
+   deployment scenarios presented here imply different trade-offs in
+   terms of deployment difficulties and advantages obtained.
+
+8.1.  Each MT Belongs to a Distinct Address Family
+
+   In this case, each MT related route is installed into a separate RIB.
+   Multiple topologies can share the same IS-IS interface on detecting
+   the incoming packet address family.  As an example, IPv4 and IPv6 can
+   share the same interface without any further considerations under MT
+   ISIS.
+
+8.2.  Some MTs Belong to the Same Address Family
+
+8.2.1.  Each Interface Belongs to One and Only One MT
+
+   In this case, MTs can be used to forward packets from the same
+   address family, even with overlapping addresses, since the MTs have
+   their dedicated interfaces, and those interfaces can be associated
+   with certain MT RIBs and FIBs.
+
+8.2.2.  Multiple MTs Share an Interface with Overlapping Addresses
+
+   Some additional mechanism is needed to select the correct RIBs for
+   the incoming IP packets to determine the correct RIB to make a
+   forwarding decision.  For example, if the topologies are Quality of
+   Service (QoS) partitioned, then the Differentiated Services Code
+   Point (DSCP) bits in the IP packet header can be utilized to make the
+   decision.  Some IP headers, or even packet data information, MAY be
+   checked to make the forwarding table selection, for example, the
+   source IP address in the header can be used to determine the desired
+   forwarding behavior.
+
+   This topic is not unique to IS-IS or even to Multi-topology, it is a
+   local policy and configuration decision to make sure the inbound
+   traffic uses the correct forwarding tables.  For example, preferred
+   customer packets are sent through a Layer 2 Tunneling Protocol (L2TP)
+   towards the high-bandwidth upstream provider, and other packets are
+   sent through a different L2TP to a normal-bandwidth provider.  Those
+   mechanisms are not part of the L2TP protocol specifications.
+
+   The generic approach of packet to multiple MT RIB mapping over the
+   same inbound interface is outside the scope of this document.
+
+
+
+
+Przygienda, et al.          Standards Track                     [Page 9]
+
+RFC 5120                         M-ISIS                    February 2008
+
+
+8.2.3.  Multiple MTs Share an Interface with Non-Overlapping Addresses
+
+   When there is no overlap in the address space among all the MTs,
+   strictly speaking, the destination address space classifies the
+   topology to which a packet belongs.  It is possible to install routes
+   from different MTs into a shared RIB.  As an example of such a
+   deployment, a special IS-IS topology can be set up for certain
+   External Border Gateway Protocol (eBGP) nexthop addresses.
+
+8.3.  Some MTs Are Not Used for Forwarding Purposes
+
+   MT in IS-IS MAY be used even if the resulting RIB is not used for
+   forwarding purposes.  As an example, multicast Reverse Path
+   Forwarding (RPF) check can be performed on a different RIB than the
+   standard unicast RIB, albeit an entirely different RIB is used for
+   the multicast forwarding.  However, an incoming packet MUST still be
+   clearly identified as belonging to a unique topology.
+
+9.  MT Network Management Considerations
+
+   When multiple IS-IS topologies exist within a domain, some of the
+   routers can be configured to participate in a subset of the MTs in
+   the network.  This section discusses some of the options we have to
+   enable operations or the network management stations to access those
+   routers.
+
+9.1.  Create Dedicated Management Topology to Include All the Nodes
+
+   This approach is to set up a dedicated management topology or 'in-
+   band' management topology.  This 'mgmt' topology will include all the
+   routers need to be managed.  The computed routes in the topology will
+   be installed into the 'mgmt' RIB.  In the condition that the 'mgmt'
+   topology uses a set of non-overlapping address space with the default
+   topology, those 'mgmt' routes can also be optionally installed into
+   the default RIB.  The advantages of duplicate 'mgmt' routes in both
+   RIBs include:  the network management utilities on the system does
+   not have to be modified to use a specific RIB other than the default
+   RIB; the 'mgmt' topology can share the same link with the default
+   topology if so designed.
+
+
+
+
+
+
+
+
+
+
+
+
+Przygienda, et al.          Standards Track                    [Page 10]
+
+RFC 5120                         M-ISIS                    February 2008
+
+
+9.2.  Extend the Default Topology to All the Nodes
+
+   Even in the case that default topology is not used on some of the
+   nodes in the IP forwarding, we MAY want to extend the default
+   topology to those nodes for the purpose of network management.
+   Operators SHOULD set high costs on the links that belong to the
+   extended portion of the default topology.  This way, the IP data
+   traffic will not be forwarded through those nodes during network
+   topology changes.
+
+10.  Acknowledgments
+
+   The authors would like to thank Andrew Partan, Dino Farinacci, Derek
+   Yeung, Alex Zinin, Stefano Previdi, Heidi Ou, Steve Luong, Pekka
+   Savola, Mike Shand, Shankar Vemulapalli, and Les Ginsberg for the
+   discussion, their review, comments, and contributions to this
+   document.
+
+11.  Security Considerations
+
+   IS-IS security applies to the work presented.  No specific security
+   issues with the proposed solutions are known.  The authentication
+   procedure for IS-IS PDUs is the same regardless of MT information
+   inside the IS-IS PDUs.
+
+   Note that an authentication mechanism, such as the one defined in
+   [RFC3567], SHOULD be applied if there is high risk resulting from
+   modification of multi-topology information.
+
+   As described in Section 8.2.2, multiple topologies share an interface
+   in the same address space, some mechanism beyond IS-IS needs to be
+   used to select the right forwarding table for an inbound packet.  A
+   misconfiguration on the system or a packet with a spoofed source
+   address, for example, can lead to packet loss or unauthorized use of
+   premium network resource.
+
+12.  IANA Considerations
+
+   This document defines the following new IS-IS TLV types, which have
+   already been reflected in the IANA IS-IS TLV code-point registry:
+
+          Name                    Value
+
+          MT-ISN                  222
+          M-Topologies            229
+          MT IP. Reach            235
+          MT IPv6 IP. Reach       237
+
+
+
+
+Przygienda, et al.          Standards Track                    [Page 11]
+
+RFC 5120                         M-ISIS                    February 2008
+
+
+   IANA has created a new registry, "IS-IS Multi-Topology Parameters",
+   with the assignments listed in Section 7.5 of this document and
+   registration policies [RFC2434] for future assignments.  The MT ID
+   values range 6-3995 are allocated through Expert Review; values in
+   the range of 3996-4095 are reserved for Private Use.  In all cases,
+   assigned values are to be registered with IANA.
+
+13.  References
+
+13.1.  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]   Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
+               dual environments", RFC 1195, December 1990.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3692]   Narten, T., "Assigning Experimental and Testing Numbers
+               Considered Useful", BCP 82, RFC 3692, January 2004.
+
+   [RFC2434]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
+               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+               October 1998.
+
+13.2.  Informative References
+
+   [RFC3567]   Li, T. and R. Atkinson, "Intermediate System to
+               Intermediate System (IS-IS) Cryptographic
+               Authentication", RFC 3567, July 2003.
+
+   [RFC3784]   Smit, H. and T. Li, "Intermediate System to Intermediate
+               System (IS-IS) Extensions for Traffic Engineering (TE)",
+               RFC 3784, June 2004.
+
+   [H01]      C. Hopps, "Routing IPv6 with IS-IS", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+Przygienda, et al.          Standards Track                    [Page 12]
+
+RFC 5120                         M-ISIS                    February 2008
+
+
+Authors' Addresses
+
+   Tony Przygienda
+   Z2 Sagl
+   Via Rovello 32
+   CH-6942 Savosa
+   EMail: prz@net4u.ch
+
+   Naiming Shen
+   Cisco Systems
+   225 West Tasman Drive
+   San Jose, CA, 95134 USA
+   EMail: naiming@cisco.com
+
+   Nischal Sheth
+   Juniper Networks
+   1194 North Mathilda Avenue
+   Sunnyvale, CA 94089 USA
+   EMail: nsheth@juniper.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Przygienda, et al.          Standards Track                    [Page 13]
+
+RFC 5120                         M-ISIS                    February 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Przygienda, et al.          Standards Track                    [Page 14]
+