draft-ietf-anima-stable-connectivity-08.txt   draft-ietf-anima-stable-connectivity-09.txt 
ANIMA T. Eckert, Ed. ANIMA T. Eckert, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational M. Behringer Intended status: Informational M. Behringer
Expires: July 20, 2018 January 16, 2018 Expires: July 30, 2018 January 26, 2018
Using Autonomic Control Plane for Stable Connectivity of Network OAM Using Autonomic Control Plane for Stable Connectivity of Network OAM
draft-ietf-anima-stable-connectivity-08 draft-ietf-anima-stable-connectivity-09
Abstract Abstract
OAM (Operations, Administration and Maintenance - as per BCP161, OAM (Operations, Administration and Maintenance - as per BCP161,
(RFC6291) processes for data networks are often subject to the (RFC6291) processes for data networks are often subject to the
problem of circular dependencies when relying on connectivity problem of circular dependencies when relying on connectivity
provided by the network to be managed for the OAM purposes. provided by the network to be managed for the OAM purposes.
Provisioning while bringing up devices and networks tends to be more Provisioning while bringing up devices and networks tends to be more
difficult to automate than service provisioning later on, changes in difficult to automate than service provisioning later on, changes in
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 July 20, 2018. This Internet-Draft will expire on July 30, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 35 skipping to change at page 2, line 35
1.3. Leveraging a generalized autonomic control plane . . . . 4 1.3. Leveraging a generalized autonomic control plane . . . . 4
2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Stable Connectivity for Centralized OAM . . . . . . . . . 5 2.1. Stable Connectivity for Centralized OAM . . . . . . . . . 5
2.1.1. Simple Connectivity for Non-GACP capable NMS Hosts . 6 2.1.1. Simple Connectivity for Non-GACP capable NMS Hosts . 6
2.1.2. Challenges and Limitation of Simple Connectivity . . 7 2.1.2. Challenges and Limitation of Simple Connectivity . . 7
2.1.3. Simultaneous GACP and data-plane Connectivity . . . . 8 2.1.3. Simultaneous GACP and data-plane Connectivity . . . . 8
2.1.4. IPv4-only NMS Hosts . . . . . . . . . . . . . . . . . 9 2.1.4. IPv4-only NMS Hosts . . . . . . . . . . . . . . . . . 9
2.1.5. Path Selection Policies . . . . . . . . . . . . . . . 12 2.1.5. Path Selection Policies . . . . . . . . . . . . . . . 12
2.1.6. Autonomic NOC Device/Applications . . . . . . . . . . 14 2.1.6. Autonomic NOC Device/Applications . . . . . . . . . . 14
2.1.7. Encryption of data-plane connections . . . . . . . . 15 2.1.7. Encryption of data-plane connections . . . . . . . . 15
2.1.8. Long Term Direction of the Solution . . . . . . . . . 15 2.1.8. Long Term Direction of the Solution . . . . . . . . . 16
2.2. Stable Connectivity for Distributed Network/OAM . . . . . 16 2.2. Stable Connectivity for Distributed Network/OAM . . . . . 16
3. Architectural Considerations . . . . . . . . . . . . . . . . 16 3. Architectural Considerations . . . . . . . . . . . . . . . . 17
3.1. No IPv4 for GACP . . . . . . . . . . . . . . . . . . . . 16 3.1. No IPv4 for GACP . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 19 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
1.1. Self-dependent OAM Connectivity 1.1. Self-dependent OAM Connectivity
OAM (Operations, Administration and Maintenance - as per BCP161, OAM (Operations, Administration and Maintenance - as per BCP161,
[RFC6291]) for data networks is often subject to the problem of [RFC6291]) for data networks is often subject to the problem of
circular dependencies when relying on the connectivity service circular dependencies when relying on the connectivity service
provided by the network to be managed. OAM can easily but provided by the network to be managed. OAM can easily but
unintentionally break the connectivity required for its own unintentionally break the connectivity required for its own
operations. Avoiding these problems can lead to complexity in OAM. operations. Avoiding these problems can lead to complexity in OAM.
skipping to change at page 14, line 7 skipping to change at page 14, line 7
data-plane address. A data-plane subflow is built. Once this is data-plane address. A data-plane subflow is built. Once this is
successful, the peers declare the GACP subflow to be a backup flow successful, the peers declare the GACP subflow to be a backup flow
and only the data-plane subflow is used to carry traffic. and only the data-plane subflow is used to carry traffic.
Making this idea work requires additional specification work outside Making this idea work requires additional specification work outside
the scope of this document. This includes but is not necessarily the scope of this document. This includes but is not necessarily
limited to defining the following aspects: limited to defining the following aspects:
The above described behavior/policy for MPTCP must be controllable by The above described behavior/policy for MPTCP must be controllable by
applications or libraries acting on behalf of applications. APIs applications or libraries acting on behalf of applications. APIs
and/or data models for this control need to be defined. As outlined and/or data models for this control need to be defined. It should be
above, applications for example may choose to only perform transfers sufficient to make these policies work on a per connection basis, and
if the data-plane is actually available because of performance not change during the lifetime of a connection for different data
limitations of the GACP, so the application needs to be made aware if items:
the setup of the data-plane subflow fails. Or transfers may want to
only use the GACP because the connection performs configuration
changes that are likely known to bring down the data-plane. It
should be sufficient to make these policies work on a per connection
basis, and not change during the lifetime of a connection for
different data items.
GACP and data-plane addresses exist in different VRFs. The MPTCP 1. The policy for likely most connections would be to use the data-
stack needs to be able to access multiple VRFs and know which local plane subflow and fall back using the ACP subflow when the data-
address is existing in which VRF. There also needs to be a logic to plane fails. This could be the default. It reduces load on the
ACP but would continue to run connection traffic at likely
reduced throughput when the data-plane fails. Ideally such
connections would also revert back to using a data-plane subflow
once its connectivity recovers.
2. Connections for non-urgent bulk transers (for example most
routine firmware updates or cached log collection) may use a
policy where the connection is made to fail when the data-plane
fails or have transfers suspend until another data-plane subflow
can successfully be built. This avoids over-taxing the ACP when
the data plane fails.
3. Connections for critical network configuration change operations
known to impact the data-plane might want to only use the ACP and
could therefore map to a (non-MP)TCP connection.
GACP and data-plane addresses exist in different VRFs. The endpoint
needs to be able to access multiple VRFs and know which local address
is existing in which VRF. There also needs to be a logic to
determine which peer address is expected to be reachable via which determine which peer address is expected to be reachable via which
local VRF/address. Because the GACP is an isolated network, data- local VRF/address. Because the GACP is an isolated network, data-
plane addresses are not reachable via the GACP therefore devices can plane addresses are not reachable via the GACP therefore devices can
determine if a peer address is a data-plane address. determine if a peer address is a data-plane address.
2.1.6. Autonomic NOC Device/Applications 2.1.6. Autonomic NOC Device/Applications
Setting up connectivity between the NOC and autonomic devices when Setting up connectivity between the NOC and autonomic devices when
the NOC device itself is non-autonomic is as mentioned in the the NOC device itself is non-autonomic is as mentioned in the
beginning a security issue. It also results as shown in the previous beginning a security issue. It also results as shown in the previous
skipping to change at page 19, line 34 skipping to change at page 19, line 49
the design and early testing. Many people contributed to the aspects the design and early testing. Many people contributed to the aspects
described in this document, including in alphabetical order: BL described in this document, including in alphabetical order: BL
Balaji, Steinthor Bjarnason, Yves Herthoghs, Sebastian Meissner, Ravi Balaji, Steinthor Bjarnason, Yves Herthoghs, Sebastian Meissner, Ravi
Kumar Vadapalli. The author would also like to thank Michael Kumar Vadapalli. The author would also like to thank Michael
Richardson, James Woodyatt and Brian Carpenter for their review and Richardson, James Woodyatt and Brian Carpenter for their review and
comments. Special thanks to Sheng Jiang and Mohamed Boucadair for comments. Special thanks to Sheng Jiang and Mohamed Boucadair for
their thorough review. their thorough review.
7. Change log [RFC Editor: Please remove] 7. Change log [RFC Editor: Please remove]
09: Mirja/Yoshifumi: reworded MPTCP policy rule examples,
stack->endpoint (agnostic to where policy is implemented).
08: IESG review fixes. 08: IESG review fixes.
* Spell check. * Spell check.
* https://raw.githubusercontent.com/anima-wg/autonomic-control- * https://raw.githubusercontent.com/anima-wg/autonomic-control-
plane/01908364cfc7259009603bf2b261354b0cc26913/draft-ietf- plane/01908364cfc7259009603bf2b261354b0cc26913/draft-ietf-
anima-stable-connectivity/draft-ietf-anima-stable-connectivity- anima-stable-connectivity/draft-ietf-anima-stable-connectivity-
08.txt 08.txt
* Eric Rescorla (comments):Typos, listing ULA on internet * Eric Rescorla (comments):Typos, listing ULA on internet
 End of changes. 9 change blocks. 
20 lines changed or deleted 36 lines changed or added

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