wdiff rfc8196.original rfc8196.txt

isis
Internet Engineering Task Force (IETF) B. Liu, Ed.
Internet-Draft
Request for Comments: 8196 Huawei Technologies
Intended status:
Category: Standards Track L. Ginsberg
Expires: November 10, 2017
ISSN: 2070-1721 Cisco Systems
B. Decraene
Orange
I. Farrer
Deutsche Telekom AG
M. Abrahamsson
T-Systems
May 9,
June 2017

ISIS Auto-Configuration
draft-ietf-isis-auto-conf-05

IS-IS Autoconfiguration

Abstract

This document specifies IS-IS auto-configuration autoconfiguration mechanisms. The key
components are IS-IS System ID self-generation, duplication detection
detection, and duplication resolution. These mechanisms provide
limited IS-IS
functions, functions and so are therefore suitable for networks where
plug-and-play configuration is expected.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119] when they appear in ALL CAPS. When these words are not in
ALL CAPS (such as "should" or "Should"), they have their usual
English meanings, and are not to be interpreted as [RFC2119] key
words.

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 an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 November 10, 2017.
http://www.rfc-editor.org/info/rfc8196.

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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Specification . . . . . . . . . . . . . . . . . . . 3
3.1. IS-IS Default Configuration . . . . . . . . . . . . . . . 3
3.2. IS-IS NET Generation . . . . . . . . . . . . . . . . . . 4
3.3. Router-Fingerprint TLV . . . . . . . . . . . . . . . . . 5
3.4. Protocol Operation . . . . . . . . . . . . . . . . . . . 6
3.4.1. Start-Up mode Startup Mode . . . . . . . . . . . . . . . . . . . . 6
3.4.2. Adjacency Formation . . . . . . . . . . . . . . . . . 7
3.4.3. IS-IS System ID Duplication Detection . . . . . . . . 7
3.4.4. Duplicate System ID Resolution Procedures . . . . . . 7
3.4.5. System ID and Router-Fingerprint Generation
Considerations . . . . . . . . . . . . . . . . . . . 8
3.4.6. Duplication of both Both System ID and Router-Fingerprint 9
3.5. Additional IS-IS TLVs Usage Guidelines . . . . . . . . . 10 11
3.5.1. Authentication TLV . . . . . . . . . . . . . . . . . 11
3.5.2. Metric Used in Reachability TLVs . . . . . . . . . . 11
3.5.3. Dynamic Host Name TLV . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 12
6. Acknowledgements References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . 12
7.1. Normative References . . . . . . . . . . . 13
Acknowledgements . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13

1. Introduction

This document specifies mechanisms for IS-IS [RFC1195]
[ISO_IEC10589][RFC5308] [ISO_IEC10589]
[RFC5308] to be auto-configuring. autoconfiguring. Such mechanisms could reduce the
management burden for configuring a network, especially where plug-and-play plug-
and-play device configuration is required.

IS-IS auto-configuration autoconfiguration is comprised of the following functions:

1. IS-IS default configuration. configuration

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

3. System ID duplication detection and resolution. resolution
4. ISIS IS-IS TLV utilization (Authentication (authentication TLV, metrics in
reachability advertisements, and Dynamic Host Name TLV). TLV)

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

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. When these words are not in ALL CAPS (such
as "should" or "Should"), they have their usual English meanings and
are not to be interpreted as [RFC2119] key words.

2. Scope

The auto-configuration autoconfiguration mechanisms support both IPv4 and IPv6
deployments.

These auto-configuration autoconfiguration mechanisms aim to cover simple deployment
cases. The following important features are not supported:

o Multiple multiple IS-IS instances. instances

o Multi-area multi-area and level-2 routing. routing

o Interworking interworking with other routing protocols. protocols

IS-IS auto-configuration autoconfiguration is primarily intended for use in small (i.e. (i.e.,
10s of devices) and unmanaged deployments. It allows IS-IS to be
used without the need for any configuration by the user. It is not
recommended for larger deployments.

3. Protocol Specification

3.1. IS-IS Default Configuration

This section defines the default configuration for an autoconfigured
router.

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

o IS-IS auto-configuration autoconfiguration instances MUST be configured as level-1, level-1 so
that the interfaces operate as level-1 only.

o originatingLSPBufferSize is set to 512.

o MaxAreaAddresses is set to 3 3.

o Extended IS Reachability reachability (TLV 22) and IP Reachability reachability (TLV 135)
TLVs [RFC5305] MUST be used i.e. used, i.e., a router operating in auto configuration
autoconfiguration mode MUST NOT use any of the following TLVs:

* IS IIS Neighbors (2) (TLV 2)

* IP Internal Reachability (128) Int. Reach (TLV 128)

* IP External Reachability (130) Ext. Address (TLV 130)

The TLVs listed above MUST be ignored on receipt.

3.2. IS-IS NET Generation

In IS-IS, a router (known as an Intermediate System) is identified by
a Network Entity Title (NET) (NET), which is a type of Network Service
Access Point (NSAP). The NET is the address of an instance of the
IS-IS protocol running on an Intermediate System (IS). IS.

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

o Area address

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

o System ID

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

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

- After its initial generation, the System ID SHOULD remain
stable. Changes such as interface enable/disable, interface
connect/disconnect, device reboot, firmware update, or
configuration changes SHOULD NOT cause the system System ID to
change. System ID change as part of the System ID collision
resolution process MUST be supported. Implementations
SHOULD allow the System ID to be cleared by a user initiated user-initiated
system reset.

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

3.3. Router-Fingerprint TLV

The Router-Fingerprint TLV is similar to the Router-Hardware-
Fingerprint TLV defined in [RFC7503]. However, the TLV defined here
includes a flags Flags field to support indicating that the router is in
Start-up
startup mode and is operating in auto-configuration autoconfiguration mode.

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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags Field | |
+-+-+-+-+-+-+-+-+ Router Fingerprint Router-Fingerprint (Variable) .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: to be assigned by IANA. 15.

Length: the length The length, in octets, of the value field. Must be >= 33.
Flags field (1 octet) "Flags" and "Router-
Fingerprint" fields.

Flags: 1 octet.

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S|A| Reserved |
+-+-+-+-+-+-+-+-+

S flag: when When set, indicates the router is in "start-up" "startup" mode.

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

Reserved: these bits These flags MUST be set to zero and MUST be ignored by the
receiver.

Router Fingerprint:

Router-Fingerprint: 32 or more octets.

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

Router Fingerprint

The Router-Fingerprint TLV with the A flag set MUST be included in Intermediate System to
Intermediate System
IS-IS Hellos (IIHs) originated by a router operating in
auto-configuration
autoconfiguration mode. An auto-configuration autoconfiguration mode router MUST ignore
IIHs that don't contain the Router Fingerprint TLV.

Router Fingerprint Router-Fingerprint TLV with the A flag
set.

The Router-Fingerprint TLV with the A flag set MUST be included in
Link State PDU (LSP) #0 originated by a router operating in auto-configuration
autoconfiguration mode. If an LSP #0 which does NOT contain a Router Fingerprint TLV is received by a Router router
operating in auto-configuration autoconfiguration mode and the LSP either does NOT
contain a Router-Fingerprint TLV or it does contain a Router-
Fingerprint TLV but the A flag is NOT set, then the LSP is flooded as
normal, but the entire LSP set originated by the sending router MUST
be ignored when running the Decision process. Process.

The router fingerprint 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

This section describes the operation of a router supporting auto-
configuration
autoconfiguration mode.

3.4.1. Start-Up mode Startup Mode

When a router starts operation in auto-configuration autoconfiguration mode, both the S
and A bits flags MUST be set in the Router Fingerprint Router-Fingerprint TLV included in
both hellos and LSP #0. During this mode mode, only LSP #0 is generated
and IS or IP/IPv6 reachability TLVs MUST NOT be included in LSP #0.
A router remains in Start-up startup mode for a minimum period of time
(recommended to be 1 minute). This time should be sufficient to
bring up adjacencies to all expected neighbors. A router leaves
Start-up
startup mode once the minimum time has elapsed and full LSP database
synchronization is achieved with all neighbors in the UP state.

When a router exits startup-mode startup mode, it clears the S bit flag in Router Router-
Fingerprint TLVs that it sends in hellos and LSP#0. LSP #0. The router MAY
now advertise the IS neighbor and IP/IPv6 prefix reachability in its
LSPs and MAY generate LSPs with a non-zero number.

The purpose of Start-up Mode startup mode is to minimize the occurrence of System
ID changes for a router once it has become fully operational. Any
System ID change during Start-up startup mode will have minimal impact on a
running network because because, while in Start-up mode startup mode, the router is not yet
being used for forwarding traffic.

3.4.2. Adjacency Formation

Routers operating in auto-configuration autoconfiguration mode MUST NOT form adjacencies
with routers which that are NOT operating in auto-
configuration autoconfiguration mode. The
presence of the Router Fingerprint Router-Fingerprint TLV with the A bit flag set indicates
the router is operating in auto-configuration autoconfiguration mode.

NOTE: The use of the special area address of all 0's 0s makes it unlikely
that a router which that is not operating in auto-configuration autoconfiguration mode will be
in the same area as a router operating in auto-
configuration autoconfiguration mode.
However, the check for the Router Fingerprint Router-Fingerprint TLV with the A bit flag set
provides additional protection.

3.4.3. IS-IS System ID Duplication Detection

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.
MAC (e.g.,
Media Access Control (MAC) address) which that are generally expected to be
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. Duplicate
System A duplicate system ID may occur between neighbors or
between routers in the same area which that are not neighbors.

Duplicate System

A duplicate system ID with a neighbor is detected when the System ID
received in an IIH is identical to the local System ID and the
Router-Fingerprint in the received Router-Fingerprint TLV does NOT
match the locally generated Router-Fingerprint.

Duplicate System

A duplicate system ID with a non-neighbor is detected when an LSP #0
is received, the System ID of the originator is identical to the
local System ID, and the Router-Fingerprint in the Router-Fingerprint
TLV does NOT match the locally generated Router-Fingerprint.

3.4.4. Duplicate System ID Resolution Procedures

When a duplicate System system ID is detected detected, one of the systems MUST
assign itself a different System ID and perform a protocol restart.
The resolution procedure attempts to minimize disruption to a running
network by choosing choosing, whenever possible, to restart a router which that is
in Start-up mode to be
restarted whenever possible. startup mode.

The contents of the Router-Fingerprint TLVs for the two routers with
duplicate System system IDs are compared.

If one TLV has the S bit flag set (router (the router is in Start-up startup mode) and one
TLV has the S bit flag clear (router (the router is NOT in Start-up mode) startup mode), the
router in
Start-up startup mode MUST generate a new System ID and restart the
protocol.

If both TLVs have the S bit flag set (both routers are in Start-up startup mode)
or both TLVs have the S bit flag clear (neither router is in Start-up
mode) startup
mode), then the router with the numerically smaller Router-Fingerprint Router-
Fingerprint MUST generate a new System ID and restart the protocol.

Fingerprint comparison is performed octet by octet starting from the
first received octet until a difference is detected. If the
fingerprints have different lengths and all octets up to the shortest
length are identical identical, then the fingerprint with smaller length is
considered smaller. smaller on the whole.

If the fingerprints are identical in both content and length (and the
state of the S bit flag is identical) identical), and the duplication is detected in
hellos
hellos, then the both routers MUST generate a new System ID and restart
the protocol.

If fingerprints are identical in both content and length length, and the
duplication is detected in LSP #0 #0, then the procedures defined in
Section 3.4.6 MUST be followed.

3.4.5. System ID and Router-Fingerprint Generation Considerations

As specified in this document, there are two distinguishing items
that need to be self-generated: the System ID and Router-Fingerprint.
In a network device, normally there are some resources which that can
provide an extremely high probability of uniqueness (some examples
listed below). These resources can be used as seeds to derive
identifiers.
identifiers:

o MAC address(es)

o Configured IP address(es)

o Hardware IDs (e.g. (e.g., CPU ID)

o Device serial number(s)

o System clock at a certain certain, specific time

o Arbitrary received packet(s) on an interface(s)
This document recommends 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 regenerate the System ID when
duplication happens.

This document also does not specify a specific method to generate the
Router-Fingerprint. Router-
Fingerprint.

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 hardware/software limitations and the
lack of sufficient communication packets at the initial stage in home
routers when doing ISIS auto-configuration. IS-IS autoconfiguration. In this case, this
document suggests using the MAC address as the System ID and
generating a
pseudo-random pseudorandom number based on another seed (such as the
memory address of a certain variable in the program) as the Router-
Fingerprint. The pseudo-random pseudorandom number might not have a very high
probability of uniqueness in this solution, solution but should be sufficient
in home networks network scenarios.

The considerations surrounding System ID stability described in
section
Section 3.2 also need to be applied.

3.4.6. Duplication of both Both System ID and Router-Fingerprint

As described above, the resources for generating a System ID/
Fingerprint ID /
Router-Fingerprint might be very constrained during the initial
stages. Hence, the duplication of both System ID and Router-Fingerprint needs Router-
Fingerprint need to be considered. In such a case case, it is possible
that a router will receive an LSP with a System ID and Router-Fingerprint Router-
Fingerprint identical to the local values values, but the LSP is NOT
identical to the locally generated
copy i.e. copy, i.e., the sequence number is
newer or the sequence number is the same same, but the LSP has a valid
checksum which that does not match. The term DD-LSP (Duplication Detection
LSP) is used to describe such an LSP.

In a benign case, this will occur if a router restarts and it
receives copies of its own LSPs from its previous incarnation. This
benign case needs to be distinguished from the pathological case
where there are two different routers with the same System ID and the
same Router-Fingerprint.

In the benign case, the restarting router will generate a new version
of its own LSP with a higher sequence number and flood the new LSP
version. This will cause other routers in the network to update
their LSPDB LSP Database (LSPDB) and synchronization will be achieved.

In the pathological case case, the generation of a new version of an LSP
by one of the "twins" will cause the other twin to generate the same
LSP with a higher sequence number - -- and oscillation will continue
without achieving LSPDB synchronization.

Note that a comparison of the S bit flag in the Router-Fingerprint TLV
cannot be
performed performed, as in the benign case it is expected that the S bit
flag will be clear. Also note that the conditions for detecting a
duplicate System system ID will NOT be satisfied because both the System ID
and the Router-
Fingerprint Router-Fingerprint will be identical.

The following procedure is defined:

DD-state is a boolean which that indicates if a
DD-LSP #0 has been received received.
DD-count is the count of the number of occurences occurrences
of reception of a DD-LSP DD-LSP.
DD-timer is a timer associated with reception of
DD-LSPs. Recommended
DD-LSPs; the recommended value is 60 seconds.
DD-max is the maximum number of DD-LSPs allowed
to be received in DD-timer interval.
Recommended interval;
the recommended value is 3.

When a DD-LSP is received:

If DD-state is FALSE:
DD-state is set to TRUE TRUE.
DD-timer is started started.
DD-count is initialized to 1.

If DD-state is TRUE:
DD-count is incremented incremented.
If DD-count is >= DD-max:
Local
The local system MUST generate a new System ID
and Router-Fingerprint and restart the protocol protocol.
DD-state is (re)initialized to FALSE and
DD-timer cancelled. is canceled.

If DD-timer expires:
DD-state is set to FALSE.

Note that to minimze minimize the likelihood of duplication of both System ID
and Router-fingerprint reoccuring, Router-Fingerprint reoccurring, routers SHOULD have more
entropies available. One simple way to achieve this is to add the
LSP sequence number of the next LSP it will send to the Router-Fingerprint. Router-
Fingerprint.

3.5. Additional IS-IS TLVs Usage Guidelines

This section describes the behavior of selected TLVs when used by a
router supporting IS-IS auto-configuration. autoconfiguration.

3.5.1. Authentication TLV

It is RECOMMENDED that IS-IS routers supporting this specification
offer an option to explicitly configure a single password for HMAC-
MD5 authentication as specified in[RFC5304]. in [RFC5304].

3.5.2. Metric Used in Reachability TLVs

It is RECOMMENDED that IS-IS auto-configuration autoconfiguration routers use a high
metric value (e.g. (e.g., 100000) as default in order to allow manually
configured adjacencies to be preferred over auto-configured. autoconfigured.

3.5.3. Dynamic Host Name TLV

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

To guarantee the uniqueness of the host name, hostname, the System ID SHOULD be
appended as a suffix in the names.

4. Security Considerations

In the absence of cryptographic authentication authentication, it is possible for an
attacker to inject a PDU falsely indicating there is a duplicate
system-id.
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
autoconfiguration as it requires some manual configuration.

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

5. IANA Considerations

This document requires the definition of details a new IS-IS TLV to be reflected in the "IS-IS TLV
Codepoints" registry:

Type Description

Value Name IIH LSP SNP Purge
---- ------------ --- --- --- -----
TBA
15 Router-Fingerprint Y Y N Y

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 Thomann,
Hannes Gredler, Peter Lothberg, Uma Chundury, Qin Wu, Sheng Jiang and
Nan Wu, etc.

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

7. References

7.1.

6.1. Normative References

[ISO_IEC10589]
"Intermediate system
International Organization for Standardization,
"Information technology -- Telecommunications and
information exchange between systems -- Intermediate
System to Intermediate system System intra-domain routeing
information exchange protocol for use in conjunction with
the protocol for providing the connectionless-mode Network Service network
service (ISO 8473), 8473)", ISO/IEC 10589:2002, Second Edition.", Nov Edition,
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>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

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

7.2.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>.

6.2. Informative References

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

[RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary",
RFC 7991, DOI 10.17487/RFC7991, December 2016,
<http://www.rfc-editor.org/info/rfc7991>.

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 Thomann,
Hannes Gredler, Peter Lothberg, Uma Chundury, Qin Wu, Sheng Jiang,
and Nan Wu, etc.

Authors' Addresses

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

Email: leo.liubing@huawei.com

Les Ginsberg
Cisco Systems
821 Alder Drive
Milpitas CA 95035
USA
United States of America

Email: ginsberg@cisco.com

Bruno Decraene
Orange
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