draft-ietf-anima-stable-connectivity-09.txt   draft-ietf-anima-stable-connectivity-10.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 30, 2018 January 26, 2018 Expires: August 9, 2018 February 5, 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-09 draft-ietf-anima-stable-connectivity-10
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 30, 2018. This Internet-Draft will expire on August 9, 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 33 skipping to change at page 2, line 33
1.1. Self-dependent OAM Connectivity . . . . . . . . . . . . . 3 1.1. Self-dependent OAM Connectivity . . . . . . . . . . . . . 3
1.2. Data Communication Networks (DCNs) . . . . . . . . . . . 3 1.2. Data Communication Networks (DCNs) . . . . . . . . . . . 3
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 . . . . . . . . . . 15
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 . . . . . . . . . 16 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 . . . . . 17
3. Architectural Considerations . . . . . . . . . . . . . . . . 17 3. Architectural Considerations . . . . . . . . . . . . . . . . 17
3.1. No IPv4 for GACP . . . . . . . . . . . . . . . . . . . . 17 3.1. No IPv4 for GACP . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 19 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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
skipping to change at page 13, line 30 skipping to change at page 13, line 30
may stall/fail when there are connectivity issues. One name (name- may stall/fail when there are connectivity issues. One name (name-
acp.noc.example.com) with only the GACP reachable address of the acp.noc.example.com) with only the GACP reachable address of the
device for troubleshooting and probing/discovery that is desired to device for troubleshooting and probing/discovery that is desired to
always only use the GACP. One name with data-plane and GACP always only use the GACP. One name with data-plane and GACP
addresses (name-both.noc.example.com). addresses (name-both.noc.example.com).
Traffic policing and/or shaping at the GACP edge in the NOC can be Traffic policing and/or shaping at the GACP edge in the NOC can be
used to throttle applications such as software download into the used to throttle applications such as software download into the
GACP. GACP.
MPTCP (Multipath TCP -see [RFC6824]) with additional future work Using different names mapping to different (subset of) addresses can
could be a very attractive candidate to automate the use of both be difficult to set up and maintain, especially also because data-
data-plane and GACP and minimize or fully avoid the need for the plane addresses may change due to reconfiguration or relocation of
above mentioned logical names to pre-set the desired connectivity devices. The name based approach alone can also not well support
(data-plane-only, GACP only, both). policies for existing applications and long-lived flows to
automatically switch between ACP and data-plane in the face of data-
plane failure and recovery. A solution would be GACP node host
transport stacks supporting the following requirements:
MPTCP supports signaling between the peers with which additional 1. Only the GACP addresses of the responder must be required by the
available addresses can be exchanged and then additional subflows initiator for the initial setup of a connection/flow across the
between those addresses can be built. MPTCP also allows to declare GACP.
subflows to be backup so they do not carry traffic unless non-backup
subflows fail. Taken together, this could be used to automatically
leverage the stable connectivity of the GACP and the potentially
higher throughput of the data plane and simplify the DNS setup:
(Only) the GACP address of GACP devices could to be put into DNS. 2. Responder and Initiator must be able to exchange their data-plane
When MPTCP builds the first subflow across the GACP, it exchanges the addresses through the GACP, and then - if needed by policy -
data-plane address. A data-plane subflow is built. Once this is build an additional flow across the data-plane.
successful, the peers declare the GACP subflow to be a backup flow
and only the data-plane subflow is used to carry traffic.
Making this idea work requires additional specification work outside 3. For unmodified application, the following policies should be
the scope of this document. This includes but is not necessarily configurable on at least a per-application basis for its TCP
limited to defining the following aspects: connections with GACP peers:
The above described behavior/policy for MPTCP must be controllable by Fallback (to GACP): An additional data-plane flow is built and
applications or libraries acting on behalf of applications. APIs used exclusively to send data whenever the data-plane is
and/or data models for this control need to be defined. It should be operational. When it can not be built during connection setup
sufficient to make these policies work on a per connection basis, and or when it fails later, traffic is sent across the GACP flow.
not change during the lifetime of a connection for different data This could be a default-policy for most OAM applications using
items: the GACP.
1. The policy for likely most connections would be to use the data- >Suspend/Fail: Like the Fallback policy, except that traffic
plane subflow and fall back using the ACP subflow when the data- will not use the GACP flow but will be suspended until a data-
plane fails. This could be the default. It reduces load on the plane flow is operational or until a policy configurable
ACP but would continue to run connection traffic at likely timeout indicates a connection failure to the application.
reduced throughput when the data-plane fails. Ideally such This policy would be appropriate for large volume background/
connections would also revert back to using a data-plane subflow scavenger class OAM application/connections such as firmware
once its connectivity recovers. downloads or telemetry/diagnostic uploads - which would
otherwise easily overrun performance limited GACP
implementations.
2. Connections for non-urgent bulk transers (for example most >GACP (only): No additional data-plane flow is built, traffic is
routine firmware updates or cached log collection) may use a only sent via the GACP flow. This can just be a TCP
policy where the connection is made to fail when the data-plane connection. This policy would be most appropriate for OAM
fails or have transfers suspend until another data-plane subflow operations known to change the data plane in a way that could
can successfully be built. This avoids over-taxing the ACP when impact (at least temporarily) connectivity through it.
the data plane fails.
3. Connections for critical network configuration change operations 4. In the presence of responders or initiators not supporting these
known to impact the data-plane might want to only use the ACP and host stack functions, the Fallback and GACP policies must result
could therefore map to a (non-MP)TCP connection. in a TCP connection across the GACP. For Suspend/Fail, presence
of TCP-only peers should result in failure during connection
setup.
GACP and data-plane addresses exist in different VRFs. The endpoint 5. In case of Fallback and Suspend/Fail, a failed data-plane
needs to be able to access multiple VRFs and know which local address connection should automatically be rebuilt when the data-plane
is existing in which VRF. There also needs to be a logic to recovers, including the case that the data-plane address of one
determine which peer address is expected to be reachable via which (or both) side(s) may have changed - for example because of
local VRF/address. Because the GACP is an isolated network, data- reconfiguration or device repositioning.
plane addresses are not reachable via the GACP therefore devices can
determine if a peer address is a data-plane address. 6. Additional data-plane flows created by these host transport stack
functions must be end-to-end authenticated by it with the GACP
domain credentials and encrypted. This maintains the expectation
that connections from GACP addresses to GACP addresses are
authenticated/encrypted. This may be skipped if the application
already provides for end-to-end encryption.
7. For enhanced applications, the host stack may support application
control to select the policy on a per-connection basis, or even
more explicit control for building of the flows and which flow
should pass traffic.
Protocols like MPTCP (Multipath TCP -see [RFC6824]) and SCTP
([RFC4960]) can already support part of these requirements. MPTCP
for example supports signaling of addresses in a TCP backward
compatible fashion, establishment of additional flows (called
subflows in MPTCP) and having primary and fallback subflows via
MP_PRIO signalling. The details if or how MPTCP, SCTP and/or other
approaches potentially with extensions and/or (shim) layers on top of
them can best provide a complete solution for the above requirements
is subject to further work outside the scope of this document.
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
paragraphs in a range of connectivity considerations, some of which paragraphs in a range of connectivity considerations, some of which
may be quite undesirable or complex to operationalize. may be quite undesirable or complex to operationalize.
Making NMS hosts autonomic and having them participate in the GACP is Making NMS hosts autonomic and having them participate in the GACP is
skipping to change at page 16, line 26 skipping to change at page 16, line 44
1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the 1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the
network to enable use of a GACP is long term undesirable. Having network to enable use of a GACP is long term undesirable. Having
IPv4 only applications automatically leverage IPv6 connectivity IPv4 only applications automatically leverage IPv6 connectivity
via host-stack translation may be an option but this has not been via host-stack translation may be an option but this has not been
investigated yet. investigated yet.
2. Build the GACP as a lightweight application for NMS hosts so GACP 2. Build the GACP as a lightweight application for NMS hosts so GACP
extends all the way into the actual NMS hosts. extends all the way into the actual NMS hosts.
3. Leverage and as necessary enhance MPTCP with automatic dual- 3. Leverage and as necessary enhance host transport stacks with
connectivity: If an MPTCP unaware application is using GACP automatic multipath-connectivity GACP and data-plane as outlined
connectivity, the policies used should add subflow(s) via the in Section 2.1.5.
data-plane and prefer them.
4. Consider how to best map NMS host desires to underlying transport 4. Consider how to best map NMS host desires to underlying transport
mechanisms: With the above mentioned 3 points, not all options mechanisms: With the above mentioned 3 points, not all options
are covered. Depending on the OAM, one may still want only GACP, are covered. Depending on the OAM, one may still want only GACP,
only data-plane, or automatically prefer one over the other and/ only data-plane, or automatically prefer one over the other and/
or use the GACP with low performance or high-performance (for or use the GACP with low performance or high-performance (for
emergency OAM such as countering DDoS). It is as of today not emergency OAM such as countering DDoS). It is as of today not
clear what the simplest set of tools is to enable explicitly the clear what the simplest set of tools is to enable explicitly the
choice of desired behavior of each OAM. The use of the above choice of desired behavior of each OAM. The use of the above
mentioned DNS and MPTCP mechanisms is a start, but this will mentioned DNS and multipath mechanisms is a start, but this will
require additional thoughts. This is likely a specific case of require additional work. This is likely a specific case of the
the more generic scope of TAPS. more generic scope of TAPS.
2.2. Stable Connectivity for Distributed Network/OAM 2.2. Stable Connectivity for Distributed Network/OAM
Today, many distributed protocols implement their own unique security Today, many distributed protocols implement their own unique security
mechanisms. mechanisms.
KARP (Keying and Authentication for Routing Protocols, see [RFC6518]) KARP (Keying and Authentication for Routing Protocols, see [RFC6518])
has tried to start to provide common directions and therefore reduce has tried to start to provide common directions and therefore reduce
the re-invention of at least some of the security aspects, but it the re-invention of at least some of the security aspects, but it
only covers routing-protocols and it is unclear how well it is only covers routing-protocols and it is unclear how well it is
skipping to change at page 19, line 49 skipping to change at page 20, line 23
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]
10: Added paragraph to multipath text to better summarize the
reason why to do this.
10: Mirja: reworded multipath text to remove instructive
description how the desired functionality would map to MPTCP
features, extensions or shim layers. Describe the desired
functionality now only as requirements. Expert WGs including but
not limited to MPTCP and future documents need to define best
design/spec option.
10: BrianC: Added requirement to 'MPTCP' section for end-to-end
encryption across data plane when connection is via GACP.
09: Mirja/Yoshifumi: reworded MPTCP policy rule examples, 09: Mirja/Yoshifumi: reworded MPTCP policy rule examples,
stack->endpoint (agnostic to where policy is implemented). 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-
skipping to change at page 24, line 28 skipping to change at page 25, line 9
ITU-T Recommendation G.7712/Y.1703, Noevember 2001. ITU-T Recommendation G.7712/Y.1703, Noevember 2001.
This is the earliest but superceeded version of the This is the earliest but superceeded version of the
series. See "https://www.itu.int/rec/T-REC-G.7712/en" for series. See "https://www.itu.int/rec/T-REC-G.7712/en" for
current versions. current versions.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>. April 2011, <https://www.rfc-editor.org/info/rfc6146>.
 End of changes. 19 change blocks. 
68 lines changed or deleted 104 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/