isis                                                         B. Liu, Ed.
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                             B. Decraene
Expires: December 3, 2016 January 21, 2017                                         Orange
                                                               I. Farrer
                                                     Deutsche Telekom AG
                                                          M. Abrahamsson
                                                               T-Systems
                                                             L. Ginsberg
                                                           Cisco Systems
                                                            June 1,
                                                           July 20, 2016

                        ISIS Auto-Configuration
                      draft-ietf-isis-auto-conf-01
                      draft-ietf-isis-auto-conf-02

Abstract

   This document specifies an IS-IS auto-configuration technology. mechanisms.  The key mechanisms of this technology
   components are IS-IS System ID self-
   generation, self-generation, duplication detection
   and duplication resolution.  This
   technology fits  These mechanisms provide limited IS-IS
   functions, thus they are fit for the environment networks where plug-and-play
   configuration is expected.

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 December 3, 2016. January 21, 2017.

Copyright Notice

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Specification  . . . . . . . . . . . . . . . . . . .   3
     3.1.  IS-IS Default Configuration . . . . . . . . . . . . . . .   3
     3.2.  IS-IS NET Generation  . . . . . . . . . . . . . . . . . .   3
     3.3.  IS-IS System ID Duplication Detection and Resolution  . .   4
       3.3.1.  Router-Fingerprint TLV  . . . . . . . . . . . . . . .   4
       3.3.2.  Duplicate System ID Duplication Detection and Resolution
               Procedures  . . . . . . . . . . . . . . . . . . . . .   5
       3.3.3.  System ID and Router-Fingerprint Generation
               Considerations  . . . . . . . . . . . . . . . . . . .   9  10
       3.3.4.  Double-Duplication of both System ID and Router-
               Fingerprint . . . . . . . . . . . . . . . . . . . . .  10  11
     3.4.  IS-IS TLVs Usage  . . . . . . . . . . . . . . . . . . . .  11
       3.4.1.  Authentication TLV  . . . . . . . . . . . . . . . . .  11
       3.4.2.  Wide Metric TLV . . . . . . . . . . . . . . . . . . .  11
       3.4.3.  Dynamic Host Name TLV . . . . . . . . . . . . . . . .  11  12
     3.5.  Routing Behavior Considerations . . . . . . . . . . . . .  12
       3.5.1.  Adjacency Formation . . . . . . . . . . . . . . . . .  12
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12  13
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  13  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   This document describes specifies mechanisms for IS-IS [RFC1195]
   [ISO_IEC10589][RFC5308] to be auto-configuring.  Such mechanisms
   could reduce the management burden to configure for configuring a network.  Home
   networks and small or medium size enterprise networks network,
   especially where plug-and-
   play plug-and-play device configuration is expected can benefit from these mechanisms.

   This document also defines mechanisms which prevent unintentional
   interoperation of autoconfigured routers with non-autoconfigured
   routers.  See Section 3.3.1 . required.

   IS-IS auto-configuration contains is comprised of the following aspects: functions:

   1.  IS-IS default configurations configurations.

   2.  IS-IS System ID self-generation self-generation.

   3.  System ID duplication detection and resolution resolution.

   4.  ISIS TLVs TLV utilization such as Authentication (Authentication TLV, Wide Metric TLV
       etc. TLV, and
       Dynamic Host Name TLV).

   This document also defines mechanisms to prevent the unintentional
   interoperation of auto-configured routers with non-autoconfigured
   routers.  See Section 3.3.1.

2.  Scope

   The auto-configuring mechanisms support both IPv4 and IPv6
   deployments.

   This

   These auto-configuration mechanism aims at mechanisms aim to cover simple case. deployment
   cases.  The following
   advanced important features are out of scope: not supported:

   o  Multiple IS-IS instances instances.

   o  Multi-area and level-2 routing routing.

   o  Interworking with other routing protocols protocols.

3.  Protocol Specification

3.1.  IS-IS Default Configuration

   o  IS-IS interfaces MUST be auto-configured to an interface type
      corresponding to their layer-2 capability.  For example, Ethernet
      interfaces will be auto-configured as broadcast networks and
      Point-to-Point Protocol (PPP) interfaces will be auto-configured
      as Point-to-Point interfaces.

   o  IS-IS auto-configuration instance MUST be configured with as level-1,
      so that the interfaces operate at as level-1 only.

   o  IS-IS auto-configuration SHOULD allow P2P mode on Ethernet
      interfaces.

3.2.  IS-IS NET Generation

   In IS-IS, a router (known as an Intermediate System) is identified by
   an
   a NET which is the address of a Network Service Access Point (NSAP)
   and represented with an IS-IS specific address format.  The NSAP is a
   logical entity which represents an instance of the IS-IS protocol
   running on an Intermediate System.

   The autoconfiguration auto-configuration mechanism generates the IS-IS NET as the
   following:

   o  Area address

         This field is 1 to 13 octets in length.

         In IS-IS auto-
         configuration, auto-configuration, this field MUST be 13 octets of long
         and set to all 0.

   o  System ID

         This field follows the area address field, and is 6 octets in
         length.  There are two basic requirements for the System ID
         generation:

         -  As specified in by the IS-IS protocol, this field must be
            unique among all routers in the same area.

         -  In order to make the routing system stable,  After its initial generation, the System ID SHOULD remain
            stable to improve the same after it is firstly generated. stability of the routing system.  It
            SHOULD not be changed due to device status change (such as
            interface enable/disable, interface plug in/off, connect/disconnect,
            device reboot, firmware update etc.) or configuration change
            (such as changing system configurations configuration or IS-IS configurations
            etc.);
            configuration); but it MUST allow be changed by support change as part of the
            System ID collision resolution process and SHOULD allow be
            being cleared by a user enforced initiated system reset.

         More specific considerations for System ID generation are
         described in Section 3.3.3 .

3.3.  IS-IS System ID Duplication Detection and Resolution

   The System ID of each node MUST be unique.  As described in
   Section 3.3.3, the System ID is generated based on entropies such as (e.g.
   MAC address address) which are supposed generally expected to be unique, but in theory unique.  However,
   since there may be limitations to the available entropies, there is
   still the possibility of System ID duplication.  This section defines
   how IS-IS detects and resolves System ID duplication.

3.3.1.  Router-Fingerprint TLV

   The Router-Fingerprint TLV basically essentially re-uses the design of Router-
   Hardware-Fingerprint TLV defined in [RFC7503].  However, there is one
   difference in that one a flag is added to indicate that the node is in "start-
   up mode"
   "start-up mode", which is defined in Section 3.3.2 . 3.3.2.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|A| Reserved  |                                               |
      +-+-+-+-+-+-+-+-+        Router Fingerprint (Variable)          .
      .                                                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Router Fingerprint TLV Format

   The length of the Router-Fingerprint is variable but must MUST be 32
   octets or greater; and greater.  For correct operation, the content is also supposed to Router-Fingerprint
   MUST be unique among all the routers. routers participating in the IS-IS area.

   o  Type: to be assigned by IANA.

   o  Length: the length of the value field.  As the Router Fingerprint
      length is variable, the field length is also variable.

   o  S flag: when set, indicates the router is in "start-up" mode as described
      below. mode.

   o  A flag: when set, indicates that the router is operating in autoconfiguration auto-
      configuration mode.  This  The purpose of the flag is in case the TLV gets used outside of
      autoconfiguration. so that two
      routers can identify if they are both using auto-configuration.
      If the A flag setting does not match in hellos then no adjacency
      should be formed.

   o  Reserved: these bits MUST be set to zero and MUST be ignored when
      received. by
      the receiver.

   o  Router Fingerprint: uniquely identifies a router, variable length.

   More specific considerations for Router-Fingerprint is are described in
   Section 3.3.3 .

3.3.2.  Duplicate System ID Duplication Detection and Resolution Procedures

   This section describes the duplicate System ID duplication detection and
   resolution process between two neighbors and two non-neighbors
   respectively.  This is because due to difference in the the routing messages
   between neighbors and non-
   neighbors are a bit different. non-neighbors.

3.3.2.1.  Start-up Mode

   While in startup-mode, Start-up Mode, an auto-configuration router forms
   adjacencies but generates only LSP #0 which contains only the Router-Fingerprint Router-
   Fingerprint TLV.  A router remains in startup-mode until it has
   successfully completed LSPDB synchronization with all neighbors or
   until 1 minute has elapsed - whichever is longer.  If a duplicate system-ID
   System ID is detected while in startup-mode Start-up Mode stage, the Start-up Mode
   router MUST clear all adjacencies, select a new system-id System ID (subject to
   rules defined in Section 3.3.2.2 ), and reenter Startup-mode. re-enter Start-up Mode.

   The start-up mode purpose of the Start-up Mode is to minimize the occurrence of
   System ID changes for a router once it has become fully operational.
   It has minimal impact on a running network because the startup Start-up Mode
   node is not yet being used for forwarding traffic.  Once duplicate
   System ID has IDs have been resolved the router begins normal operation.  If
   two routers are both in startup mode (or both NOT in startup mode) Start-up Mode and duplicate system-id System ID is detected then
   detected, they determine which one changes its system-id based
   on fingerprint. follow the duplication resolution as specified in
   Section 3.3.2.2 and Section 3.3.2.3.

   When an IS-IS auto-configuration router boots up, it MUST operate in
   start-up mode
   Startup-Mode until duplicate system-id System ID detection has successfully
   completed.

3.3.2.2.  Duplication Between Neighbors

   In the case of duplicate System ID duplication occurs IDs being detected between neighbors,
   an IS-IS auto-configuration router MUST include the Router-Fingerprint Router-
   Fingerprint TLV in the Hello messages, so that the duplication could can be
   detected before an adjacency forming.

   Procedures of the nodes in is formed.

   Start-up Mode: Mode procedures:

   1.  Boot up, advertise up and advertisement of the Router-Fingerprint TLV in Hello message
       messages

          The router sends Hellos Hello messages which include the Router-Fingerprint Router-
          Fingerprint TLV.  Adjacencies are formed as normal but MUST
          NOT be advertised in LSPs until the router exits startup-mode. Start-up
          Mode.

   2.  Receive  Receiving Hello message(s), and verifies System ID duplication detection

          Received hellos Hello messages are inspected for a possible duplicate
          System ID.  If duplication a duplicate is detected, the router MUST check
          the S flag of the Router-Fingerprint TLV.

          +  If the S flag is NOT set (which means the Hello message was
             NOT generated by a neighbor also in Start-up mode), Mode neighbor), then the router
             MUST re-generate the System ID and reenter Startup-
             mode. re-enter Start-up Mode.

          +  If the S flag is set (which means (meaning the neighbor is also in
             Startup-mode),
             Start-up Mode),

             -  the  The router which has a numerically smaller Router-
                Fingerprint MUST re-generate the its System ID and reenter
                Startup-mode. re-enter
                Start-up Mode.  Fingerprint comparison is MUST be performed
                octet by octet starts from the left until octets are different.  Then a difference
                is found.  Then, the numeric smaller fingerprint is the
                one with the smaller octet (unsigned
                integer). lowest value.  If the fingerprints have
                different lengths, then the shorter length fingerprint
                MUST be padding with zero at the left side for
                comparison.

             -  If the Router Fingerprints are identical, both routers
                MUST re-generate the System ID and the Router
                Fingerprint, and reenter Startup-mode. re-enter Start-up Mode.

   3.  Run in normal  Normal operation

          After the System ID duplication procedure is done, successfully
          completed, the router begins to run in normal operation.  The router
          MUST re-
          advertise re-advertise the Router-Fingerprint TLV with the S flag off.

   Procedures of the nodes NOT in
          disabled.

   Non Start-up Mode: Mode procedures:

   1.  Compare the System ID in received Hello messages

          When receiving a Hello message, the router MUST check the
          System ID of the Hello.  If the System ID is the same as its
          own, it indicates a that System ID duplication occurs. has occurred.

          If there is no Router-Fingerprint TLV in the received Hello
          message, it
          means a non-autoconfiguration router by accident connected to this is interpreted as the auto-configuration domain attached router either
          does not support auto-configuration, or other unexpected bad
          behaviors. does not have it
          enabled.  In this case, the auto-configuration router MUST NOT
          form adjacency with the non-autoconfiguration router.

   2.  Duplication resolution

          When duplicate System ID duplication occurs, IDs are detected, the non-startup mode
          router MUST check the S flag of the duplicated Router-Fingerprint Router-
          Fingerprint TLV:

          +  If the S flag is NOT set, then the router with the
             numerically smaller or equal Router-Fingerprint MUST
             generate a new System ID.  Note that, the router MUST
             compare the two Router-Fingerprint in terms of two numeric
             numbers. octet by octet until
             difference is found.

          +  If the S flag is set, then router does nothing, because it
             MUST be the node which no further action is necessary in start-up mode re-generates the
             System ID.
             Duplication resolution process.

   3.  Re-join  Re-joining the network with the a new System ID (if required)

          The router with the smaller Router-Fingerprint advertise that has changed its System ID advertises new
          Hellos based on containing the newly generated NET System ID to re-join the
          IS-IS auto-configuration network.  The conflicting SysID-
          duplicated router with the highest
          Router-Fingerprint also MUST increase the sequence number and
          re-advertise its own LSP (after
          increasing the sequence number). Hellos.

          The Duplication Detection process SHOULD be repeated with the
          newly generated System ID SHOULD take a duplication
          detection as well. System.

3.3.2.3.  Duplication Between Non-neighbors

   System ID duplication may also occur between non-neighbors, so therefore
   an IS-
   IS IS-IS auto-configuration router MUST also include the Router-Fingerprint Router-
   Fingerprint TLV in the its LSP messages.  Specific  The specific procedures are as the following.

   Procedures of the nodes in
   follows:

   Start-up Mode: Mode procedures:

   1.  Boot up, form adjacency formation

   2.  Acquire  Acquiring LSPDB and verifies checking System ID duplication

          The router generates only an LSP #0 which contains only the
          Fingerprint TLV; and that Fingerprint is only sent in LSP #0.
          A router remains in startup-mode Start-up Mode until it has successfully
          completed LSPDB synchronization with all neighbors or until 1
          minute has elapsed - whichever is longer.  If duplicate
          system-ID is detected, the router MUST check the S flag of the
          Router-Fingerprint TLV of the LSP that contains the duplicated
          System ID.

          +  If the S flag is not set, it means the LSP was not generated at the by
             a Non Start-up Mode, Mode node, then the router itself MUST clear
             all adjacencies, re-generate a new system-id and reenter Startup-mode.
             Start-up Mode.

          +  If the S flag is set, then the router which has a
             numerically smaller Router-Fingerprint MUST generate a new
             System ID and reenter Startup-mode. Start-up Mode.

   3.  Run  Running in normal operation

          After the System ID duplication procedure is done, the router
          begins to run in normal operation.  The router MUST re-
          advertise the Router-Fingerprint TLV with the S flag off.

   Procedures of the nodes not in

   Non Start-up Mode: Mode procedures:

   1.  Compare  Checking the received Router-Fingerprint TLVs

          When receiving a LSP containing its own System ID, the router
          MUST check the Router-Fingerprint TLV.  If the Router-
          Fingerprint TLV is different from its own, it indicates a
          System ID duplication occurs.

   2.  Duplication resolution

          When System ID duplication occurs, the non-startup mode router
          MUST check the S flag of the duplicated Router-Fingerprint
          TLV:

          +  If the S flag is NOT set, then the router with the
             numerically smaller Router-Fingerprint MUST generate a new
             System ID.  Note that, the router MUST compare the two
             Router-Fingerprint in terms of two numeric numbers. octet by octet until difference is
             found.

          +  If the S flag is set, then router does nothing, because
             according to the start-up mode procedure, the start-up node
             MUST re-generate the System ID. nothing.

   3.  Re-join  Re-joining the network with the new System ID

          The router changing its system System ID advertise advertises new LSPs based on
          the newly generated System ID to re-join the IS-IS auto-
          configuration network.  The other SysID-duplicated router with the highest Router-
          Fingerprint also
          MUST re-advertise its own LSP (after increasing the sequence
          number).

          The newly generated System ID SHOULD take a perform duplication
          detection as well.

3.3.3.  System ID and Router-Fingerprint Generation Considerations

   As specified in this document, there are two distinguisher distinguishing items
   that need to be
   self-generated, which is self-generated: the System ID and Router-Fingerprint.
   In a network device, normally there are some resources which can
   provide an extremely high probability of uniqueness thus could be
   used as seeds to derive distinguisher (e.g.  hashing or generating
   pseudo-random numbers), such as:

   o  MAC address(es)

   o  Configured IP address(es)

   o  Hardware IDs (e.g.  CPU ID)

   o  Device serial number(s)

   o  System clock at a certain specific time

   o  Arbitrary received packet packet(s) on an interface(s)

   This document recommends to the use of an IEEE 802 48-bit MAC address
   associated with the router as the initial System ID.  This document
   does not specify a specific method to re-generate the System ID when
   duplication happens.

   This document also does not specify a specific method to generate the
   Router-Fingerprint.  However, the generation of System ID and Router-
   Fingerprint MUST be based on different seeds so that the two
   distinguisher would not collide.

   There is an important concern that the seeds listed above (except MAC
   address) might not be available in some small devices such as home
   routers.  This is because of the hardware/software limitation limitations and the
   lack of sufficient communication packets at the initial stage in the home
   routers when doing ISIS-autoconfiguration. ISIS auto-configuration.  In this case, this
   document suggests to use using the MAC address as System ID and generate generating a
   pseudo-random number based on another seed (such as the memory
   address of a certain variable in the program) as Router-Fingerprint. the Router-
   Fingerprint.  The pseudo-random number might not have a very high quality
   probability of uniqueness in this solution, but should be sufficient
   in home networks scenarios.

   Note that, the Router-Fingerprint SHOULD

   The considerations surrounding System ID stability described in
   section Section 3.2 also remain the same after
   it is firstly generated.  It SHOULD not be changed due need to device
   status change (such as interface enable/disable, interface plug in/
   off, device reboot, firmware update etc.) or configuration change
   (such as changing system configurations or IS-IS configurations
   etc.); but it MUST allow be changed by double-duplication resolution
   Section 3.3.4 and SHOULD allow be cleared by user enforced system
   reset. applied.

3.3.4.  Double-Duplication of both System ID and Router-Fingerprint

   As described above, the resources for generating the distinguisher
   might be very constrained at during the initial stage. stages.  Hence, the double-
   duplication
   double-duplication of both System ID and Router-Fingerprint needs to
   be considered.

   ISIS-autoconfiguring routers SHOULD support detecting System ID
   duplication by LSP war.  LSP war is a phenomenon that if whereby a router
   receives a LSP originated with its System ID, but it doesn't find it
   in the database, or it does not match the one the router has (e.g.
   It
   it advertises IP prefixes that the router doesn't does not own, or IS
   neighbors that the router doesn't does not see), then per the ISIS
   specification, the router must re-originate its LSP with an increased
   sequence number.  If double-duplication happens, the duplicated two
   routers will both continuously have repeat the above behavior.  After
   multiples iterations, the program should be able to deduce that double-
   duplication happens.

   At the point when
   double-duplication happens, is occurring.

   When this condition is detected, routers should have much more
   entropies available.  Thus, the router is able to extend or re-
   generate its Router-Fingerprint (one simple way is just adding the
   LSP sequence number of the next LSP it will send to the Router-
   Fingerprint).  (Optimized solution TBD.)

3.4.  IS-IS TLVs Usage

   This section describes several the TLVs that are utilized by necessary for IS-IS auto-
   configuration.

3.4.1.  Authentication TLV

   It is RECOMMENDED that IS-IS routers supporting this specification
   minimally offer an option to explicitly configure a single password
   for HMAC-MD5 authentication, which is Type 54 authentication mode of
   [RFC5304].  In this case, the Authentication TLV (TLV 10) is needed.

3.4.2.  Wide Metric TLV

   IS-IS auto-configuration routers MUST support TLVs using wide metric metrics
   as defined in [RFC5305]).

   It is recommended RECOMMENDED that IS-IS auto-configuration routers use a high
   metric value (e.g. 1000000) as default in order to typically prefer
   the
   manually configured adjacencies rather than the auto-configuring
   ones. over auto-configuringed.

3.4.3.  Dynamic Host Name TLV

   IS-IS auto-configuration routers MAY advertise their Dynamic Host
   Names TLV (TLV 137, [RFC5301]).  The host names could be provisioned
   by an IT system, or just use the name of vendor, device type or
   serial number number, etc.  Note that,

   To guarantee the hostname needs to be unique so
   that it could uniqueness of the host names, the System ID SHOULD
   be useful. appended as a suffix in the names.

3.5.  Routing Behavior Considerations

3.5.1.  Adjacency Formation

   Since ISIS IS-IS does not require strict hold timers timer matching to form
   adjacency, this document does not specify specific hold timers.
   However, the timers should be within a reasonable range based on
   current practise in the industry.  (For example, the defaults defined
   in [ISO_IEC10589] .)

4.  Security Considerations

   In general, auto-configuration is mutually incompatible with
   authentication.  This is a common problem that IS-IS auto-
   configuration can not avoid.

   For wired deployment, the wired line connection itself could be considered
   as an implicit authentication in that normally unwanted routers are usually
   not able to connect to (i.e. there is some kind of physical security in
   place preventing the wire line; connection of rogue devices); for wireless
   deployment, the authentication could be achieve achieved at the lower
   wireless link layer.

   Malicious

   A malicious router could modify the System ID field to keep causing
   System ID duplication detection and resolution thus cause the routing
   system to oscillate.  However, this is not a new attack vector as
   without this document the consequences would be higher as other
   routers would not try have a mechanism to adapt. try and resolve this case.

5.  IANA Considerations

   The Router-Fingerprint

   IANA is kindly requested to assign a new TLV type code needs an assignment by IANA. for the Router-
   Fingerprint from the IS-IS TLV Codepoint registry.

6.  Acknowledgements

   This document was heavily inspired by [RFC7503].

   Martin Winter, Christian Franke and David Lamparter gave essential
   feedback to improve the technical design based on their
   implementation experience.

   Many useful comments were made by Acee Lindem, Karsten Thomannby, Thomann,
   Hannes Gredler, Peter Lothberg, Uma Chundury, Qin Wu, Sheng Jiang and
   Nan Wu, etc.

   This document was produced using the xml2rfc tool [RFC2629].
   (initially prepared using 2-Word-v2.0.template.dot.  )

7.  References

7.1.  Normative References

   [ISO_IEC10589]
              ""Intermediate System to Intermediate System intra-domain
              routeing information exchange protocol for use in
              conjunction with the protocol for providing the
              connectionless-mode network service (ISO 8473)", ISO/IEC
              10589", November 2002.

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

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              DOI 10.17487/RFC2629, June 1999,
              <http://www.rfc-editor.org/info/rfc2629>.

   [RFC5301]  McPherson, D. and N. Shen, "Dynamic Hostname Exchange
              Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301,
              October 2008, <http://www.rfc-editor.org/info/rfc5301>.

   [RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
              Authentication", RFC 5304, DOI 10.17487/RFC5304, October
              2008, <http://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, <http://www.rfc-editor.org/info/rfc5305>.

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

   [RFC6232]  Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge
              Originator Identification TLV for IS-IS", RFC 6232,
              DOI 10.17487/RFC6232, May 2011,
              <http://www.rfc-editor.org/info/rfc6232>.

7.2.  Informative References

   [I-D.ietf-homenet-hncp]
              Stenberg, M., Barth, S., and P. Pfister, "Home Networking
              Control Protocol", draft-ietf-homenet-hncp-10 (work in
              progress), November 2015.

   [RFC7503]  Lindem, A. and J. Arkko, "OSPFv3 Autoconfiguration",
              RFC 7503, DOI 10.17487/RFC7503, April 2015,
              <http://www.rfc-editor.org/info/rfc7503>.

Authors' Addresses

   Bing Liu
   Huawei Technologies
   Q14,
   Q10, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: leo.liubing@huawei.com

   Bruno Decraene
   Orange
   38 rue du General Leclerc
   Issy-les-Moulineaux FR
   FR
   France

   Email: bruno.decraene@orange.com

   Ian Farrer
   Deutsche Telekom AG
   Bonn
   Germany

   Email: ian.farrer@telekom.de

   Mikael Abrahamsson
   T-Systems
   Stockholm
   Sweden

   Email: mikael.abrahamsson@t-systems.se
   Les Ginsberg
   Cisco Systems
   510 McCarthy Blvd.
   Milpitas  CA 95035
   USA

   Email: ginsberg@cisco.com