| RTG Working Group | A. Clemm |
| Internet-Draft | P. Pillay-Esnault |
| Intended status: Standards Track | U. Chunduri |
| Expires: January 9, 2020 | Futurewei |
| July 8, 2019 |
Preferred Path Routing (PPR) OAM and Accounting
draft-cpc-rtgwg-ppr-oam-00
This document defines OAM and traffic accounting capabilities for Preferred Path Routing (PPR) for IS-IS and OSPF protocols. Specifically, this document specifies OAM capabilities that allow to assert proper PPR connectivity and to trace PPR path information. In addition, a set of statistics and operational data to facilitate PPR traffic accounting on a per-PPR path basis are defined. This includes a number of Information Elements that extend IPFIX to export path information, as well as a YANG Data Model to be used in conjunction with management and control protocols. Collectively the capabilities defined in this document provide network operators with the necessary means to ensure proper working of their PPR deployments.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119, RFC8174 when, and only when they appear in all capitals, as shown here.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Preferred Path Routing (PPR) allows to route packets along a custom path on the basis of a path identifier (PPR-ID) as opposed to individual segments in the packet. Interior Gateway Protocols (IGPs) nodes compute nexthops based on the path description for the prefix and take proper forwarding actions for the paths that they are a part of. PPR may be used with different data planes, e.g. IPv4, IPv6, MPLS, SRv6. Dissemination and nexthop computation of path information is described in [I-D.chunduri-lsr-isis-preferred-path-routing] and [I-D.chunduri-lsr-ospf-preferred-path-routing].
In order to operate, administer, and maintain PPR deployments, network operators must be given tools that allow them to ensure that PPR is working as expected and that allow them to troubleshoot any potential problems. This includes assessing whether remote destinations can indeed be reached as intended using a given preferred path, and to verify path elements along the path being taken. Traditionally, ping (ICMP echo request on IP networks, LSP ping in MPLS networks) and traceroute operations are used for those purposes. In order to facilitate operation of PPR, analogous capabilities with PPR-specific extensions are useful which are defined in this document.
In addition, for purposes of traffic accounting and ongoing operations, it can be very useful to maintain certain PPR statistics. This allows, for example, to assess times and volume when traffic over preferred paths is occurring. This document defines new PPR path attributes as defined in Section 5 and this can be optionally signaled for the preferred paths selectively to account for the traffic on every path segment (where critical SLAs are needed). IPFIX is commonly used to maintain and export flow-specific information from any node in the network. This document introduces a number of new IPFIX Information Elements that are useful in conjunction with PPR.
Some of the same statistics maintained on a per-flow basis may be useful to maintain not just for the duration of a flow, but for the lifetime of the path. That information is considered part of regular management information and subject to specification as part of a YANG data model.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Ping and Trace capabilities depend on the underlying data plane being used for the PPR path. Different mechanisms exist for each of those data planes. As PPR support does not require any change in the existing dataplane, for each of those cases, existing ping and trace core mechanisms continue to work seamlessly without modification:
To manage PPR, network operators may require additional information that is specific to PPR. For example, PPR may be installed by different IGPs(OSPF/ISIS) and supports two types of paths:
The current mechanisms need to be enhanced to carry the PPR specific mechanism but otherwise it has minimal changes. In this section, a simple topology is shown in Figure 1 is used to illustrate the different traces of PPR paths described in the subsequent sub sections below.
1 __R9___R10__ 1
/ 1 \
R1-------R2 R3------R4
\_____R11____/
2 2
Figure 1. Topology example
PPR paths from topology
PPR-ID: (strict) -> R1, R2, R3, R11, R4
PPR-ID: (Loose) -> R1, R2, R3, R4
The section between R2-R3 is loose.
The best path is via R9 and 10. Path is R1, R2, (R9, R10), R3, R4
Node Node IPaddr SPF Cost to R3
R1 1.1.1.1
R2 2.2.2.2 costs via R9+R10=3, via R11=4
R3 3.3.3.3
R4 4.4.4.4
R9 9.9.9.9
R10 10.10.10.10
R11 11.11.11.11
The classic ping to a destination relying on the forwarding path works seamlessly as the PPR path is installed via IGPs. The PPR-ID is the same as the destination address/label in different dataplanes, therefore the existing ping mechanism remains unchanged in a network supporting PPR.
However, the traceroute output should display more PPR specific information such as whether or not the path from a node is loose or strict, or the source of the protocol that installed a PPR-ID or the dataplane information. In order to support PPR-specific trace information, a few additional capabilities are needed.
A PPR Trace is initiated from a node, using the PPR-ID as a parameter. The trace will then traverse the PPR path of the specified PPR-ID. In addition to the information that would be returned with a regular trace, PPR-specific information is returned from PPR nodes that are encountered along the path. For each PPR node, the following information is returned:
These PPR specific information will be carried in ICMP data. These extensions are TBD for the various dataplanes.
The PPR strict mode indicates the PPR path on a hop by hop basis. As the PPR-ID represents a strict path to be followed, the ingress node should increment the TTL for the PPR-ID until all the egress node has returned all individual intermediate segments completely traced.
The PPR specific enhancements additional information are returned as part of trace information. The strict path to be trace is PPR-ID=4.4.4.5 represents the path (R1, R2, R11, R3, R4). An example of the output for traceroute for PPR-IS in IPV4 dataplane is given below:
>traceroute 4.4.4.5
traceroute to 4.4.4.5 (192.4.4.5), 30 hops max, 40 byte packets
1 1.1.1.1 (192.1.1.1) 6.819 ms 1.370 ms 1.281 ms
PPR: ID:4.4.4.5 Mode=Strict Origin=IS-IS
2 2.2.2.2 (192.1.1.2) 4.437 ms 1.987 ms 2.335 ms
PPR: ID:4.4.4.5 Mode=Strict Origin=IS-IS
3 11.11.11.11 (192.11.11.11) 9.830 ms 11.696 ms 5.478 ms
PPR: ID:4.4.4.5 Mode=Strict Origin=IS-IS
4 3.3.3.3 (192.3.3.3) 9.448 ms 5.096 ms 7.518 ms
PPR: ID:4.4.4.5 Mode=Strict Origin=IS-IS
5 4.4.4.4 (192.3.3.4) 9.448 ms 5.096 ms 7.518 ms
PPR: ID:4.4.4.5 Mode=Strict Origin=IS-IS
Figure 2 Enhanced traceroute Output example
The output for IPv6 and MPLS traceroute should be augmented to display the PPR-ID specific parameters as shown above.
The PPR loose path functionality allows greater flexibility by letting the IGP calculate the best path on a loose section of the path described for PPR-ID. The traditional traceroute requires additional enhancement for the PPR trace to perform correctly . Per Figure 1, the loose path example is R1, R2,(R9, R10), R3, R4 where () represents the loose section of the path. An example of the output for traceroute for PPR-IS in IPV4 dataplane is given below:
>traceroute 4.4.4.5
traceroute to 4.4.4.5 (192.4.4.5), 30 hops max, 40 byte packets
1 1.1.1.1 (192.1.1.1) 6.819 ms 1.370 ms 1.281 ms
PPR: ID:4.4.4.5 Mode=Strict Origin=OSPF
2 2.2.2.2 (192.1.1.2) 4.437 ms 1.987 ms 2.335 ms
PPR: ID:4.4.4.5 Mode=Loose Origin=OSPF Multipaths=0
1 9.9.9.9 (192.9.9.9) 9.830 ms 11.696 ms 5.478 ms
PPR: ID:4.4.4.5 Mode=None Origin=OSPF
2 10.10.10.10 (192.9.9.10) 4.230 ms 4.633 ms 5.789 ms
PPR: ID:4.4.4.5 Mode=None Origin=OSPF
3 3.3.3.3 (192.3.3.3) 9.448 ms 5.096 ms 7.518 ms
PPR: ID:4.4.4.5 Mode=Strict Origin =OSPF
4 4.4.4.4 (192.3.3.4) 9.448 ms 5.096 ms 7.518 ms
PPR: ID:4.4.4.5 Mode=Strict Origin=OSPF
Figure 3 Enhanced traceroute Output example
The output for IPv6 and MPLS traceroute should be augmented to display the PPR-ID, Mode and Origin.
As the loose path functionality does not preclude the presence of equal cost multiple paths (ECMPs), the well documented limitations and solutions for classic traceroute applies here as well. For operational purposes, it might be of value to list all the multipaths. To acheive this the node just before the loose section MAY initiate a recursive traceroute to aggregate that information and send it with their ICMP Echo Reply message.
Traffic for certain PPRs may have more stringent requirement w.r.t accounting for critical SLAs (e.g. 5G non-eMBB slice) and should account for any link/node failures along the path. Presence of "Packet Traffic Accounting" and "Traffic Statistics" Sub-TLVs below in IGP PPR-TLV instructs all the respective nodes along the path to provision the hardware and to account for the respective traffic statistics. Traffic accounting should happen, when the actual data traffic hits for the PPR-ID in the forwarding plane. This capability allows more granular and dynamic enablement of traffic statistics for only certain PPRs as needed.
As instruction for creating and deleting the traffic accounting for PPRs happen through IGP message processing, respective IGP's control plane security (Section 10) options are applicable to the PPR-TLV and Sub-TLVs thereof.
PPR-Attribute Sub-TLVs describe the attributes of that particular path. The following path attribute Sub-TLVs are defined for respective IGP PPR-TLV [I-D.chunduri-lsr-isis-preferred-path-routing] and [I-D.chunduri-lsr-ospf-preferred-path-routing].
How the accumulated traffic accounting information is distributed to a central entity is out of scope of this document. One can use any method (e.g. RESTCONF, Yang PUSH, gRPC) to extract the PPR-ID traffic accounting information from various nodes along the path.
Network providers will appreciate the ability to collect certain statistics about PPR path usage, including how much traffic a PPR path carries and at what times from any node in the network. Such statistics can be useful to account for the degree of usage of a path and provide additional operational insights, including (for example) usage patterns and trending information.
One mechanism that is traditionally used to collect traffic statistics is IPFIX (IP Flow Information eXport [RFC7011]. IPFIX supports a very rich set of Information Elements containing various statistics, far more in fact than will be required for PPR path statistics. However, those statistics are collected only a per-flow basis.
In order to be able to collect statistics on a per-path basis, a set of new IPFIX Information Elements need to be defined that allow to capture a PPR-ID. In addition, these new IPFIX Information Elements need to be able to serve as a flow key. This allows separate IPFIX cache entries to be created on a per-path basis, and to export the corresponding records as IPFIX records. Of course, the records exported do not refer to flows but to paths - IPFIX thus becomes de-facto extended to become IPPIX - IP Path Information eXport.
Flow records that have a PPR-ID as flow key SHALL be terminated and exported in the following events and/or per configurable policy:
A flow record for path is created when a packet on a path is detected and no flow entry for that PPR-ID exists. I.e., flow records are not created and maintained for every PPR-ID that is known to the Network Element, only to PPR-IDs that are "active".
The following new IPFIX Information Elements need to be added:
Each of those fields need to be able to be supported as a flow key field.
The following statistics, as represented through corresponding Information Elements, will be of particular interest to export as part of IPFIX records with a PPR-ID as flow key:
Because a path's packets traverse every hop on the path, the observed path statistics are expected to generally be the same on every node across the path. Network providers may therefore choose to configure IPFIX path information export only on certain routers, for example at the network edge. That said, in certain circumstances it may make sense to export statistics from multiple nodes on a path and compare records for any discrepancies in order to diagnose or isolate operational anomalies (such as occurrence of packet loss).
In addition to exporting path flow statistics, network providers need to be able to retrieve operational information about PPR paths as a whole. This includes information about when a path was created, how it came into being, and statistics maintained over the entire lifetime of the path (i.e. since its creation). For this purpose, a YANG Data Model for PPR Monitoring is defined, "ppr-statistics". The model is depicted in the following tree diagram. The tree diagram follows the notation defined in [RFC8340]
module: ietf-ppr-statistics
+--ro ppr-stats
+--ro num-pprs? uint32
+--ro ppr* [ppr-id]
+--ro ppr-id ppr-id
+--ro ppr-creation-time? yang:date-and-time
+--ro loose-or-strict? ppr-path-type
+--ro ppr-origin? ppr-origin-proto
+--ro ppr-packets? uint64
+--ro ppr-dropped-packets? uint64
+--ro ppr-octets? uint64
+--ro ppr-active-flows? uint32
Figure 1: Tree diagram for establish-subscription-datastore-error-info
The data model contains the following:
<CODE BEGINS> file "ietf-ppr-statistics@2019-07-08.yang"
module ietf-ppr-statistics {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ppr-statistics";
prefix pprs;
import ietf-yang-types {
prefix yang;
}
import ietf-inet-types {
prefix inet;
}
organization "IETF";
contact
"WG Web: <http://tools.ietf.org/wg/rtgwg/>
WG List: <mailto:rtgwg@ietf.org>
Author: Alexander Clemm
<mailto:ludwig@clemm.org>
Author: Padma Pillay-Esnault
<mailto:padma@futurewei.com>
Author: Uma Chunduri
<mailto:uchundur@futurewei.com>";
description
"The YANG data model defines a set of statistics to be used for
managing PPR.";
revision 2019-07-08 {
description
"Initial revision";
reference
"RFC XXXX: Preferred Path Routing (PPR) OAM and Accounting";
}
typedef ppr-id {
type union {
type inet:ipv4-address;
type inet:ipv6-address;
type string {
length "4..32";
}
}
description
"Identifies a PPR. Depending on the type of PPR, a different
format is used.";
}
typedef ppr-origin-proto {
type string;
description
"Identifies the source of the PPR, i.e. how the PPR came into
being. Different values are TBD and the type itself is
subject to change.";
}
typedef ppr-path-type {
type enumeration {
enum loose {
description "Path type is loose";
}
enum strict {
description "Path type is strict";
}
}
description
"The type of PPR path - loose or strict.";
}
container ppr-stats {
config false;
description
"Top-level container for PPR statistics.";
leaf num-pprs {
type uint32;
description
"The number of currently active PPRs on the node.";
}
list ppr {
key "ppr-id";
description
"The list of currently active PPRs on the node.";
leaf ppr-id {
type ppr-id;
description
"The identifier of the PPR.";
}
leaf ppr-creation-time {
type yang:date-and-time;
description
"The precise time at which the PPR was created on the
node.";
}
leaf loose-or-strict {
type ppr-path-type;
description
"An indication whether the PPR is loose or strict.";
}
leaf ppr-origin {
type ppr-origin-proto;
description
"The way in which the PPR came into being, i.e. through
which method or protocol it was created.";
}
leaf ppr-packets {
type uint64;
description
"The number of packets that have forwarded on that path.
(Modulo semantics apply, i.e. the value of the leaf wraps
around to 0 when the maximum uint64 is reached.)";
}
leaf ppr-dropped-packets {
type uint64;
description
"The number of packets on that path that have been dropped
by this node. (Modulo semantics apply, i.e. the value of
the leaf wraps around to 0 when the maximum uint64 is
reached.)";
}
leaf ppr-octets {
type uint64;
description
"The number of octets that have been forwarded on that
path. (Modulo semantics apply, i.e. the value of the
leaf wraps around to 0 when the maximum uint64 is
reached.)";
}
leaf ppr-active-flows {
type uint32;
description
"The number of distinct flows that are currently active
on that path.";
}
}
}
}
<CODE ENDS>
tbd
This document requests the following new code points in IANA PPR Attributes TLV code-point registry for IS-IS, OSPFv2 and OSPFv3 protocols. IS-IS PPR Attributes are defined in [I-D.chunduri-lsr-isis-preferred-path-routing] and OSPF PPR attributes are defined in [I-D.chunduri-lsr-isis-preferred-path-routing].
Sub-TLV # Sub-TLV Name --------- ---------------------------------------------------------
IANA is requested to add the following entries to the IPFIX Information Elements Registry:
This document registers the following namespace URI in the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-ppr-statistics
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document registers the following YANG module in the "YANG Module Names" registry [RFC6020]:
Name: ietf-ppr-statistics
Namespace: urn:ietf:params:xml:ns:yang:ietf-ppr-statistics
Prefix: pprs
Reference: draft-cpc-rtgwg-ppr-oam-XX.txt (RFC form)
The ability to perform path traces and pings could be used by an attacker to discover details of a network. In addition, excessive amounts of traces and pings could be used by an attacker to try and exhaust network resources. Network providers therefore need to secure the ability to invoke trace and ping operations, requiring proper auhorization and authentication. Likewise, trace or ping requests originating from an untrusted source from outside the network edge should be dropped at the ingress edge.
Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. Further security analysis for IS-IS protocol is done in [RFC7645] with detailed analysis of various security threats and why [RFC5304] should not be used in the deployments. Advertisement of the additional information defined in this document introduces no new security concerns in IS-IS protocol. However as this extension is related to SR-MPLS and SRH data planes as defined in [I-D.ietf-spring-segment-routing], those particular data plane security considerations does apply here.
Existing security extensions for OSPF protocol are described in [RFC2328] and [RFC7684] apply to the extensions specified in this document. While OSPF is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPF routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC7474] SHOULD be used.
This document also describes IPFX extensions that allow it to be used as a mechanism for IP Path Information Export. IPFIX security considerations apply, which are detailed in [RFC7011] section 11.
The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. The readable data nodes are defined under the container "ppr-stats". The sensitivity/vulnerability concerns providing an unauthorized attacker with internals about the network, specifically exposure of PPR IDs that are installed on a network node and insight about the network traffic that occurs over these nodes.