draft-ietf-isis-auto-conf-04.txt   draft-ietf-isis-auto-conf-05.txt 
isis B. Liu, Ed. isis B. Liu, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track B. Decraene Intended status: Standards Track L. Ginsberg
Expires: May 26, 2017 Orange Expires: November 10, 2017 Cisco Systems
B. Decraene
Orange
I. Farrer I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
M. Abrahamsson M. Abrahamsson
T-Systems T-Systems
L. Ginsberg May 9, 2017
Cisco Systems
November 22, 2016
ISIS Auto-Configuration ISIS Auto-Configuration
draft-ietf-isis-auto-conf-04 draft-ietf-isis-auto-conf-05
Abstract Abstract
This document specifies IS-IS auto-configuration mechanisms. The key This document specifies IS-IS auto-configuration mechanisms. The key
components are IS-IS System ID self-generation, duplication detection components are IS-IS System ID self-generation, duplication detection
and duplication resolution. These mechanisms provide limited IS-IS and duplication resolution. These mechanisms provide limited IS-IS
functions, and so are suitable for networks where plug-and-play functions, and so are suitable for networks where plug-and-play
configuration is expected. configuration is expected.
Requirements Language Requirements Language
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 26, 2017. This Internet-Draft will expire on November 10, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 31 skipping to change at page 2, line 31
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Specification . . . . . . . . . . . . . . . . . . . 3 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 3
3.1. IS-IS Default Configuration . . . . . . . . . . . . . . . 3 3.1. IS-IS Default Configuration . . . . . . . . . . . . . . . 3
3.2. IS-IS NET Generation . . . . . . . . . . . . . . . . . . 4 3.2. IS-IS NET Generation . . . . . . . . . . . . . . . . . . 4
3.3. Router-Fingerprint TLV . . . . . . . . . . . . . . . . . 5 3.3. Router-Fingerprint TLV . . . . . . . . . . . . . . . . . 5
3.4. Protocol Operation . . . . . . . . . . . . . . . . . . . 6 3.4. Protocol Operation . . . . . . . . . . . . . . . . . . . 6
3.4.1. Start-Up mode . . . . . . . . . . . . . . . . . . . . 6 3.4.1. Start-Up mode . . . . . . . . . . . . . . . . . . . . 6
3.4.2. Adjacency Formation . . . . . . . . . . . . . . . . . 6 3.4.2. Adjacency Formation . . . . . . . . . . . . . . . . . 7
3.4.3. IS-IS System ID Duplication Detection and Resolution 7 3.4.3. IS-IS System ID Duplication Detection . . . . . . . . 7
3.4.4. Duplicate System ID Resolution Procedures . . . . . . 7 3.4.4. Duplicate System ID Resolution Procedures . . . . . . 7
3.4.5. System ID and Router-Fingerprint Generation 3.4.5. System ID and Router-Fingerprint Generation
Considerations . . . . . . . . . . . . . . . . . . . 8 Considerations . . . . . . . . . . . . . . . . . . . 8
3.4.6. Double-Duplication of both System ID and Router- 3.4.6. Duplication of both System ID and Router-Fingerprint 9
Fingerprint . . . . . . . . . . . . . . . . . . . . . 9
3.5. Additional IS-IS TLVs Usage Guidelines . . . . . . . . . 10 3.5. Additional IS-IS TLVs Usage Guidelines . . . . . . . . . 10
3.5.1. Authentication TLV . . . . . . . . . . . . . . . . . 10 3.5.1. Authentication TLV . . . . . . . . . . . . . . . . . 11
3.5.2. Metric Used in Reachability TLVs . . . . . . . . . . 11 3.5.2. Metric Used in Reachability TLVs . . . . . . . . . . 11
3.5.3. Dynamic Host Name TLV . . . . . . . . . . . . . . . . 11 3.5.3. Dynamic Host Name TLV . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This document specifies mechanisms for IS-IS [RFC1195] This document specifies mechanisms for IS-IS [RFC1195]
[ISO_IEC10589][RFC5308] to be auto-configuring. Such mechanisms [ISO_IEC10589][RFC5308] to be auto-configuring. Such mechanisms
could reduce the management burden for configuring a network, could reduce the management burden for configuring a network,
especially where plug-and-play device configuration is required. especially where plug-and-play device configuration is required.
IS-IS auto-configuration is comprised of the following functions: IS-IS auto-configuration is comprised of the following functions:
skipping to change at page 4, line 24 skipping to change at page 4, line 24
o Extended IS Reachability and IP Reachability TLVs [RFC5305] MUST o Extended IS Reachability and IP Reachability TLVs [RFC5305] MUST
be used i.e. a router operating in auto configuration mode MUST be used i.e. a router operating in auto configuration mode MUST
NOT use any of the following TLVs: NOT use any of the following TLVs:
* IS Neighbors (2) * IS Neighbors (2)
* IP Internal Reachability (128) * IP Internal Reachability (128)
* IP External Reachability (130) * IP External Reachability (130)
TLVs listed above MUST be ignored on receipt.
3.2. IS-IS NET Generation 3.2. IS-IS NET Generation
In IS-IS, a router (known as an Intermediate System) is identified by In IS-IS, a router (known as an Intermediate System) is identified by
a Network Entity Title (NET) which is a type of Network Service a Network Entity Title (NET) which is a type of Network Service
Access Point (NSAP). The NET is the address of an instance of the Access Point (NSAP). The NET is the address of an instance of the
IS-IS protocol running on an Intermediate System (IS). IS-IS protocol running on an Intermediate System (IS).
The auto-configuration mechanism generates the IS-IS NET as the The auto-configuration mechanism generates the IS-IS NET as the
following: following:
skipping to change at page 4, line 49 skipping to change at page 4, line 51
o System ID o System ID
This field follows the area address field, and is 6 octets in This field follows the area address field, and is 6 octets in
length. There are two basic requirements for the System ID length. There are two basic requirements for the System ID
generation: generation:
- As specified by the IS-IS protocol, this field must be - As specified by the IS-IS protocol, this field must be
unique among all routers in the same area. unique among all routers in the same area.
- After its initial generation, the System ID SHOULD remain - After its initial generation, the System ID SHOULD remain
stable. It SHOULD NOT be changed due to device status stable. Changes such as interface enable/disable, interface
change (such as interface enable/disable, interface connect/ connect/disconnect, device reboot, firmware update, or
disconnect, device reboot, firmware update etc.) or configuration changes SHOULD NOT cause the system ID to
configuration change (such as changing system configuration change. System ID change as part of the System ID collision
or IS-IS configuration); but MUST support change as part of resolution process MUST be supported. Implementations
the System ID collision resolution process and SHOULD allow SHOULD allow the System ID to be cleared by a user initiated
being cleared by a user initiated system reset. system reset.
More specific considerations for System ID generation are More specific considerations for System ID generation are
described in Section 3.4.5. described in Section 3.4.5.
3.3. Router-Fingerprint TLV 3.3. Router-Fingerprint TLV
The Router-Fingerprint TLV is similar to the Router-Hardware- The Router-Fingerprint TLV is similar to the Router-Hardware-
Fingerprint TLV defined in [RFC7503]. However, the TLV defined here Fingerprint TLV defined in [RFC7503]. However, the TLV defined here
includes a flags field to support indicating that the router is in includes a flags field to support indicating that the router is in
Start-up mode and is operating in auto-configuration mode. Start-up mode and is operating in auto-configuration mode.
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|A| Reserved | | | Flags Field | |
+-+-+-+-+-+-+-+-+ Router Fingerprint (Variable) . +-+-+-+-+-+-+-+-+ Router Fingerprint (Variable) .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router Fingerprint TLV Format
The length of the Router-Fingerprint is variable but MUST be 32
octets or greater. For correct operation, the Router-Fingerprint
MUST be unique among all the routers participating in the IS-IS area.
o Type: to be assigned by IANA.
o Length: the length of the value field. Must be >= 33.
o Flags field (1 octet)
S flag: when set, indicates the router is in "start-up" mode. Type: to be assigned by IANA.
Length: the length of the value field. Must be >= 33.
Flags field (1 octet)
A flag: when set, indicates that the router is operating in 0 1 2 3 4 5 6 7
auto-configuration mode. The purpose of the flag is so that +-+-+-+-+-+-+-+-+
two routers can identify if they are both using auto- |S|A| Reserved |
configuration. If the A flag setting does not match in hellos +-+-+-+-+-+-+-+-+
then no adjacency should be formed.
Reserved: these bits MUST be set to zero and MUST be ignored by S flag: when set, indicates the router is in "start-up" mode.
the receiver. A flag: when set, indicates that the router is operating in
auto-configuration mode. The purpose of the flag is 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.
Reserved: these bits MUST be set to zero and MUST be ignored by
the receiver.
o Router Fingerprint: uniquely identifies a router, variable length. Router Fingerprint: 32 or more octets.
More specific considerations for Router-Fingerprint are described in More specific considerations for Router-Fingerprint are described in
Section 3.4.5. Section 3.4.5.
Router Fingerprint TLV MUST be included in Intermediate System to Router Fingerprint TLV MUST be included in Intermediate System to
Intermediate System Hellos (IIHs) originated by a router operating in Intermediate System Hellos (IIHs) originated by a router operating in
auto-configuration mode. auto-configuration mode. An auto-configuration mode router MUST
ignore IIHs that don't contain the Router Fingerprint TLV.
Router Fingerprint TLV MUST be included in Link State PDU (LSP) #0 Router Fingerprint TLV MUST be included in Link State PDU (LSP) #0
originated by a router operating in auto-configuration mode. The originated by a router operating in auto-configuration mode. If an
router fingerprint TLV MUST NOT be included in an LSP with a non-zero LSP #0 which does NOT contain a Router Fingerprint TLV is received by
number. a Router operating in auto-configuration mode the LSP is flooded as
normal, but the entire LSP set originated by the sending router MUST
be ignored when running the Decision process.
The router fingerprint TLV MUST NOT be included in an LSP with a non-
zero number and when received MUST be ignored.
3.4. Protocol Operation 3.4. Protocol Operation
This section describes the operation of a router supporting auto- This section describes the operation of a router supporting auto-
configuration mode. configuration mode.
3.4.1. Start-Up mode 3.4.1. Start-Up mode
When a router starts operation in auto-configuration mode, both the S When a router starts operation in auto-configuration mode, both the S
and A bits MUST be set in the Router Fingerprint TLV included in both and A bits MUST be set in the Router Fingerprint TLV included in both
skipping to change at page 7, line 13 skipping to change at page 7, line 19
configuration mode. The presence of the Router Fingerprint TLV with configuration mode. The presence of the Router Fingerprint TLV with
the A bit set indicates the router is operating in auto-configuration the A bit set indicates the router is operating in auto-configuration
mode. mode.
NOTE: The use of the special area address of all 0's makes it NOTE: The use of the special area address of all 0's makes it
unlikely that a router which is not operating in auto-configuration unlikely that a router which is not operating in auto-configuration
mode will be in the same area as a router operating in auto- mode will be in the same area as a router operating in auto-
configuration mode. However, the check for the Router Fingerprint configuration mode. However, the check for the Router Fingerprint
TLV with A bit set provides additional protection. TLV with A bit set provides additional protection.
3.4.3. IS-IS System ID Duplication Detection and Resolution 3.4.3. IS-IS System ID Duplication Detection
The System ID of each node MUST be unique. As described in The System ID of each node MUST be unique. As described in
Section 3.4.5, the System ID is generated based on entropies (e.g. Section 3.4.5, the System ID is generated based on entropies (e.g.
MAC address) which are generally expected to be unique. However, MAC address) which are generally expected to be unique. However,
since there may be limitations to the available entropies, there is since there may be limitations to the available entropies, there is
still the possibility of System ID duplication. This section defines still the possibility of System ID duplication. This section defines
how IS-IS detects and resolves System ID duplication. Duplicate how IS-IS detects and resolves System ID duplication. Duplicate
System ID may occur between neighbors or between routers in the same System ID may occur between neighbors or between routers in the same
area which are not neighbors. area which are not neighbors.
skipping to change at page 8, line 27 skipping to change at page 8, line 34
If fingerprints are identical in both content and length and the If fingerprints are identical in both content and length and the
duplication is detected in LSP #0 then the procedures defined in duplication is detected in LSP #0 then the procedures defined in
Section 3.4.6 MUST be followed. Section 3.4.6 MUST be followed.
3.4.5. System ID and Router-Fingerprint Generation Considerations 3.4.5. System ID and Router-Fingerprint Generation Considerations
As specified in this document, there are two distinguishing items As specified in this document, there are two distinguishing items
that need to be self-generated: the System ID and Router-Fingerprint. that need to be self-generated: the System ID and Router-Fingerprint.
In a network device, normally there are some resources which can In a network device, normally there are some resources which can
provide an extremely high probability of uniqueness thus could be provide an extremely high probability of uniqueness (some examples
used as seeds to derive distinguisher (e.g. hashing or generating listed below). These resources can be used as seeds to derive
pseudo-random numbers), such as: identifiers.
o MAC address(es) o MAC address(es)
o Configured IP address(es) o Configured IP address(es)
o Hardware IDs (e.g. CPU ID) o Hardware IDs (e.g. CPU ID)
o Device serial number(s) o Device serial number(s)
o System clock at a certain specific time o System clock at a certain specific time
skipping to change at page 9, line 20 skipping to change at page 9, line 25
document suggests using the MAC address as System ID and generating a document suggests using the MAC address as System ID and generating a
pseudo-random number based on another seed (such as the memory pseudo-random number based on another seed (such as the memory
address of a certain variable in the program) as the Router- address of a certain variable in the program) as the Router-
Fingerprint. The pseudo-random number might not have a very high Fingerprint. The pseudo-random number might not have a very high
probability of uniqueness in this solution, but should be sufficient probability of uniqueness in this solution, but should be sufficient
in home networks scenarios. in home networks scenarios.
The considerations surrounding System ID stability described in The considerations surrounding System ID stability described in
section Section 3.2 also need to be applied. section Section 3.2 also need to be applied.
3.4.6. Double-Duplication of both System ID and Router-Fingerprint 3.4.6. Duplication of both System ID and Router-Fingerprint
As described above, the resources for generating System ID/ As described above, the resources for generating System ID/
Fingerprint might be very constrained during the initial stages. Fingerprint might be very constrained during the initial stages.
Hence, the double-duplication of both System ID and Router- Hence, the duplication of both System ID and Router-Fingerprint needs
Fingerprint needs to be considered. In such a case it is possible to be considered. In such a case it is possible that a router will
that a router will receive an LSP with System ID and Router- receive an LSP with System ID and Router-Fingerprint identical to the
Fingerprint identical to the local values but the LSP is NOT local values but the LSP is NOT identical to the locally generated
identical to the locally generated copy i.e. sequence number is newer copy i.e. sequence number is newer or sequence number is the same but
or sequence number is the same but the LSP has a valid checksum which the LSP has a valid checksum which does not match. The term DD-LSP
does not match. The term DD-LSP is used to describe such an LSP. is used to describe such an LSP.
In a benign case, this will occur if a router restarts and it In a benign case, this will occur if a router restarts and it
receives copies of its own LSPs from its previous incarnation. This receives copies of its own LSPs from its previous incarnation. This
benign case needs to be distinguished from the pathological case benign case needs to be distinguished from the pathological case
where there are two different routers with the same System ID and the where there are two different routers with the same System ID and the
same Router-Fingerprint. same Router-Fingerprint.
In the benign case, the restarting router will generate a new version In the benign case, the restarting router will generate a new version
of its own LSP with higher sequence number and flood the new LSP of its own LSP with higher sequence number and flood the new LSP
version. This will cause other routers in the network to update version. This will cause other routers in the network to update
skipping to change at page 10, line 35 skipping to change at page 10, line 41
DD-count is incremented DD-count is incremented
If DD-count is >= DD-max: If DD-count is >= DD-max:
Local system MUST generate a new System ID Local system MUST generate a new System ID
and Router-Fingerprint and restart the protocol and Router-Fingerprint and restart the protocol
DD-state is (re)initialized to FALSE and DD-state is (re)initialized to FALSE and
DD-timer cancelled. DD-timer cancelled.
If DD-timer expires: If DD-timer expires:
DD-state is set to FALSE. DD-state is set to FALSE.
Note that to minimze the likelihood of double-duplication reoccuring, Note that to minimze the likelihood of duplication of both System ID
routers SHOULD have more entropies available. One simple way to and Router-fingerprint reoccuring, routers SHOULD have more entropies
achieve this is to add the LSP sequence number of the next LSP it available. One simple way to achieve this is to add the LSP sequence
will send to the Router-Fingerprint. number of the next LSP it will send to the Router-Fingerprint.
3.5. Additional IS-IS TLVs Usage Guidelines 3.5. Additional IS-IS TLVs Usage Guidelines
This section describes the behavior of selected TLVs when used by a This section describes the behavior of selected TLVs when used by a
router supporting IS-IS auto-configuration. router supporting IS-IS auto-configuration.
3.5.1. Authentication TLV 3.5.1. Authentication TLV
It is RECOMMENDED that IS-IS routers supporting this specification It is RECOMMENDED that IS-IS routers supporting this specification
offer an option to explicitly configure a single password for HMAC- offer an option to explicitly configure a single password for HMAC-
skipping to change at page 11, line 23 skipping to change at page 11, line 29
IS-IS auto-configuration routers MAY advertise their Dynamic Host IS-IS auto-configuration routers MAY advertise their Dynamic Host
Name TLV (TLV 137, [RFC5301]). The host name could be provisioned by Name TLV (TLV 137, [RFC5301]). The host name could be provisioned by
an IT system, or just use the name of vendor, device type or serial an IT system, or just use the name of vendor, device type or serial
number, etc. number, etc.
To guarantee the uniqueness of the host name, the System ID SHOULD be To guarantee the uniqueness of the host name, the System ID SHOULD be
appended as a suffix in the names. appended as a suffix in the names.
4. Security Considerations 4. Security Considerations
In general, the use of authentication is incompatible with auto- In the absence of cryptographic authentication it is possible for an
attacker to inject a PDU falsely indicating there is a duplicate
system-id. This may trigger automatic restart of the protocol using
the duplicate-id resolution procedures defined in this document.
Note that the use of authentication is incompatible with auto-
configuration as it requires some manual configuration. configuration as it requires some manual configuration.
For wired deployment, the wired connection itself could be considered For wired deployment, the wired connection itself could be considered
as an implicit authentication in that unwanted routers are usually as an implicit authentication in that unwanted routers are usually
not able to connect (i.e. there is some kind of physical security in not able to connect (i.e. there is some kind of physical security in
place preventing the connection of rogue devices); for wireless place preventing the connection of rogue devices); for wireless
deployment, the authentication could be achieved at the lower deployment, the authentication could be achieved at the lower
wireless link layer. wireless link layer.
5. IANA Considerations 5. IANA Considerations
skipping to change at page 12, line 9 skipping to change at page 12, line 17
This document was heavily inspired by [RFC7503]. This document was heavily inspired by [RFC7503].
Martin Winter, Christian Franke and David Lamparter gave essential Martin Winter, Christian Franke and David Lamparter gave essential
feedback to improve the technical design based on their feedback to improve the technical design based on their
implementation experience. implementation experience.
Many useful comments were made by Acee Lindem, Karsten Thomann, Many useful comments were made by Acee Lindem, Karsten Thomann,
Hannes Gredler, Peter Lothberg, Uma Chundury, Qin Wu, Sheng Jiang and Hannes Gredler, Peter Lothberg, Uma Chundury, Qin Wu, Sheng Jiang and
Nan Wu, etc. Nan Wu, etc.
This document was produced using the xml2rfc tool [RFC7749]. This document was produced using the xml2rfc tool [RFC7991].
(initially prepared using 2-Word-v2.0.template.dot. ) (initially prepared using 2-Word-v2.0.template.dot. )
7. References 7. References
7.1. Normative References 7.1. Normative References
[ISO_IEC10589] [ISO_IEC10589]
"Intermediate system to Intermediate system intra-domain "Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in routeing information exchange protocol for use in
conjunction with the protocol for providing the conjunction with the protocol for providing the
skipping to change at page 13, line 5 skipping to change at page 13, line 15
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008, DOI 10.17487/RFC5308, October 2008,
<http://www.rfc-editor.org/info/rfc5308>. <http://www.rfc-editor.org/info/rfc5308>.
7.2. Informative References 7.2. Informative References
[RFC7503] Lindem, A. and J. Arkko, "OSPFv3 Autoconfiguration", [RFC7503] Lindem, A. and J. Arkko, "OSPFv3 Autoconfiguration",
RFC 7503, DOI 10.17487/RFC7503, April 2015, RFC 7503, DOI 10.17487/RFC7503, April 2015,
<http://www.rfc-editor.org/info/rfc7503>. <http://www.rfc-editor.org/info/rfc7503>.
[RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary",
RFC 7749, DOI 10.17487/RFC7749, February 2016, RFC 7991, DOI 10.17487/RFC7991, December 2016,
<http://www.rfc-editor.org/info/rfc7749>. <http://www.rfc-editor.org/info/rfc7991>.
Authors' Addresses Authors' Addresses
Bing Liu (editor) Bing Liu (editor)
Huawei Technologies Huawei Technologies
Q10, Huawei Campus, No.156 Beiqing Road Q10, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095 Hai-Dian District, Beijing, 100095
P.R. China P.R. China
Email: leo.liubing@huawei.com Email: leo.liubing@huawei.com
Les Ginsberg
Cisco Systems
821 Alder Drive
Milpitas CA 95035
USA
Email: ginsberg@cisco.com
Bruno Decraene Bruno Decraene
Orange Orange
France France
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Ian Farrer Ian Farrer
Deutsche Telekom AG Deutsche Telekom AG
Bonn Bonn
Germany Germany
skipping to change at page 13, line 31 skipping to change at page 14, line 4
France France
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Ian Farrer Ian Farrer
Deutsche Telekom AG Deutsche Telekom AG
Bonn Bonn
Germany Germany
Email: ian.farrer@telekom.de Email: ian.farrer@telekom.de
Mikael Abrahamsson Mikael Abrahamsson
T-Systems T-Systems
Stockholm Stockholm
Sweden Sweden
Email: mikael.abrahamsson@t-systems.se Email: mikael.abrahamsson@t-systems.se
Les Ginsberg
Cisco Systems
821 Alder Drive
Milpitas CA 95035
USA
Email: ginsberg@cisco.com
 End of changes. 30 change blocks. 
79 lines changed or deleted 93 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/