idnits 2.17.1 draft-cpc-rtgwg-ppr-oam-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 22 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1753 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC792' is mentioned on line 171, but not defined == Unused Reference: 'RFC8029' is defined on line 829, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-chunduri-lsr-isis-preferred-path-routing-03 == Outdated reference: A later version (-04) exists of draft-chunduri-lsr-ospf-preferred-path-routing-03 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTG Working Group A. Clemm 3 Internet-Draft P. Pillay-Esnault 4 Intended status: Standards Track U. Chunduri 5 Expires: January 9, 2020 Futurewei 6 July 8, 2019 8 Preferred Path Routing (PPR) OAM and Accounting 9 draft-cpc-rtgwg-ppr-oam-00 11 Abstract 13 This document defines OAM and traffic accounting capabilities for 14 Preferred Path Routing (PPR) for IS-IS and OSPF protocols. 15 Specifically, this document specifies OAM capabilities that allow to 16 assert proper PPR connectivity and to trace PPR path information. In 17 addition, a set of statistics and operational data to facilitate PPR 18 traffic accounting on a per-PPR path basis are defined. This 19 includes a number of Information Elements that extend IPFIX to export 20 path information, as well as a YANG Data Model to be used in 21 conjunction with management and control protocols. Collectively the 22 capabilities defined in this document provide network operators with 23 the necessary means to ensure proper working of their PPR 24 deployments. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC2119 [RFC2119], 31 RFC8174 [RFC8174] when, and only when they appear in all capitals, as 32 shown here. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 9, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Definition and Acronyms . . . . . . . . . . . . . . . . . . . 4 70 4. PPR Ping and Trace Functionality . . . . . . . . . . . . . . 4 71 4.1. PPR Trace Functionality in Strict Mode . . . . . . . . . 6 72 4.2. PPR Trace Functionality in Loose Mode . . . . . . . . . . 7 73 5. Traffic Accounting through IGP PPR-Attribute Sub-TLVs . . . . 8 74 6. Path Statistics and IP[F/P]IX . . . . . . . . . . . . . . . . 9 75 7. A YANG Data Model for PPR Monitoring . . . . . . . . . . . . 11 76 7.1. Motivation and Overview . . . . . . . . . . . . . . . . . 11 77 7.2. YANG Data Model . . . . . . . . . . . . . . . . . . . . . 13 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 9.1. IGP Path Attributes . . . . . . . . . . . . . . . . . . . 16 81 9.2. IPFIX Information Elements . . . . . . . . . . . . . . . 16 82 9.3. YANG Data Model . . . . . . . . . . . . . . . . . . . . . 16 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 10.1. Path Trace and Ping . . . . . . . . . . . . . . . . . . 17 85 10.2. IGPs and IPFIX . . . . . . . . . . . . . . . . . . . . . 17 86 10.3. YANG Data Model . . . . . . . . . . . . . . . . . . . . 18 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 89 11.2. Informative References . . . . . . . . . . . . . . . . . 20 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 92 1. Introduction 94 Preferred Path Routing (PPR) allows to route packets along a custom 95 path on the basis of a path identifier (PPR-ID) as opposed to 96 individual segments in the packet. Interior Gateway Protocols (IGPs) 97 nodes compute nexthops based on the path description for the prefix 98 and take proper forwarding actions for the paths that they are a part 99 of. PPR may be used with different data planes, e.g. IPv4, IPv6, 100 MPLS, SRv6. Dissemination and nexthop computation of path 101 information is described in 102 [I-D.chunduri-lsr-isis-preferred-path-routing] and 103 [I-D.chunduri-lsr-ospf-preferred-path-routing]. 105 In order to operate, administer, and maintain PPR deployments, 106 network operators must be given tools that allow them to ensure that 107 PPR is working as expected and that allow them to troubleshoot any 108 potential problems. This includes assessing whether remote 109 destinations can indeed be reached as intended using a given 110 preferred path, and to verify path elements along the path being 111 taken. Traditionally, ping (ICMP echo request on IP networks, LSP 112 ping in MPLS networks) and traceroute operations are used for those 113 purposes. In order to facilitate operation of PPR, analogous 114 capabilities with PPR-specific extensions are useful which are 115 defined in this document. 117 In addition, for purposes of traffic accounting and ongoing 118 operations, it can be very useful to maintain certain PPR statistics. 119 This allows, for example, to assess times and volume when traffic 120 over preferred paths is occurring. This document defines new PPR 121 path attributes as defined in Section 5 and this can be optionally 122 signaled for the preferred paths selectively to account for the 123 traffic on every path segment (where critical SLAs are needed). 124 IPFIX is commonly used to maintain and export flow-specific 125 information from any node in the network. This document introduces a 126 number of new IPFIX Information Elements that are useful in 127 conjunction with PPR. 129 Some of the same statistics maintained on a per-flow basis may be 130 useful to maintain not just for the duration of a flow, but for the 131 lifetime of the path. That information is considered part of regular 132 management information and subject to specification as part of a YANG 133 data model. 135 2. Key Words 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 3. Definition and Acronyms 145 o IE: IPFIX Information Element 147 o IGP: Interior Gateway Protocol 149 o IPFIX: IP Flow Information eXport 151 o IS-IS Link State PDU 153 o PPR: Preferred Path Routing/Route 155 o PPR-ID: Preferred Path Route Identifier, a data plane identifier 157 o SRH: Segment Routing Header - IPv6 routing Extension header 159 o SRv6: Segment Routing with Ipv6 data plane with SRH 161 o TE: Traffic Engineering 163 4. PPR Ping and Trace Functionality 165 Ping and Trace capabilities depend on the underlying data plane being 166 used for the PPR path. Different mechanisms exist for each of those 167 data planes. As PPR support does not require any change in the 168 existing dataplane, for each of those cases, existing ping and trace 169 core mechanisms continue to work seamlessly without modification: 171 IPv4 data plane: ICMP [RFC792] 173 IPv6 data plane: ICMPv6 [RFC4443] 175 MPLS data plane: LSP Ping [RFC8287] 177 SRv6 data plane: Mechanism under development 179 To manage PPR, network operators may require additional information 180 that is specific to PPR. For example, PPR may be installed by 181 different IGPs(OSPF/ISIS) and supports two types of paths: 183 (1) Strict: where all the nodes on the path are specified and the 184 traffic is forwarded at every single hop to the next node 185 defined in the path. 187 (2) Loose: where not all nodes are described in the path. There are 188 section(s) of the path that are unspecified and the packets are 189 forwarded based on the local router forwarding until the next 190 node in the path description. 192 The current mechanisms need to be enhanced to carry the PPR specific 193 mechanism but otherwise it has minimal changes. In this section, a 194 simple topology is shown in Figure 1 is used to illustrate the 195 different traces of PPR paths described in the subsequent sub 196 sections below. 198 1 __R9___R10__ 1 199 / 1 \ 200 R1-------R2 R3------R4 201 \_____R11____/ 202 2 2 204 Figure 1. Topology example 206 PPR paths from topology 207 PPR-ID: (strict) -> R1, R2, R3, R11, R4 209 PPR-ID: (Loose) -> R1, R2, R3, R4 210 The section between R2-R3 is loose. 211 The best path is via R9 and 10. Path is R1, R2, (R9, R10), R3, R4 212 Node Node IPaddr SPF Cost to R3 213 R1 1.1.1.1 214 R2 2.2.2.2 costs via R9+R10=3, via R11=4 215 R3 3.3.3.3 216 R4 4.4.4.4 217 R9 9.9.9.9 218 R10 10.10.10.10 219 R11 11.11.11.11 221 The classic ping to a destination relying on the forwarding path 222 works seamlessly as the PPR path is installed via IGPs. The PPR-ID 223 is the same as the destination address/label in different dataplanes, 224 therefore the existing ping mechanism remains unchanged in a network 225 supporting PPR. 227 However, the traceroute output should display more PPR specific 228 information such as whether or not the path from a node is loose or 229 strict, or the source of the protocol that installed a PPR-ID or the 230 dataplane information. In order to support PPR-specific trace 231 information, a few additional capabilities are needed. 233 A PPR Trace is initiated from a node, using the PPR-ID as a 234 parameter. The trace will then traverse the PPR path of the 235 specified PPR-ID. In addition to the information that would be 236 returned with a regular trace, PPR-specific information is returned 237 from PPR nodes that are encountered along the path. For each PPR 238 node, the following information is returned: 240 (1) Node Information: Provides the loopback identifier of the node 241 (TBD). 243 (2) Loose-or-strict-or-none: Indicates whether the path from that 244 node is loose or strict, or whether the node is PPR-capable but 245 not one of the nodes designated in the path. The latter can be 246 the case for transit nodes on a loose segment of the path. 248 (3) PPR-Origin Protocol: Indicates the protocol that installed the 249 PPR-ID in the FIB. 251 (4) PPR-ID: Indicates the PPR-ID of the packet as received. This is 252 needed in case of a loose path, leading to encapsulated PPR-ID, 253 described further in Section 4.2. 255 These PPR specific information will be carried in ICMP data. These 256 extensions are TBD for the various dataplanes. 258 4.1. PPR Trace Functionality in Strict Mode 260 The PPR strict mode indicates the PPR path on a hop by hop basis. As 261 the PPR-ID represents a strict path to be followed, the ingress node 262 should increment the TTL for the PPR-ID until all the egress node has 263 returned all individual intermediate segments completely traced. 265 The PPR specific enhancements additional information are returned as 266 part of trace information. The strict path to be trace is PPR- 267 ID=4.4.4.5 represents the path (R1, R2, R11, R3, R4). An example of 268 the output for traceroute for PPR-IS in IPV4 dataplane is given 269 below: 271 >traceroute 4.4.4.5 273 traceroute to 4.4.4.5 (192.4.4.5), 30 hops max, 40 byte packets 274 1 1.1.1.1 (192.1.1.1) 6.819 ms 1.370 ms 1.281 ms 275 PPR: ID:4.4.4.5 Mode=Strict Origin=IS-IS 277 2 2.2.2.2 (192.1.1.2) 4.437 ms 1.987 ms 2.335 ms 278 PPR: ID:4.4.4.5 Mode=Strict Origin=IS-IS 280 3 11.11.11.11 (192.11.11.11) 9.830 ms 11.696 ms 5.478 ms 281 PPR: ID:4.4.4.5 Mode=Strict Origin=IS-IS 283 4 3.3.3.3 (192.3.3.3) 9.448 ms 5.096 ms 7.518 ms 284 PPR: ID:4.4.4.5 Mode=Strict Origin=IS-IS 286 5 4.4.4.4 (192.3.3.4) 9.448 ms 5.096 ms 7.518 ms 287 PPR: ID:4.4.4.5 Mode=Strict Origin=IS-IS 289 Figure 2 Enhanced traceroute Output example 291 The output for IPv6 and MPLS traceroute should be augmented to 292 display the PPR-ID specific parameters as shown above. 294 4.2. PPR Trace Functionality in Loose Mode 296 The PPR loose path functionality allows greater flexibility by 297 letting the IGP calculate the best path on a loose section of the 298 path described for PPR-ID. The traditional traceroute requires 299 additional enhancement for the PPR trace to perform correctly . Per 300 Figure 1, the loose path example is R1, R2,(R9, R10), R3, R4 where () 301 represents the loose section of the path. An example of the output 302 for traceroute for PPR-IS in IPV4 dataplane is given below: 304 >traceroute 4.4.4.5 306 traceroute to 4.4.4.5 (192.4.4.5), 30 hops max, 40 byte packets 308 1 1.1.1.1 (192.1.1.1) 6.819 ms 1.370 ms 1.281 ms 309 PPR: ID:4.4.4.5 Mode=Strict Origin=OSPF 311 2 2.2.2.2 (192.1.1.2) 4.437 ms 1.987 ms 2.335 ms 312 PPR: ID:4.4.4.5 Mode=Loose Origin=OSPF Multipaths=0 314 1 9.9.9.9 (192.9.9.9) 9.830 ms 11.696 ms 5.478 ms 315 PPR: ID:4.4.4.5 Mode=None Origin=OSPF 317 2 10.10.10.10 (192.9.9.10) 4.230 ms 4.633 ms 5.789 ms 318 PPR: ID:4.4.4.5 Mode=None Origin=OSPF 320 3 3.3.3.3 (192.3.3.3) 9.448 ms 5.096 ms 7.518 ms 321 PPR: ID:4.4.4.5 Mode=Strict Origin =OSPF 323 4 4.4.4.4 (192.3.3.4) 9.448 ms 5.096 ms 7.518 ms 324 PPR: ID:4.4.4.5 Mode=Strict Origin=OSPF 326 Figure 3 Enhanced traceroute Output example 328 The output for IPv6 and MPLS traceroute should be augmented to 329 display the PPR-ID, Mode and Origin. 331 As the loose path functionality does not preclude the presence of 332 equal cost multiple paths (ECMPs), the well documented limitations 333 and solutions for classic traceroute applies here as well. For 334 operational purposes, it might be of value to list all the 335 multipaths. To acheive this the node just before the loose section 336 MAY initiate a recursive traceroute to aggregate that information and 337 send it with their ICMP Echo Reply message. 339 5. Traffic Accounting through IGP PPR-Attribute Sub-TLVs 341 Traffic for certain PPRs may have more stringent requirement w.r.t 342 accounting for critical SLAs (e.g. 5G non-eMBB slice) and should 343 account for any link/node failures along the path. Presence of 344 "Packet Traffic Accounting" and "Traffic Statistics" Sub-TLVs below 345 in IGP PPR-TLV instructs all the respective nodes along the path to 346 provision the hardware and to account for the respective traffic 347 statistics. Traffic accounting should happen, when the actual data 348 traffic hits for the PPR-ID in the forwarding plane. This capability 349 allows more granular and dynamic enablement of traffic statistics for 350 only certain PPRs as needed. 352 As instruction for creating and deleting the traffic accounting for 353 PPRs happen through IGP message processing, respective IGP's control 354 plane security (Section 10) options are applicable to the PPR-TLV and 355 Sub-TLVs thereof. 357 PPR-Attribute Sub-TLVs describe the attributes of that particular 358 path. The following path attribute Sub-TLVs are defined for 359 respective IGP PPR-TLV [I-D.chunduri-lsr-isis-preferred-path-routing] 360 and [I-D.chunduri-lsr-ospf-preferred-path-routing]. 362 o Type 10 (Suggested Value - IANA TBD): Packet Traffic accounting 363 Sub-TLV. Length 0 and has no value field. Specifies to create a 364 counter to count number of packets forwarded on this PPR-ID on 365 each node in the path description. 367 o Type 11 (Suggested Value - IANA TBD): Traffic statistics in Bytes 368 Sub-TLV. Length 0 and has no value field. Specifies to create a 369 counter to count number of bytes forwarded on this PPR-ID 370 specified in the network header (e.g. IPv4, IPv6) on each node in 371 the path description. 373 How the accumulated traffic accounting information is distributed to 374 a central entity is out of scope of this document. One can use any 375 method (e.g. RESTCONF, Yang PUSH, gRPC) to extract the PPR-ID 376 traffic accounting information from various nodes along the path. 378 6. Path Statistics and IP[F/P]IX 380 Network providers will appreciate the ability to collect certain 381 statistics about PPR path usage, including how much traffic a PPR 382 path carries and at what times from any node in the network. Such 383 statistics can be useful to account for the degree of usage of a path 384 and provide additional operational insights, including (for example) 385 usage patterns and trending information. 387 One mechanism that is traditionally used to collect traffic 388 statistics is IPFIX (IP Flow Information eXport [RFC7011]. IPFIX 389 supports a very rich set of Information Elements containing various 390 statistics, far more in fact than will be required for PPR path 391 statistics. However, those statistics are collected only a per-flow 392 basis. 394 In order to be able to collect statistics on a per-path basis, a set 395 of new IPFIX Information Elements need to be defined that allow to 396 capture a PPR-ID. In addition, these new IPFIX Information Elements 397 need to be able to serve as a flow key. This allows separate IPFIX 398 cache entries to be created on a per-path basis, and to export the 399 corresponding records as IPFIX records. Of course, the records 400 exported do not refer to flows but to paths - IPFIX thus becomes de- 401 facto extended to become IPPIX - IP Path Information eXport. 403 Flow records that have a PPR-ID as flow key SHALL be terminated and 404 exported in the following events and/or per configurable policy: 406 o When no packet has not been observed on a path for a time interval 407 defined by a flow inactivity timer. 409 o When the flow has reached a certain age, defined by a flow 410 termination timer. 412 A flow record for path is created when a packet on a path is detected 413 and no flow entry for that PPR-ID exists. I.e., flow records are not 414 created and maintained for every PPR-ID that is known to the Network 415 Element, only to PPR-IDs that are "active". 417 The following new IPFIX Information Elements need to be added: 419 o pprid-ipv4, with ipv4address as abstract data type. 421 o pprid-ipv6, with ipv6address as abstract data type. 423 o pprid-mpls, with unsigned32 as abstract data type. 425 o pprid-srv6, which is for further study. 427 Each of those fields need to be able to be supported as a flow key 428 field. 430 The following statistics, as represented through corresponding 431 Information Elements, will be of particular interest to export as 432 part of IPFIX records with a PPR-ID as flow key: 434 o IE 1: octetDeltaCount - the number of octets on this path 436 o IE 2: packetDeltaCount - the number of incoming packets on this 437 path 439 o IE 3: deltaFlowCount - the number of original flows routed via 440 this path 442 o IE 21: flowEndSysUpTime - the relative time stamp of the last 443 packet of the path flow (i.e. end of the observation period that 444 is covered by the record) 446 o IE 22: flowStartSysUpTime - the relative time stamp of the first 447 packet of the path flow (i.e. beginning of the observation period 448 that is covered by the record) 450 o IE 132: droppedOctetDeltaCount - the number of octets of the path 451 flow that were dropped by the node (during the observation period 452 covered by the record). 454 o IE 133: droppedPacketDeltaCount - the number of packets of the 455 path flow that were dropped by the node (during the observation 456 period covered by the record). 458 Because a path's packets traverse every hop on the path, the observed 459 path statistics are expected to generally be the same on every node 460 across the path. Network providers may therefore choose to configure 461 IPFIX path information export only on certain routers, for example at 462 the network edge. That said, in certain circumstances it may make 463 sense to export statistics from multiple nodes on a path and compare 464 records for any discrepancies in order to diagnose or isolate 465 operational anomalies (such as occurrence of packet loss). 467 7. A YANG Data Model for PPR Monitoring 469 7.1. Motivation and Overview 471 In addition to exporting path flow statistics, network providers need 472 to be able to retrieve operational information about PPR paths as a 473 whole. This includes information about when a path was created, how 474 it came into being, and statistics maintained over the entire 475 lifetime of the path (i.e. since its creation). For this purpose, a 476 YANG Data Model for PPR Monitoring is defined, "ppr-statistics". The 477 model is depicted in the following tree diagram. The tree diagram 478 follows the notation defined in [RFC8340] 479 module: ietf-ppr-statistics 480 +--ro ppr-stats 481 +--ro num-pprs? uint32 482 +--ro ppr* [ppr-id] 483 +--ro ppr-id ppr-id 484 +--ro ppr-creation-time? yang:date-and-time 485 +--ro loose-or-strict? ppr-path-type 486 +--ro ppr-origin? ppr-origin-proto 487 +--ro ppr-packets? uint64 488 +--ro ppr-dropped-packets? uint64 489 +--ro ppr-octets? uint64 490 +--ro ppr-active-flows? uint32 492 Figure 1: Tree diagram for establish-subscription-datastore-error- 493 info 495 The data model contains the following: 497 o num-pprs: indicates the number of currently active PPRs on the 498 node. 500 o ppr: the list of PPRs configured on the node, indexed by ppr-id, 501 with the following entries: 503 * ppr-creation-time: indicates the time the PPR came into being. 505 * loose-or-strict: indicates whether the PPR is loose or strict. 507 * ppr-origin: indicates the way in which the PPR came into being, 508 i.e. through which method or protocol it was created. 510 * ppr-packets: the number of packets that have forwarded on that 511 path. (Wrapping around to 0 when the maximum is reached, per 512 modulo semantics). 514 * ppr-dropped packets: the number of packets on that path that 515 have been dropped by this node. (Wrapping around to 0 when the 516 maximum is reached, per modulo semantics). 518 * ppr-octets: the number of octets that have been forwarded on 519 that path. (Wrapping aound to 0 when the maxium is reached, 520 per modulo semantics). 522 * ppr-active-flows: The number of distinct flows that are 523 currently active on that path. 525 7.2. YANG Data Model 527 file "ietf-ppr-statistics@2019-07-08.yang" 528 module ietf-ppr-statistics { 530 yang-version 1.1; 531 namespace "urn:ietf:params:xml:ns:yang:ietf-ppr-statistics"; 533 prefix pprs; 535 import ietf-yang-types { 536 prefix yang; 537 } 539 import ietf-inet-types { 540 prefix inet; 541 } 543 organization "IETF"; 544 contact 545 "WG Web: 546 WG List: 548 Author: Alexander Clemm 549 551 Author: Padma Pillay-Esnault 552 554 Author: Uma Chunduri 555 "; 557 description 558 "The YANG data model defines a set of statistics to be used for 559 managing PPR."; 561 revision 2019-07-08 { 562 description 563 "Initial revision"; 564 reference 565 "RFC XXXX: Preferred Path Routing (PPR) OAM and Accounting"; 566 } 568 typedef ppr-id { 569 type union { 570 type inet:ipv4-address; 571 type inet:ipv6-address; 572 type string { 573 length "4..32"; 574 } 575 } 576 description 577 "Identifies a PPR. Depending on the type of PPR, a different 578 format is used."; 579 } 581 typedef ppr-origin-proto { 582 type string; 583 description 584 "Identifies the source of the PPR, i.e. how the PPR came into 585 being. Different values are TBD and the type itself is 586 subject to change."; 587 } 589 typedef ppr-path-type { 590 type enumeration { 591 enum loose { 592 description "Path type is loose"; 593 } 594 enum strict { 595 description "Path type is strict"; 596 } 597 } 598 description 599 "The type of PPR path - loose or strict."; 600 } 602 container ppr-stats { 603 config false; 604 description 605 "Top-level container for PPR statistics."; 606 leaf num-pprs { 607 type uint32; 608 description 609 "The number of currently active PPRs on the node."; 610 } 611 list ppr { 612 key "ppr-id"; 613 description 614 "The list of currently active PPRs on the node."; 615 leaf ppr-id { 616 type ppr-id; 617 description 618 "The identifier of the PPR."; 619 } 620 leaf ppr-creation-time { 621 type yang:date-and-time; 622 description 623 "The precise time at which the PPR was created on the 624 node."; 625 } 626 leaf loose-or-strict { 627 type ppr-path-type; 628 description 629 "An indication whether the PPR is loose or strict."; 630 } 631 leaf ppr-origin { 632 type ppr-origin-proto; 633 description 634 "The way in which the PPR came into being, i.e. through 635 which method or protocol it was created."; 636 } 637 leaf ppr-packets { 638 type uint64; 639 description 640 "The number of packets that have forwarded on that path. 641 (Modulo semantics apply, i.e. the value of the leaf wraps 642 around to 0 when the maximum uint64 is reached.)"; 643 } 644 leaf ppr-dropped-packets { 645 type uint64; 646 description 647 "The number of packets on that path that have been dropped 648 by this node. (Modulo semantics apply, i.e. the value of 649 the leaf wraps around to 0 when the maximum uint64 is 650 reached.)"; 651 } 652 leaf ppr-octets { 653 type uint64; 654 description 655 "The number of octets that have been forwarded on that 656 path. (Modulo semantics apply, i.e. the value of the 657 leaf wraps around to 0 when the maximum uint64 is 658 reached.)"; 659 } 660 leaf ppr-active-flows { 661 type uint32; 662 description 663 "The number of distinct flows that are currently active 664 on that path."; 665 } 666 } 667 } 668 } 669 671 8. Acknowledgements 673 tbd 675 9. IANA Considerations 677 9.1. IGP Path Attributes 679 This document requests the following new code points in IANA PPR 680 Attributes TLV code-point registry for IS-IS, OSPFv2 and OSPFv3 681 protocols. IS-IS PPR Attributes are defined in 682 [I-D.chunduri-lsr-isis-preferred-path-routing] and OSPF PPR 683 attributes are defined in 684 [I-D.chunduri-lsr-isis-preferred-path-routing]. 686 Sub-TLV # Sub-TLV Name 687 --------- --------------------------------------------------------- 689 10 Packet Traffic Accounting (Section 5) 691 11 Traffic Statistics (Section 5) 693 add capability for loose traceroute support. 695 9.2. IPFIX Information Elements 697 IANA is requested to add the following entries to the IPFIX 698 Information Elements Registry: 700 o pprid-ipv4, with ipv4address as abstract data type. 702 o pprid-ipv6, with ipv6address as abstract data type. 704 o pprid-mpls, with unsigned32 as abstract data type. 706 o pprid-srv6, whose abstract data type is for further study. 708 9.3. YANG Data Model 710 This document registers the following namespace URI in the "IETF XML 711 Registry" [RFC3688]: 713 URI: urn:ietf:params:xml:ns:yang:ietf-ppr-statistics 714 Registrant Contact: The IESG. 715 XML: N/A; the requested URI is an XML namespace. 717 This document registers the following YANG module in the "YANG Module 718 Names" registry [RFC6020]: 720 Name: ietf-ppr-statistics 721 Namespace: urn:ietf:params:xml:ns:yang:ietf-ppr-statistics 722 Prefix: pprs 723 Reference: draft-cpc-rtgwg-ppr-oam-XX.txt (RFC form) 725 10. Security Considerations 727 10.1. Path Trace and Ping 729 The ability to perform path traces and pings could be used by an 730 attacker to discover details of a network. In addition, excessive 731 amounts of traces and pings could be used by an attacker to try and 732 exhaust network resources. Network providers therefore need to 733 secure the ability to invoke trace and ping operations, requiring 734 proper auhorization and authentication. Likewise, trace or ping 735 requests originating from an untrusted source from outside the 736 network edge should be dropped at the ingress edge. 738 10.2. IGPs and IPFIX 740 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 741 Further security analysis for IS-IS protocol is done in [RFC7645] 742 with detailed analysis of various security threats and why [RFC5304] 743 should not be used in the deployments. Advertisement of the 744 additional information defined in this document introduces no new 745 security concerns in IS-IS protocol. However as this extension is 746 related to SR-MPLS and SRH data planes as defined in [I-D.ietf- 747 spring-segment-routing], those particular data plane security 748 considerations does apply here. 750 Existing security extensions for OSPF protocol are described in 751 [RFC2328] and [RFC7684] apply to the extensions specified in this 752 document. While OSPF is under a single administrative domain, there 753 can be deployments where potential attackers have access to one or 754 more networks in the OSPF routing domain. In these deployments, 755 stronger authentication mechanisms such as those specified in 756 [RFC7474] SHOULD be used. 758 This document also describes IPFX extensions that allow it to be used 759 as a mechanism for IP Path Information Export. IPFIX security 760 considerations apply, which are detailed in [RFC7011] section 11. 762 10.3. YANG Data Model 764 The YANG module specified in this document defines a schema for data 765 that is designed to be accessed via network management protocols such 766 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 767 is the secure transport layer, and the mandatory-to-implement secure 768 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 769 is HTTPS, and the mandatory-to-implement secure transport is TLS 770 [RFC8446]. 772 The Network Configuration Access Control Model (NACM) [RFC8341] 773 provides the means to restrict access for particular NETCONF or 774 RESTCONF users to a preconfigured subset of all available NETCONF or 775 RESTCONF protocol operations and content. 777 Some of the readable data nodes in this YANG module may be considered 778 sensitive or vulnerable in some network environments. It is thus 779 important to control read access (e.g., via get, get-config, or 780 notification) to these data nodes. The readable data nodes are 781 defined under the container "ppr-stats". The sensitivity/ 782 vulnerability concerns providing an unauthorized attacker with 783 internals about the network, specifically exposure of PPR IDs that 784 are installed on a network node and insight about the network traffic 785 that occurs over these nodes. 787 11. References 789 11.1. Normative References 791 [I-D.chunduri-lsr-isis-preferred-path-routing] 792 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 793 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 794 draft-chunduri-lsr-isis-preferred-path-routing-03 (work in 795 progress), May 2019. 797 [I-D.chunduri-lsr-ospf-preferred-path-routing] 798 Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. 799 Contreras, "Preferred Path Routing (PPR) in OSPF", draft- 800 chunduri-lsr-ospf-preferred-path-routing-03 (work in 801 progress), May 2019. 803 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 804 Requirement Levels", BCP 14, RFC 2119, 805 DOI 10.17487/RFC2119, March 1997, 806 . 808 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 809 DOI 10.17487/RFC3688, January 2004, 810 . 812 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 813 Control Message Protocol (ICMPv6) for the Internet 814 Protocol Version 6 (IPv6) Specification", STD 89, 815 RFC 4443, DOI 10.17487/RFC4443, March 2006, 816 . 818 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 819 the Network Configuration Protocol (NETCONF)", RFC 6020, 820 DOI 10.17487/RFC6020, October 2010, 821 . 823 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 824 "Specification of the IP Flow Information Export (IPFIX) 825 Protocol for the Exchange of Flow Information", STD 77, 826 RFC 7011, DOI 10.17487/RFC7011, September 2013, 827 . 829 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 830 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 831 Switched (MPLS) Data-Plane Failures", RFC 8029, 832 DOI 10.17487/RFC8029, March 2017, 833 . 835 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 836 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 837 May 2017, . 839 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 840 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 841 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 842 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 843 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 844 . 846 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 847 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 848 . 850 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 851 Access Control Model", STD 91, RFC 8341, 852 DOI 10.17487/RFC8341, March 2018, 853 . 855 11.2. Informative References 857 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 858 DOI 10.17487/RFC2328, April 1998, 859 . 861 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 862 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 863 2008, . 865 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 866 and M. Fanto, "IS-IS Generic Cryptographic 867 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 868 2009, . 870 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 871 and A. Bierman, Ed., "Network Configuration Protocol 872 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 873 . 875 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 876 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 877 . 879 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 880 "Security Extension for OSPFv2 When Using Manual Key 881 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 882 . 884 [RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and 885 Authentication for Routing Protocol (KARP) IS-IS Security 886 Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015, 887 . 889 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 890 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 891 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 892 2015, . 894 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 895 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 896 . 898 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 899 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 900 . 902 Authors' Addresses 904 Alexander Clemm 905 Futurewei 906 2330 Central Expressway 907 Santa Clara, CA 95050 908 USA 910 Email: ludwig@clemm.org 912 Padma Pillay-Esnault 913 Futurewei 914 2330 Central Expressway 915 Santa Clara, CA 95050 916 USA 918 Email: padma@futurewei.com 920 Uma Chunduri 921 Futurewei 922 2330 Central Expressway 923 Santa Clara, CA 95050 924 USA 926 Email: umac.ietf@gmail.com