draft-ietf-anima-autonomic-control-plane-03.txt   draft-ietf-anima-autonomic-control-plane-04.txt 
ANIMA WG M. Behringer, Ed. ANIMA WG M. Behringer, Ed.
Internet-Draft T. Eckert Internet-Draft Cisco Systems
Intended status: Standards Track Cisco Systems Intended status: Standards Track T. Eckert
Expires: January 9, 2017 S. Bjarnason Expires: May 4, 2017
S. Bjarnason
Arbor Networks Arbor Networks
July 8, 2016 October 31, 2016
An Autonomic Control Plane An Autonomic Control Plane
draft-ietf-anima-autonomic-control-plane-03 draft-ietf-anima-autonomic-control-plane-04
Abstract Abstract
Autonomic functions need a control plane to communicate, which Autonomic functions need a control plane to communicate, which
depends on some addressing and routing. This Autonomic Control Plane depends on some addressing and routing. This Autonomic Control Plane
should ideally be self-managing, and as independent as possible of should ideally be self-managing, and as independent as possible of
configuration. This document defines an "Autonomic Control Plane", configuration. This document defines an "Autonomic Control Plane",
with the primary use as a control plane for autonomic functions. It with the primary use as a control plane for autonomic functions. It
also serves as a "virtual out of band channel" for OAM communications also serves as a "virtual out of band channel" for OAM communications
over a network that is not configured, or mis-configured. over a network that is not configured, or mis-configured.
skipping to change at page 1, line 38 skipping to change at page 1, line 39
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 January 9, 2017. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 14 skipping to change at page 2, line 15
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Cases for an Autonomic Control Plane . . . . . . . . . . 4 2. Use Cases for an Autonomic Control Plane . . . . . . . . . . 4
2.1. An Infrastructure for Autonomic Functions . . . . . . . . 4 2.1. An Infrastructure for Autonomic Functions . . . . . . . . 4
2.2. Secure Bootstrap over an Unconfigured Network . . . . . . 4 2.2. Secure Bootstrap over an Unconfigured Network . . . . . . 5
2.3. Data Plane Independent Permanent Reachability . . . . . . 5 2.3. Data Plane Independent Permanent Reachability . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Self-Creation of an Autonomic Control Plane . . . . . . . . . 8 5. Self-Creation of an Autonomic Control Plane . . . . . . . . . 8
5.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Domain Certificate with ANIMA information . . . . . . 8 5.1.1. Domain Certificate with ANIMA information . . . . . . 8
5.1.2. AN Adjacency Table . . . . . . . . . . . . . . . . . 9 5.1.2. AN Adjacency Table . . . . . . . . . . . . . . . . . 9
5.2. Neighbor discovery via mDNS/DNS-SD . . . . . . . . . . . 9 5.2. Neighbor discovery . . . . . . . . . . . . . . . . . . . 10
5.3. Candidate ACP Neighbor Selection . . . . . . . . . . . . 10 5.2.1. L2 topology considerations . . . . . . . . . . . . . 10
5.4. Channel Selection . . . . . . . . . . . . . . . . . . . . 11 5.2.2. CDP/LLDP/mDNS considerations . . . . . . . . . . . . 11
5.5. Security Association protocols . . . . . . . . . . . . . 12 5.2.3. Discovery with GRASP . . . . . . . . . . . . . . . . 11
5.5.1. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 13 5.2.4. Discovery and BRSKY . . . . . . . . . . . . . . . . . 12
5.5.2. ACP via GRE/IPsec . . . . . . . . . . . . . . . . . . 13 5.3. Candidate ACP Neighbor Selection . . . . . . . . . . . . 12
5.5.3. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 13 5.4. Channel Selection . . . . . . . . . . . . . . . . . . . . 13
5.5.4. GRASP/TLS negotiation . . . . . . . . . . . . . . . . 13 5.5. Security Association protocols . . . . . . . . . . . . . 14
5.5.5. ACP Security Profiles . . . . . . . . . . . . . . . . 14 5.5.1. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 14
5.6. GRASP instance details . . . . . . . . . . . . . . . . . 14 5.5.2. ACP via GRE/IPsec . . . . . . . . . . . . . . . . . . 15
5.7. Context Separation . . . . . . . . . . . . . . . . . . . 14 5.5.3. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 15
5.8. Addressing inside the ACP . . . . . . . . . . . . . . . . 15 5.5.4. GRASP/TLS negotiation . . . . . . . . . . . . . . . . 15
5.8.1. Fundamental Concepts of Autonomic Addressing . . . . 15 5.5.5. ACP Security Profiles . . . . . . . . . . . . . . . . 16
5.8.2. The ACP Addressing Base Scheme . . . . . . . . . . . 16 5.6. GRASP instance details . . . . . . . . . . . . . . . . . 16
5.8.3. ACP Addressing Sub-Scheme . . . . . . . . . . . . . . 17 5.7. Context Separation . . . . . . . . . . . . . . . . . . . 16
5.8.4. Usage of the Zone Field . . . . . . . . . . . . . . . 18 5.8. Addressing inside the ACP . . . . . . . . . . . . . . . . 16
5.8.5. Other ACP Addressing Sub-Schemes . . . . . . . . . . 19 5.8.1. Fundamental Concepts of Autonomic Addressing . . . . 17
5.9. Routing in the ACP . . . . . . . . . . . . . . . . . . . 19 5.8.2. The ACP Addressing Base Scheme . . . . . . . . . . . 18
5.10. General ACP Considerations . . . . . . . . . . . . . . . 19 5.8.3. ACP Addressing Sub-Scheme . . . . . . . . . . . . . . 18
6. Workarounds for Non-Autonomic Nodes . . . . . . . . . . . . . 20 5.8.4. Usage of the Zone Field . . . . . . . . . . . . . . . 20
6.1. Connecting a Non-Autonomic Controller / NMS system . . . 20 5.8.5. Other ACP Addressing Sub-Schemes . . . . . . . . . . 20
6.2. ACP through Non-Autonomic L3 Clouds . . . . . . . . . . . 20 5.9. Routing in the ACP . . . . . . . . . . . . . . . . . . . 21
7. Self-Healing Properties . . . . . . . . . . . . . . . . . . . 21 5.10. General ACP Considerations . . . . . . . . . . . . . . . 21
8. Self-Protection Properties . . . . . . . . . . . . . . . . . 22 6. Workarounds for Non-Autonomic Nodes . . . . . . . . . . . . . 22
9. The Administrator View . . . . . . . . . . . . . . . . . . . 22 6.1. Connecting a Non-Autonomic Controller / NMS system . . . 22
10. Explanations . . . . . . . . . . . . . . . . . . . . . . . . 23 6.2. ACP through Non-Autonomic L3 Clouds . . . . . . . . . . . 22
10.1. Why GRASP to discover autonomic neighbors . . . . . . . 23 7. Self-Healing Properties . . . . . . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Self-Protection Properties . . . . . . . . . . . . . . . . . 24
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. The Administrator View . . . . . . . . . . . . . . . . . . . 24
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
14.1. Initial version . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 26 13. Change log [RFC Editor: Please remove] . . . . . . . . . . . 26
14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 26 13.1. Initial version . . . . . . . . . . . . . . . . . . . . 26
14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 26 13.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 26
14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 26 13.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 26
14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 27 13.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 27
14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 27 13.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 27
14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 28 13.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 27
14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 28 13.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 27
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 28
Appendix A. Background on the choice of routing protocol . . . . 30 13.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 28
13.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 29
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Background on the choice of routing protocol . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Autonomic Networking is a concept of self-management: Autonomic Autonomic Networking is a concept of self-management: Autonomic
functions self-configure, and negotiate parameters and settings functions self-configure, and negotiate parameters and settings
across the network. [RFC7575] defines the fundamental ideas and across the network. [RFC7575] defines the fundamental ideas and
design goals of Autonomic Networking. A gap analysis of Autonomic design goals of Autonomic Networking. A gap analysis of Autonomic
Networking is given in [RFC7576]. The reference architecture for Networking is given in [RFC7576]. The reference architecture for
Autonomic Networking in the IETF is currently being defined in the Autonomic Networking in the IETF is currently being defined in the
skipping to change at page 4, line 31 skipping to change at page 4, line 37
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
This document describes some use cases for the ACP in Section 2, it This document describes some use cases for the ACP in Section 2, it
defines the requirements in Section 3, Section 4 gives an overview defines the requirements in Section 3, Section 4 gives an overview
how an Autonomic Control Plane is constructed, and in Section 5 the how an Autonomic Control Plane is constructed, and in Section 5 the
detailed process is explained. Section 6 explains how non-autonomic detailed process is explained. Section 6 explains how non-autonomic
nodes and networks can be integrated, and Section 5.5 the first nodes and networks can be integrated, and Section 5.5 the first
channel types for the ACP. channel types for the ACP.
The document "Autonomic Network Stable Connectivity" The document "Autonomic Network Stable Connectivity"
[I-D.eckert-anima-stable-connectivity] describes how the ACP can be [I-D.ietf-anima-stable-connectivity] describes how the ACP can be
used to provide stable connectivity for OAM applications. It also used to provide stable connectivity for OAM applications. It also
explains on how existing management solutions can leverage the ACP in explains on how existing management solutions can leverage the ACP in
parallel with traditional management models, when to use the ACP parallel with traditional management models, when to use the ACP
versus the data plane, how to integrate IPv4 based management, etc. versus the data plane, how to integrate IPv4 based management, etc.
2. Use Cases for an Autonomic Control Plane 2. Use Cases for an Autonomic Control Plane
2.1. An Infrastructure for Autonomic Functions 2.1. An Infrastructure for Autonomic Functions
Autonomic Functions need a stable infrastructure to run on, and all Autonomic Functions need a stable infrastructure to run on, and all
skipping to change at page 6, line 6 skipping to change at page 6, line 13
global routing table. global routing table.
o For control plane protocols, the ACP allows their operation even o For control plane protocols, the ACP allows their operation even
when the data plane is temporarily faulty, or during transitional when the data plane is temporarily faulty, or during transitional
events, such as routing changes, which may affect the control events, such as routing changes, which may affect the control
plane at least temporarily. This is specifically important for plane at least temporarily. This is specifically important for
autonomic service agents, which could affect data plane autonomic service agents, which could affect data plane
connectivity. connectivity.
The document "Autonomic Network Stable Connectivity" The document "Autonomic Network Stable Connectivity"
[I-D.eckert-anima-stable-connectivity] explains the use cases for the [I-D.ietf-anima-stable-connectivity] explains the use cases for the
ACP in significantly more detail and explains how the ACP can be used ACP in significantly more detail and explains how the ACP can be used
in practical network operations. in practical network operations.
3. Requirements 3. Requirements
The Autonomic Control Plane has the following requirements: The Autonomic Control Plane has the following requirements:
1. The ACP SHOULD provide robust connectivity: As far as possible, 1. The ACP SHOULD provide robust connectivity: As far as possible,
it should be independent of configured addressing, configuration it should be independent of configured addressing, configuration
and routing. Requirements 2 and 3 build on this requirement, but and routing. Requirements 2 and 3 build on this requirement, but
skipping to change at page 9, line 39 skipping to change at page 10, line 10
The adjacency table MAY contain information about the validity and The adjacency table MAY contain information about the validity and
trust of the adjacent autonomic node's certificate. However, trust of the adjacent autonomic node's certificate. However,
subsequent steps MUST always start with authenticating the peer. subsequent steps MUST always start with authenticating the peer.
The adjacency table contains information about adjacent autonomic The adjacency table contains information about adjacent autonomic
nodes in general, independently of their domain and trust status. nodes in general, independently of their domain and trust status.
The next step determines to which of those autonomic nodes an ACP The next step determines to which of those autonomic nodes an ACP
connection should be established. connection should be established.
5.2. Neighbor discovery via mDNS/DNS-SD 5.2. Neighbor discovery
Autonomic devices use DNS-SD/mDNS to discover the IPv6 link-local 5.2.1. L2 topology considerations
address of autonomic neighbors across L2 adjacencies. The result is
stored in the AN Adjacency Table, see Section 5.1.2.
o If a node is not part an autonomic domain, it starts autonomic ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2
enrollment with an adjacent node as the proxy using procedures .../ \ \ ...
described in [I-D.ietf-anima-bootstrapping-keyinfra]. ANrtrI ------ \ ------- ANrtrN
ANswitchI ...
o If a node is part of an autonomic domain (eg: enrolled with a Figure 2
certificate) and has a working ACP towards one or more registrars
(including when it is a registrar herself), it MUST announce the
"_bootstrapks._tcp.local." service to indicate that it can act as
a proxy for bootstrap. This can be superceeded by Intent.
o If a node is part of an autonomic domain, it also announces the Consider a large L2 LAN with ANrtr1...ANrtrN connected via some
"_anima_acp_ll._udp.local" service via DNS-based Service Discovery topology of L2 switches (eg: in a large enterprise campus or IoT
[RFC6763] over Multicast DNS [RFC6762] and searches for that environment using large L2 LANs). If the discovery protocol used for
services to discover neighbors. This can be superceeded by Intent the ACP is operating at the subnet level, every AN router will see
or future work (see below). all other AN routers on the LAN as neighbors and a full mesh of ACP
channels will be built. If some or all of the AN switches are
autonomic with the same discovery protocol, then the full mesh would
include those switches as well.
o TBD: Should the domain also be announced with the A full mesh of ACP connections like this can creates fundamental
"_anima_acp_ll._udp.local" service? Pro: Then a node "sees" which challenges. The number of security associations of the secure
domain a neighbor is and can make selection more efficient. Con: channel protocols will not scale arbitrarily, especially when they
A proxy exposes its domain by default. leverage platform accelerated encryption/decryption. Likewise, any
other ACP operations needs to scale to the number of direct ACP
neigbors. An AN router with just 4 interfaces might be deployed into
a LAN with hundreds of neighbors connected via switches. Introducing
such a new unpredictable scaling factor requirement makes it harder
to support the ACP on arbitrary platforms and in arbitrary
deployments.
o To prevent unaccceptable levels of network traffic the congestion Predictable scaling requirements for ACP neighbors can most easily be
avoidance mechanisms specified in [RFC6762] section 7 MUST be achieved if in topologies like these, AN capable L2 switches can
followed. Announcements for the "_anima_acp._udp.local" service ensure that discovery messages terminate on them so that neighboring
MUST only use the IPv6 link-local address of the announcing AN routers and switches will only find the physcially connected AN L2
interface. Other service parameters (SRV parameters, TXT records) switches as their candidate ACP neighbors. With such a discovery
are ignored to avoid creating additional attack vectors from bogus mechanism in place, the ACP and its security associations will only
announcements by third parties. need to scale to the number of physcial interfaces instead of a
potentially much larger number of "LAN-connected" neighbors. And the
ACP topology will follow directly the physical topology, something
which can then also be leveraged in management operations or by ASAs.
o Note that two different service names are used between bootstrap In the example above, consider ANswitch1 and ANswitchI are AN
and ACP because these functions may not always go along with each capable, and ANswitch2 is not AN capable. The desired ACP topology
other. For example, an autonomic device connecting to the is therefore that ANrtr1 and ANrtrI only have an ACP connetion to
Internet can still provide Bootstrap proxy functions via any of ANswitch1, and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP
the discovery mechanisms specified in the bootstrap document, connection amongst each other. ANswitch1 also has an ACP connection
while building the ACP is only defined in this document to be with ANswitchI and ANswitchI has ACP connections to anything else
across IPv6 LL adjacencies. The reason for this difference is behind it.
that in case of non-L2-adjacent devices, it is appropriate to
perform bootstrap via a centralized bootstrap proxy, but the ACP
should be built towards the nearest possible ACP neighbors, and in
the absence of L2 adjacencies this is a more complex discovery
problem, left for future work - and different discovery
mechanisms.
o An autonomic node stores the results of the neighbor discovery in 5.2.2. CDP/LLDP/mDNS considerations
the AN Adjacency table.
LLDP (and Ciscos CDP) are example of L2 discovery protocols that do
terminate their messages on L2 ports. Unfortunately, they will also
terminate their messages if they do not support the ACP and would
then inhibit ACP neighbor discovery
mDNS operates at the subnet level, and is also used on L2 switches.
The authors of this document are not aware of mDNS implementation
that terminate their messages on L2 ports instead of the subnet
level. If mDNS was used as the ACP discovery mechanism on an ACP
capable L2 switch, then this would be necessary to implement. It is
likely that termination of mDNS messages could only be applied to all
mDNS messages from a port, which would then make it necessary to
software forward any non-ACP related mDNS messages to maintain prior
non-ACP mDNS functionality. With low performance of software
forwarding in many L2 switches, this could easily make the ACP
unsupportable on such L2 switches.
5.2.3. Discovery with GRASP
In conclusion for the above described considerations, the ACP uses
"insecure" instances of GRASP for discovery of ACP neighbors because
it can easily be set up to match the requiremetns without affecting
other uses of the protocol.
The name of the GRASP objective to announce/discover the capability
of a neighbor to run the ACP is "ACP". All other parameters are
defined in section [I-D.ietf-anima-grasp] where these instances of
GRASP are called "DULL" (Discovery Unsolicited Link Local). As
explained above, in an ACP enabled L2 switch, each of these instances
would actually need to be per-L2-port. The result of the discovery
is the IPv6 link-local address of the neighbor. It is stored in the
AN Adjacency Table, see Section 5.1.2 which then drives the further
building of the ACP to that neighbor.
For example, ANswitch1 would run separate DULL GRASP instances on its
ports to ANrtr1, ANswitch2 and ANswitchI, even though all those three
ports may be in the data plane in the same (V)LAN. This is easily
achieved by extracting native GRASP multicast messages by their MAC
multicast destination address. None of the other type of GRASP
instances (eg: as used inside the ACP) use GRASP messages that would
be affected by such extraction, because all other GRASP messages have
encrypted encapsulations.
5.2.4. Discovery and BRSKY
Before a node has a domain certificate, it can not participate in the
ACP and therefore does also not try to discover an ACP neighbor.
Instead, it uses the discovery mechanism described in
[I-D.ietf-anima-grasp] to discover a bootstrap proxy. Currently,
that document describes mDNS as the protocol of choice for that
discovery. In the context of above topology example, ANrtr1 might
therefore discover and choose any ANrtr or ANswitch on the LAN that
is already part of the autonomic domain - instead of the closest one
which is ANswitch1. This choice of bootstrap proxy does not impact
in the later building of the ACP on ANrtr1 and is therefore not a
concern for the ACP.
Once a device has its domain certificate, it will start announcing
itself via GRASP as ACP capable.
When an autonomic device is a registrar, it will announce the
registrar function via GRASP in the ACP as the "6JOIN" objective. An
AN device that is a registrar or learns about one or more reachable
registrars via this GRASP/ACP announcements will announce itself as a
boostrap proxy via mDNS. See [I-D.richardson-anima-6join-discovery]
for more details.
5.3. Candidate ACP Neighbor Selection 5.3. Candidate ACP Neighbor Selection
An autonomic node must determine to which other autonomic nodes in An autonomic node must determine to which other autonomic nodes in
the adjacency table it should build an ACP connection. This is based the adjacency table it should build an ACP connection. This is based
on the information in the AN Adjacency table. on the information in the AN Adjacency table.
The ACP is by default established exclusively between nodes in the The ACP is by default established exclusively between nodes in the
same domain. same domain.
skipping to change at page 14, line 9 skipping to change at page 15, line 49
them. In the absence of Intent, the mechanism choosen is the best them. In the absence of Intent, the mechanism choosen is the best
one for the device with the lower Device-ID. one for the device with the lower Device-ID.
After agreeing on a channel mechanism, Alice and Bob start the After agreeing on a channel mechanism, Alice and Bob start the
selected Channel protocol. The GRASP/TLS connection can be kept selected Channel protocol. The GRASP/TLS connection can be kept
alive or timed out as long as the seelected channel protocol has a alive or timed out as long as the seelected channel protocol has a
secure association between Alice and Bob. When it terminates, it secure association between Alice and Bob. When it terminates, it
needs to be re-negotiated via GRASP/TLS. needs to be re-negotiated via GRASP/TLS.
Negotiation of a channel type may require IANA assignments of code Negotiation of a channel type may require IANA assignments of code
points. See IANA Considerations (Section 12) for the formal points. See IANA Considerations (Section 11) for the formal
definition of those code points. definition of those code points.
TBD: The exact negotiation steps in GRASP to achieve this outcome. TBD: The exact negotiation steps in GRASP to achieve this outcome.
5.5.5. ACP Security Profiles 5.5.5. ACP Security Profiles
A baseline autonomic device MUST support IPsec and SHOULD support A baseline autonomic device MUST support IPsec and SHOULD support
GRASP/TLS and dTLS. A constrained autonomic device MUST support GRASP/TLS and dTLS. A constrained autonomic device MUST support
dTLS. dTLS.
skipping to change at page 14, line 31 skipping to change at page 16, line 22
ACP mechanisms they suppport. ACP mechanisms they suppport.
5.6. GRASP instance details 5.6. GRASP instance details
Received GRASP packets are assigned to an instance of GRASP by the Received GRASP packets are assigned to an instance of GRASP by the
context they are received on: context they are received on:
o GRASP packets received on an ACP (virtual) interfaces are assigned o GRASP packets received on an ACP (virtual) interfaces are assigned
to the ACP instance of GRASP to the ACP instance of GRASP
o GRASP/UDP packets received on L2 interfaces/ports where the device
is willing to run ACP are assigned to a DULL instance of GRASP for
that interface/port.
o GRASP packets received inside a TLS connection established for o GRASP packets received inside a TLS connection established for
GRASP/TLS ACP negotiation are assigned to a separate instance of GRASP/TLS ACP negotiation are assigned to a separate instance of
GRASP for that negotiation. GRASP for that negotiation.
TBD: The Details of the GRASP objective/packet formats still need to
be defined. Eg: Need to define an allocation for the objective of
"Autonomic Node".
5.7. Context Separation 5.7. Context Separation
The ACP is in a separate context from the normal data plane of the The ACP is in a separate context from the normal data plane of the
device. This context includes the ACP channels IPv6 forwarding and device. This context includes the ACP channels IPv6 forwarding and
routing as well as any required higher layer ACP functions. routing as well as any required higher layer ACP functions.
In classical network device platforms, a dedicated so called "Virtual In classical network device platforms, a dedicated so called "Virtual
routing and forwarding instance" (VRF) is one logical implementation routing and forwarding instance" (VRF) is one logical implementation
option for the ACP. If possible by the platform SW architecture, option for the ACP. If possible by the platform SW architecture,
separation options that minimize shared components are preferred. separation options that minimize shared components are preferred.
skipping to change at page 16, line 33 skipping to change at page 18, line 24
5.8.2. The ACP Addressing Base Scheme 5.8.2. The ACP Addressing Base Scheme
The Base ULA addressing scheme for autonomic nodes has the following The Base ULA addressing scheme for autonomic nodes has the following
format: format:
8 40 3 77 8 40 3 77
+--+--------------+------+------------------------------------------+ +--+--------------+------+------------------------------------------+
|FD| hash(domain) | Type | (sub-scheme) | |FD| hash(domain) | Type | (sub-scheme) |
+--+--------------+------+------------------------------------------+ +--+--------------+------+------------------------------------------+
Figure 2: ACP Addressing Base Scheme Figure 3: ACP Addressing Base Scheme
The first 48 bits follow the ULA scheme, as defined in [RFC4193], to The first 48 bits follow the ULA scheme, as defined in [RFC4193], to
which a type field is added: which a type field is added:
o "FD" identifies a locally defined ULA address. o "FD" identifies a locally defined ULA address.
o The ULA "global ID" is set here to be a hash of the domain name, o The ULA "global ID" is set here to be a hash of the domain name,
which results in a pseudo-random 40 bit value. It is calculated which results in a pseudo-random 40 bit value. It is calculated
as the first 40 bits of the MD5 hash of the domain name, in the as the first 40 bits of the MD5 hash of the domain name, in the
example "example.com". example "example.com".
skipping to change at page 17, line 15 skipping to change at page 18, line 52
5.8.3. ACP Addressing Sub-Scheme 5.8.3. ACP Addressing Sub-Scheme
The sub-scheme defined here is defined by the Type value 0 (zero) in The sub-scheme defined here is defined by the Type value 0 (zero) in
the base scheme. the base scheme.
51 13 63 1 51 13 63 1
+------------------------+---------+----------------------------+---+ +------------------------+---------+----------------------------+---+
| (base scheme) | Zone ID | Device ID | V | | (base scheme) | Zone ID | Device ID | V |
+------------------------+---------+----------------------------+---+ +------------------------+---------+----------------------------+---+
Figure 3: ACP Addressing Sub-Scheme Figure 4: ACP Addressing Sub-Scheme
The fields are defined as follows: [Editor's note: The lengths of the The fields are defined as follows: [Editor's note: The lengths of the
fields is for discussion.] fields is for discussion.]
o Zone ID: If set to all zero bits: The device ID bits are used as o Zone ID: If set to all zero bits: The device ID bits are used as
an identifier (as opposed to a locator). This results in a non- an identifier (as opposed to a locator). This results in a non-
hierarchical, flat addressing scheme. Any other value indicates a hierarchical, flat addressing scheme. Any other value indicates a
zone. See section Section 5.8.4 on how this field is used in zone. See section Section 5.8.4 on how this field is used in
detail. detail.
skipping to change at page 20, line 42 skipping to change at page 22, line 38
the entire ACP, without further authentication. Thus, this the entire ACP, without further authentication. Thus, this
connection must be physically controlled. connection must be physically controlled.
The non-autonomic NMS host must be routed in the ACP. This involves The non-autonomic NMS host must be routed in the ACP. This involves
two parts: 1) the NMS host must point default to the AN device for two parts: 1) the NMS host must point default to the AN device for
the ULA prefix used inside the ACP, and 2) the prefix used between AN the ULA prefix used inside the ACP, and 2) the prefix used between AN
node and NMS host must be announced into the ACP, and distributed node and NMS host must be announced into the ACP, and distributed
there. there.
The document "Autonomic Network Stable Connectivity" The document "Autonomic Network Stable Connectivity"
[I-D.eckert-anima-stable-connectivity] explains in more detail how [I-D.ietf-anima-stable-connectivity] explains in more detail how the
the ACP can be integrated in a mixed NOC environment. ACP can be integrated in a mixed NOC environment.
6.2. ACP through Non-Autonomic L3 Clouds 6.2. ACP through Non-Autonomic L3 Clouds
Not all devices in a network may be autonomic. If non-autonomic Not all devices in a network may be autonomic. If non-autonomic
Layer-2 devices are between autonomic nodes, the communications Layer-2 devices are between autonomic nodes, the communications
described in this document should work, since it is IP based. described in this document should work, since it is IP based.
However, non-autonomic Layer-3 devices do not forward link local However, non-autonomic Layer-3 devices do not forward link local
autonomic messages, and thus break the Autonomic Control Plane. autonomic messages, and thus break the Autonomic Control Plane.
One workaround is to manually configure IP tunnels between autonomic One workaround is to manually configure IP tunnels between autonomic
skipping to change at page 22, line 9 skipping to change at page 24, line 4
renewal of certificates that are to expire in the future, and it may renewal of certificates that are to expire in the future, and it may
prevent the enrolment of new devices during the partition. prevent the enrolment of new devices during the partition.
After a network partition, a re-merge will just establish the After a network partition, a re-merge will just establish the
previous status, certificates can be renewed, the CRL is available, previous status, certificates can be renewed, the CRL is available,
and new devices can be enrolled everywhere. Since all devices use and new devices can be enrolled everywhere. Since all devices use
the same trust anchor, a re-merge will be smooth. the same trust anchor, a re-merge will be smooth.
Merging two networks with different trust anchors requires the trust Merging two networks with different trust anchors requires the trust
anchors to mutually trust each other (for example, by cross-signing). anchors to mutually trust each other (for example, by cross-signing).
As long as the domain names are different, the addressing will not As long as the domain names are different, the addressing will not
overlap (see Section 5.8). overlap (see Section 5.8).
8. Self-Protection Properties 8. Self-Protection Properties
As explained in Section 5, the ACP is based on channels being built As explained in Section 5, the ACP is based on secure channels built
between devices which have been previously authenticated based on between devices that have mutually authenticated each other with
their domain certificates. The channels themselves are protected their domain certificates. The channels themselves are protected
using standard encryption technologies like DTLS or IPsec which using standard encryption technologies like DTLS or IPsec which
provide additional authentication during channel establishment, data provide additional authentication during channel establishment, data
integrity and data confidentiality protection of data inside the ACP integrity and data confidentiality protection of data inside the ACP
and in addition, provide replay protection. and in addition, provide replay protection.
An attacker will therefore not be able to join the ACP unless having An attacker will therefore not be able to join the ACP unless having
a valid domain certificate, also packet injection and sniffing a valid domain certificate, also packet injection and sniffing
traffic will not be possible due to the security provided by the traffic will not be possible due to the security provided by the
encryption protocol. encryption protocol.
skipping to change at page 23, line 15 skipping to change at page 25, line 11
be separated from visibility of data plane so automated systems will be separated from visibility of data plane so automated systems will
never have to deal with ACP aspect unless they explicitly desire to never have to deal with ACP aspect unless they explicitly desire to
do so. do so.
Since an ACP is self-protecting, a device not supporting the ACP, or Since an ACP is self-protecting, a device not supporting the ACP, or
without a valid domain certificate cannot connect to it. This means without a valid domain certificate cannot connect to it. This means
that by default a traditional controller or network management system that by default a traditional controller or network management system
cannot connect to an ACP. See Section 6.1 for more details on how to cannot connect to an ACP. See Section 6.1 for more details on how to
connect an NMS host into the ACP. connect an NMS host into the ACP.
10. Explanations 10. Security Considerations
This section is non-normative and intended to provide further
explanations for the choices made in this document.
10.1. Why GRASP to discover autonomic neighbors
None of the considered mechanisms to establish security associations
(eg: IPsec or dTLS) include mechanisms to discover candidate
neighbors, so these security mechanisms themselves are insufficient
for the discovery.
Existing L2 mechanisms such as LLDP (or vendor speccific alternatives
like Ciscos CDP) are L2 link-local. If an autonomic device connects
via an LLDP capable, but non-autonomic capable L2 switch to another
autonomic device, then the non-autonomic L2 switch would not
propagate the LLDP messages, so discovery would not work as desired.
Existing L3/L4 link local discovery mechanisms such as mDNS or Web-
Services Discovery (http://specs.xmlsoap.org/ws/2005/04/discovery/ws-
discovery.pdf) are capable to support the simple discovery required
by autonomic devices but have the following downsides compared to
GRASP.
There is no clear single ubiquitoous protocol that would apply
equally well to all market segments in which autonomic routers are
intended to be deployed. Making a choice is therefore difficult.
In some of these protocols, the fact that they operate L3 link local
is often seen as a limitation rather than as a necessity for the
application.
Various mechanisms are used or considered in these protocols to
expand the scope of discovery beyond a single L3 subnet. If
autonomic devices would use such a protocol, then autonomic discovery
messages could more likely leak into remote networks and give more
undesired (insecured) visibility into the presence of autonomic
devices and potentially leading to more attempts to establish
autonomic associations with those discovered devices. To achieve the
maximum resilience with the minimum number of ACP channels, those
channels need to follow as closely the physcial hops in the topology
as possible.
Visibility of discovery protocols in other domains may be
undesirable: Visibility of mDNS messages for example could extend all
the way into end user application level service browsers. It is
undesirable to see desvices announcing themselves as automic there.
Existing protocols can be more complex compared to GRASP as they have
been designed for different purposes, for example to be more flexible
and generic. In mDNS, if DNS-SD was used, it would require at least
four RRs to be exchanged for a single service: a PTR, a SRV, a TXT
and a AAAA RR. Minimizing the number of protocol exchanges by
coalescing these RRs is possible but requires additional software
design considerations.
GRASP is already required inside the ACP and a highly desirable
option for secure ACP channel negotiation (GRASP/TLS). Using it for
discovery allows to reuse that already necessary code basis. If any
other protocol was used for discovery, then autonomic discovery might
be the only purpose for which the protocol code exists in the device.
None of the above arguments individually are strong reasons not to
use one of these GRASP alternatives, but together they make it
reasonable to first define GRASP as the MTI (Mandatory To Implement)
for the discovery step.
11. Security Considerations
An ACP is self-protecting and there is no need to apply configuration An ACP is self-protecting and there is no need to apply configuration
to make it secure. Its security therefore does not depend on to make it secure. Its security therefore does not depend on
configuration. configuration.
However, the security of the ACP depends on a number of other However, the security of the ACP depends on a number of other
factors: factors:
o The usage of domain certificates depends on a valid supporting PKI o The usage of domain certificates depends on a valid supporting PKI
infrastructure. If the chain of trust of this PKI infrastructure infrastructure. If the chain of trust of this PKI infrastructure
skipping to change at page 25, line 11 skipping to change at page 25, line 34
o Security can be compromised by implementation errors (bugs), as in o Security can be compromised by implementation errors (bugs), as in
all products. all products.
Fundamentally, security depends on correct operation, implementation Fundamentally, security depends on correct operation, implementation
and architecture. Autonomic approaches such as the ACP largely and architecture. Autonomic approaches such as the ACP largely
eliminate the dependency on correct operation; implementation and eliminate the dependency on correct operation; implementation and
architectural mistakes are still possible, as in all networking architectural mistakes are still possible, as in all networking
technologies. technologies.
12. IANA Considerations 11. IANA Considerations
Section 5.5.3 describes ACP over dTLS, which requires a well-known Section 5.5.3 describes ACP over dTLS, which requires a well-known
UDP port. We request IANA to assign this UDP port for 'ACP over UDP port. We request IANA to assign this UDP port for 'ACP over
dTLS'. dTLS'.
Section 5.5.4 describes an option for the channel negotiation, the Section 5.5.4 describes an option for the channel negotiation, the
'ACP channel type'. We request IANA to create a registry for 'ACP 'ACP channel type'. We request IANA to create a registry for 'ACP
channel type'. channel type'.
The ACP channel type is a 8-bit unsigned integer. This document only The ACP channel type is a 8-bit unsigned integer. This document only
skipping to change at page 25, line 35 skipping to change at page 26, line 10
---------+-----------------------------------+------------ ---------+-----------------------------------+------------
0 | GRE tunnel protected with | this document 0 | GRE tunnel protected with | this document
| IPsec transport mode | | IPsec transport mode |
1-255 | reserved for future channel types | 1-255 | reserved for future channel types |
Section 5.8.2 describes a 'type' field in the base addressing scheme. Section 5.8.2 describes a 'type' field in the base addressing scheme.
We request IANA to create a registry for the 'ACP addressing scheme We request IANA to create a registry for the 'ACP addressing scheme
type'. The initial value and definition will be determined in a type'. The initial value and definition will be determined in a
later version of this document. later version of this document.
13. Acknowledgements 12. Acknowledgements
This work originated from an Autonomic Networking project at Cisco This work originated from an Autonomic Networking project at Cisco
Systems, which started in early 2010. Many people contributed to Systems, which started in early 2010. Many people contributed to
this project and the idea of the Autonomic Control Plane, amongst this project and the idea of the Autonomic Control Plane, amongst
which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji
BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Ravi BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Ravi
Kumar Vadapalli. Kumar Vadapalli.
Further input and suggestions were received from: Rene Struik, Brian Further input and suggestions were received from: Rene Struik, Brian
Carpenter, Benoit Claise. Carpenter, Benoit Claise.
14. Change log [RFC Editor: Please remove] 13. Change log [RFC Editor: Please remove]
14.1. Initial version
13.1. Initial version
First version of this document: draft-behringer-autonomic-control- First version of this document: draft-behringer-autonomic-control-
plane plane
14.2. draft-behringer-anima-autonomic-control-plane-00 13.2. draft-behringer-anima-autonomic-control-plane-00
Initial version of the anima document; only minor edits. Initial version of the anima document; only minor edits.
14.3. draft-behringer-anima-autonomic-control-plane-01 13.3. draft-behringer-anima-autonomic-control-plane-01
o Clarified that the ACP should be based on, and support only IPv6. o Clarified that the ACP should be based on, and support only IPv6.
o Clarified in intro that ACP is for both, between devices, as well o Clarified in intro that ACP is for both, between devices, as well
as for access from a central entity, such as an NMS. as for access from a central entity, such as an NMS.
o Added a section on how to connect an NMS system. o Added a section on how to connect an NMS system.
o Clarified the hop-by-hop crypto nature of the ACP. o Clarified the hop-by-hop crypto nature of the ACP.
o Added several references to GDNP as a candidate protocol. o Added several references to GDNP as a candidate protocol.
o Added a discussion on network split and merge. Although, this o Added a discussion on network split and merge. Although, this
should probably go into the certificate management story longer should probably go into the certificate management story longer
term. term.
14.4. draft-behringer-anima-autonomic-control-plane-02 13.4. draft-behringer-anima-autonomic-control-plane-02
Addresses (numerous) comments from Brian Carpenter. See mailing list Addresses (numerous) comments from Brian Carpenter. See mailing list
for details. The most important changes are: for details. The most important changes are:
o Introduced a new section "overview", to ease the understanding of o Introduced a new section "overview", to ease the understanding of
the approach. the approach.
o Merged the previous "problem statement" and "use case" sections o Merged the previous "problem statement" and "use case" sections
into a mostly re-written "use cases" section, since they were into a mostly re-written "use cases" section, since they were
overlapping. overlapping.
o Clarified the relationship with draft-eckert-anima-stable- o Clarified the relationship with draft-ietf-anima-stable-
connectivity connectivity
14.5. draft-behringer-anima-autonomic-control-plane-03 13.5. draft-behringer-anima-autonomic-control-plane-03
o Took out requirement for IPv6 --> that's in the reference doc. o Took out requirement for IPv6 --> that's in the reference doc.
o Added requirement section. o Added requirement section.
o Changed focus: more focus on autonomic functions, not only virtual o Changed focus: more focus on autonomic functions, not only virtual
out of band. This goes a bit throughout the document, starting out of band. This goes a bit throughout the document, starting
with a changed abstract and intro. with a changed abstract and intro.
14.6. draft-ietf-anima-autonomic-control-plane-00 13.6. draft-ietf-anima-autonomic-control-plane-00
No changes; re-submitted as WG document. No changes; re-submitted as WG document.
14.7. draft-ietf-anima-autonomic-control-plane-01 13.7. draft-ietf-anima-autonomic-control-plane-01
o Added some paragraphs in addressing section on "why IPv6 only", to o Added some paragraphs in addressing section on "why IPv6 only", to
reflect the discussion on the list. reflect the discussion on the list.
o Moved the data-plane ACP out of the main document, into an o Moved the data-plane ACP out of the main document, into an
appendix. The focus is now the virtually separated ACP, since it appendix. The focus is now the virtually separated ACP, since it
has significant advantages, and isn't much harder to do. has significant advantages, and isn't much harder to do.
o Changed the self-creation algorithm: Part of the initial steps go o Changed the self-creation algorithm: Part of the initial steps go
into the reference document. This document now assumes an into the reference document. This document now assumes an
skipping to change at page 28, line 5 skipping to change at page 28, line 23
o Introduce a section for the capability negotiation protocol o Introduce a section for the capability negotiation protocol
(section 7). This needs to be worked out in more detail. This (section 7). This needs to be worked out in more detail. This
will likely be based on GRASP. will likely be based on GRASP.
o Introduce a new parameter: ACP tunnel type. And defines it in the o Introduce a new parameter: ACP tunnel type. And defines it in the
IANA considerations section. Suggest GRE protected with IPSec IANA considerations section. Suggest GRE protected with IPSec
transport mode as the default tunnel type. transport mode as the default tunnel type.
o Updated links, lots of small edits. o Updated links, lots of small edits.
14.8. draft-ietf-anima-autonomic-control-plane-02 13.8. draft-ietf-anima-autonomic-control-plane-02
o Added explicitly text for the ACP channel negotiation. o Added explicitly text for the ACP channel negotiation.
o Merged draft-behringer-anima-autonomic-addressing-02 into this o Merged draft-behringer-anima-autonomic-addressing-02 into this
document, as suggested by WG chairs. document, as suggested by WG chairs.
14.9. draft-ietf-anima-autonomic-control-plane-03 13.9. draft-ietf-anima-autonomic-control-plane-03
o Changed Neighbor discovery protocol from GRASP to mDNS. Bootstrap o Changed Neighbor discovery protocol from GRASP to mDNS. Bootstrap
protocol team decided to go with mDNS to discover bootstrap proxy, protocol team decided to go with mDNS to discover bootstrap proxy,
and ACP should be consistent with this. Reasons to go with mDNS and ACP should be consistent with this. Reasons to go with mDNS
in bootstrap were a) Bootstrap should be reuseable also outside of in bootstrap were a) Bootstrap should be reuseable also outside of
full anima solutions and introduce as few as possible new full anima solutions and introduce as few as possible new
elements. mDNS was considered well-known and very-likely even pre- elements. mDNS was considered well-known and very-likely even pre-
existing in low-end devices (IoT). b) Using GRASP both for the existing in low-end devices (IoT). b) Using GRASP both for the
insecure neighbor discovery and secure ACP operatations raises the insecure neighbor discovery and secure ACP operatations raises the
risk of introducing security issues through implementation issues/ risk of introducing security issues through implementation issues/
skipping to change at page 28, line 44 skipping to change at page 29, line 13
planned, and the paragraph in the main text referring to it. planned, and the paragraph in the main text referring to it.
o Deleted one sub-addressing scheme, focusing on a single scheme o Deleted one sub-addressing scheme, focusing on a single scheme
now. now.
o Included information on how ANIMA information must be encoded in o Included information on how ANIMA information must be encoded in
the domain certificate in Section 5.1. the domain certificate in Section 5.1.
o Editorial changes, updated draft references, etc. o Editorial changes, updated draft references, etc.
15. References 13.10. draft-ietf-anima-autonomic-control-plane-04
[I-D.eckert-anima-stable-connectivity] Changed discovery of ACP neighbor back from mDNS to GRASP after
Eckert, T. and M. Behringer, "Using Autonomic Control revisiting the L2 problem. Described problem in discovery section
Plane for Stable Connectivity of Network OAM", draft- itself to justify. Added text to explain how ACP discovery relates
eckert-anima-stable-connectivity-02 (work in progress), to BRSKY (bootstrap) discovery and pointed to Michael Richardsons
October 2015. draft detailing it. Removed appendix section that contained the
original explanations why GRASP would be usedul (current text is
meant to be better).
14. References
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., and S. Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
Bjarnason, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-03 (work in progress), June 2016. keyinfra-04 (work in progress), October 2016.
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, D., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-06 (work in progress), June 2016. grasp-08 (work in progress), October 2016.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A
Reference Model for Autonomic Networking", draft-ietf- Reference Model for Autonomic Networking", draft-ietf-
anima-reference-model-02 (work in progress), July 2016. anima-reference-model-02 (work in progress), July 2016.
[I-D.ietf-anima-stable-connectivity]
Eckert, T. and M. Behringer, "Using Autonomic Control
Plane for Stable Connectivity of Network OAM", draft-ietf-
anima-stable-connectivity-01 (work in progress), July
2016.
[I-D.richardson-anima-6join-discovery]
Richardson, M., "GRASP discovery of Registrar by Join
Assistant", draft-richardson-anima-6join-discovery-00
(work in progress), October 2016.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<http://www.rfc-editor.org/info/rfc4122>. <http://www.rfc-editor.org/info/rfc4122>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>. <http://www.rfc-editor.org/info/rfc4193>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
skipping to change at page 32, line 20 skipping to change at page 32, line 50
Michael H. Behringer (editor) Michael H. Behringer (editor)
Cisco Systems Cisco Systems
Building D, 45 Allee des Ormes Building D, 45 Allee des Ormes
Mougins 06250 Mougins 06250
France France
Email: mbehring@cisco.com Email: mbehring@cisco.com
Toerless Eckert Toerless Eckert
Cisco Systems
Email: eckert@cisco.com
Email: tte+ietf@cs.fau.de
Steinthor Bjarnason Steinthor Bjarnason
Arbor Networks Arbor Networks
2727 South State Street, Suite 200 2727 South State Street, Suite 200
Ann Arbor MI 48104 Ann Arbor MI 48104
United States United States
Email: sbjarnason@arbor.net Email: sbjarnason@arbor.net
 End of changes. 48 change blocks. 
201 lines changed or deleted 220 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/