idnits 2.17.1 draft-ietf-bfd-stability-10.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 12, 2021) is 1109 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) == Outdated reference: A later version (-15) exists of draft-ietf-bfd-optimizing-authentication-11 == Outdated reference: A later version (-13) exists of draft-ietf-bfd-secure-sequence-numbers-07 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Mishra 3 Internet-Draft SES 4 Intended status: Standards Track M. Jethanandani 5 Expires: October 14, 2021 Kloud Services 6 A. Saxena 7 Ciena Corporation 8 S. Pallagatti 9 VMware 10 M. Chen 11 Huawei 12 P. Fan 13 China Mobile 14 April 12, 2021 16 BFD Stability 17 draft-ietf-bfd-stability-10 19 Abstract 21 This document describes extensions to the Bidirectional Forwarding 22 Detection (BFD) protocol to measure BFD stability. Specifically, it 23 describes a mechanism for detection of BFD packet loss. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 14, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. BFD NULL-Authentication Type . . . . . . . . . . . . . . . . 3 63 5. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3 64 5.1. Loss Measurement . . . . . . . . . . . . . . . . . . . . 4 65 6. ietf-bfd-stability YANG Module . . . . . . . . . . . . . . . 4 66 6.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 4 67 6.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 5 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 7.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 9 70 7.2. The "YANG Module Names" Registry . . . . . . . . . . . . 9 71 8. Security Consideration . . . . . . . . . . . . . . . . . . . 9 72 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 11.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 The Bidirectional Forwarding Detection ( BFD) [RFC5880] protocol 82 operates by transmitting and receiving BFD control packets, generally 83 at high frequency, over the datapath being monitored. In order to 84 prevent significant data loss due to a datapath failure, BFD session 85 detection time as defined in BFD [RFC5880] is set to the smallest 86 feasible value. 88 This document proposes a mechanism to detect lost packets in a BFD 89 session in addition to the datapath fault detection mechanisms of 90 BFD. Such a mechanism presents significant value to measure the 91 stability of BFD sessions and provides data to the operators for the 92 cause of a BFD failure. 94 This document does not propose any BFD extension to measure data 95 traffic loss or delay on a link or tunnel and the scope is limited to 96 BFD packets. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in RFC 103 2119 [RFC2119] and RFC 8174 [RFC8174]. 105 The reader is expected to be familiar with the BFD [RFC5880], 106 Optimizing BFD Authentication 107 [I-D.ietf-bfd-optimizing-authentication] and BFD Secure Sequence 108 Numbers [I-D.ietf-bfd-secure-sequence-numbers]. 110 3. Use Cases 112 Bidirectional Forwarding Detection as defined in BFD [RFC5880] cannot 113 detect any BFD packet loss if the loss does not last for detection 114 time. This document proposes a method to detect a dropped packet on 115 the receiver. For example, if the receiver receives BFD control 116 packet k at time t but receives packet k+3 at time t+10ms, and never 117 receives packet k+1 and/or k+2, then it has experienced a drop. 119 This proposal enables BFD implementations to generate diagnostic 120 information on the health of each BFD session that could be used to 121 preempt a failure on a datapath that BFD was monitoring by allowing 122 time for a corrective action to be taken. 124 In a faulty datapath scenario, an operator can use BFD health 125 information to trigger delay and loss measurement OAM protocol, 126 Connectivity Fault Management (CFM) [IEEE802.1ag] or Loss Measurement 127 (LM)-Delay Measurement (DM)) as defined by A One-way Active 128 Measurement Protocol (OWAMP) [RFC4656] to further isolate the issue. 130 4. BFD NULL-Authentication Type 132 The functionality proposed for BFD stability measurement is achieved 133 by appending an authentication section with the NULL Authentication 134 type (as defined in Optimizing BFD Authentication 135 [I-D.ietf-bfd-optimizing-authentication] ) to the BFD control packets 136 that do not have authentication enabled. 138 5. Theory of Operation 140 This mechanism allows operators to measure the loss of BFD control 141 packets. 143 When using MD5 or SHA authentication, BFD uses an authentication 144 section that carries the Sequence Number. However, if non-meticulous 145 authentication is being used, or no authentication is in use, then 146 the non-authenticated BFD control packets MUST include an 147 authentication section with the NULL Authentication type. 149 5.1. Loss Measurement 151 Loss measurement counts the number of BFD control packets missed at 152 the receiver during any Detection Time period. The loss is detected 153 by comparing the Sequence Number field in the Auth TLV (NULL or 154 otherwise) in successive BFD control packets. The Sequence Number in 155 each successive control packet generated on a BFD session by the 156 transmitter is incremented by one. This loss count can then be 157 exposed using the YANG module defined in the subsequent section. 159 The first BFD authentication section with a non-zero sequence number, 160 in a valid BFD control packet, processed by the receiver is used for 161 bootstrapping the logic. When using secure sequence numbers, if the 162 expected values are pre-calculated, the value must be matched to 163 detect lost packets as defined in BFD secure sequence numbers 164 [I-D.ietf-bfd-secure-sequence-numbers]. 166 6. ietf-bfd-stability YANG Module 168 6.1. Data Model Overview 170 This YANG module augments the "ietf-bfd" module to add to the per- 171 session set of counters a 'loss-packet-count' for BFD packets that 172 are lost but do not necessarily result in the BFD session going down. 174 module: ietf-bfd-stability 175 augment /rt:routing/rt:control-plane-protocols 176 /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh 177 /bfd-ip-sh:sessions/bfd-ip-sh:session 178 /bfd-ip-sh:session-statistics: 179 +--ro lost-packet-count? yang:counter32 180 augment /rt:routing/rt:control-plane-protocols 181 /rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh 182 /bfd-ip-mh:session-groups/bfd-ip-mh:session-group 183 /bfd-ip-mh:sessions/bfd-ip-mh:session-statistics: 184 +--ro lost-packet-count? yang:counter32 185 augment /rt:routing/rt:control-plane-protocols 186 /rt:control-plane-protocol/bfd:bfd/bfd-lag:lag 187 /bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links 188 /bfd-lag:micro-bfd-ipv4/bfd-lag:session-statistics: 189 +--ro lost-packet-count? yang:counter32 190 augment /rt:routing/rt:control-plane-protocols 191 /rt:control-plane-protocol/bfd:bfd/bfd-lag:lag 192 /bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links 193 /bfd-lag:micro-bfd-ipv6/bfd-lag:session-statistics: 194 +--ro lost-packet-count? yang:counter32 195 augment /rt:routing/rt:control-plane-protocols 196 /rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls 197 /bfd-mpls:session-groups/bfd-mpls:session-group 198 /bfd-mpls:sessions/bfd-mpls:session-statistics: 199 +--ro lost-packet-count? yang:counter32 201 6.2. YANG Module 203 This YANG module imports Common YANG Types [RFC6991], A YANG Data 204 Model for Routing [RFC8349], and YANG Data Model for Bidirectional 205 Forwading Detection (BFD) [I-D.ietf-bfd-yang]. 207 file "ietf-bfd-stability@2021-04-11.yang" 208 module ietf-bfd-stability { 209 yang-version 1.1; 210 namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-stability"; 211 prefix "bfds"; 213 import ietf-yang-types { 214 prefix "yang"; 215 reference 216 "RFC 6991: Common YANG Data Types"; 217 } 219 import ietf-routing { 220 prefix "rt"; 221 reference 222 "RFC 8349: A YANG Data Model for Routing Management 223 (NMDA version)"; 224 } 226 import ietf-bfd { 227 prefix bfd; 228 reference 229 "I-D.ietf-bfd-yang: YANG Data Model for Bidirectional 230 Forwarding Detection."; 231 } 233 import ietf-bfd-ip-sh { 234 prefix bfd-ip-sh; 235 reference 236 "I-D.ietf-bfd-yang: YANG Data Model for Bidirectional 237 Forwarding Detection."; 238 } 240 import ietf-bfd-ip-mh { 241 prefix bfd-ip-mh; 242 reference 243 "I-D.ietf-bfd-yang: YANG Data Model for Bidirectional 244 Forwarding Detection."; 245 } 247 import ietf-bfd-lag { 248 prefix bfd-lag; 249 reference 250 "I-D.ietf-bfd-yang: YANG Data Model for Bidirectional 251 Forwarding Detection."; 252 } 254 import ietf-bfd-mpls { 255 prefix bfd-mpls; 256 reference 257 "I-D.ietf-bfd-yang: YANG Data Model for Bidirectional 258 Forwarding Detection."; 259 } 261 organization 262 "IETF BFD Working Group"; 264 contact 265 "WG Web: 266 WG List: 268 Authors: Mahesh Jethanandani (mjethanandani@gmail.com) 269 Ashesh Mishra (mishra.ashesh@gmail.com) 270 Ankur Saxena (ankurpsaxena@gmail.com) 271 Santosh Pallagatti (santosh.pallagati@gmail.com) 272 Mach Chen (mach.chen@huawei.com) 273 Peng Fan (fanp08@gmail.com)."; 275 description 276 "This YANG module augments the base BFD YANG model to add 277 attributes related to BFD Stability. In particular it adds a 278 a per session count for BFD packets that are lost. 280 Copyright (c) 2021 IETF Trust and the persons identified as 281 authors of the code. All rights reserved. 283 Redistribution and use in source and binary forms, with or 284 without modification, is permitted pursuant to, and subject to 285 the license terms contained in, the Simplified BSD License set 286 forth in Section 4.c of the IETF Trust's Legal Provisions 287 Relating to IETF Documents 288 (https://trustee.ietf.org/license-info). 290 This version of this YANG module is part of RFC XXXX 291 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 292 for full legal notices. 294 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 295 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 296 'MAY', and 'OPTIONAL' in this document are to be interpreted as 297 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 298 they appear in all capitals, as shown here."; 300 revision "2021-04-11" { 301 description 302 "Initial Version."; 303 reference 304 "RFC XXXX, BFD Stability."; 305 } 307 augment "/rt:routing/rt:control-plane-protocols/" + 308 "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" + 309 "bfd-ip-sh:sessions/bfd-ip-sh:session/" + 310 "bfd-ip-sh:session-statistics" { 311 leaf lost-packet-count { 312 type yang:counter32; 313 description 314 "Number of BFD packets that were lost without bringing the 315 session down."; 316 } 317 description 318 "Augment the 'bfd' container to add attributes related to BFD 319 stability."; 320 } 322 augment "/rt:routing/rt:control-plane-protocols/" + 323 "rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh/" + 324 "bfd-ip-mh:session-groups/bfd-ip-mh:session-group/" + 325 "bfd-ip-mh:sessions/bfd-ip-mh:session-statistics" { 326 leaf lost-packet-count { 327 type yang:counter32; 328 description 329 "Number of BFD packets that were lost without bringing the 330 session down."; 331 } 332 description 333 "Augment the 'bfd' container to add attributes related to BFD 334 stability."; 335 } 337 augment "/rt:routing/rt:control-plane-protocols/" + 338 "rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/" + 339 "bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links/" + 340 "bfd-lag:micro-bfd-ipv4/bfd-lag:session-statistics" { 341 leaf lost-packet-count { 342 type yang:counter32; 343 description 344 "Number of BFD packets that were lost without bringing the 345 session down."; 346 } 347 description 348 "Augment the 'bfd' container to add attributes related to BFD 349 stability."; 350 } 352 augment "/rt:routing/rt:control-plane-protocols/" + 353 "rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/" + 354 "bfd-lag:sessions/bfd-lag:session/bfd-lag:member-links/" + 355 "bfd-lag:micro-bfd-ipv6/bfd-lag:session-statistics" { 356 leaf lost-packet-count { 357 type yang:counter32; 358 description 359 "Number of BFD packets that were lost without bringing the 360 session down."; 361 } 362 description 363 "Augment the 'bfd' container to add attributes related to BFD 364 stability."; 366 } 368 augment "/rt:routing/rt:control-plane-protocols/" + 369 "rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls/" + 370 "bfd-mpls:session-groups/bfd-mpls:session-group/" + 371 "bfd-mpls:sessions/bfd-mpls:session-statistics" { 372 leaf lost-packet-count { 373 type yang:counter32; 374 description 375 "Number of BFD packets that were lost without bringing the 376 session down."; 377 } 378 description 379 "Augment the 'bfd' container to add attributes related to BFD 380 stability."; 381 } 382 } 383 385 7. IANA Considerations 387 7.1. The "IETF XML" Registry 389 This document registers one URIs in the "ns" subregistry of the "IETF 390 XML" registry [RFC3688]. Following the format in [RFC3688], the 391 following registration is requested: 393 URI: urn:ietf:params:xml:ns:yang:ietf-bfd-stability 394 Registrant Contact: The IESG 395 XML: N/A, the requested URI is an XML namespace. 397 7.2. The "YANG Module Names" Registry 399 This document registers one YANG module in the "YANG Module Names" 400 registry YANG [RFC6020]. Following the format in YANG [RFC6020], the 401 following registrations are requested: 403 name: ietf-bfd-stability 404 namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-stability 405 prefix: bfds 406 reference: RFC XXXX 408 8. Security Consideration 410 The YANG module specified in this document defines a schema for data 411 that is designed to be accessed via network management protocols such 412 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 413 is the secure transport layer, and the mandatory-to-implement secure 414 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 415 is HTTPS, and the mandatory-to-implement secure transport is TLS 416 [RFC8446]. The NETCONF Access Control Model (NACM) [RFC8341] 417 provides the means to restrict access for particular NETCONF or 418 RESTCONF users to a preconfigured subset of all available NETCONF or 419 RESTCONF protocol operations and content. 421 The YANG module does not define any writeable/creatable/deletable 422 data nodes. 424 The only readable data nodes in YANG module may be considered 425 sensitive or vulnerable in some network environments. It is thus 426 important to control read access (e.g., via get, get-config, or 427 notification) to these data nodes. The model does not define any 428 readable subtrees and data nodes. 430 The YANG module does not define any RPC operations. 432 9. Contributors 434 Manav Bhatia 436 10. Acknowledgements 438 Authors would like to thank Nobo Akiya, Jeffery Haas, Dileep Singh, 439 Basil Saji, Sagar Soni, Albert Fu and Mallik Mudigonda who also 440 contributed to this document. 442 11. References 444 11.1. Normative References 446 [I-D.ietf-bfd-optimizing-authentication] 447 Jethanandani, M., Mishra, A., Saxena, A., and M. Bhatia, 448 "Optimizing BFD Authentication", draft-ietf-bfd- 449 optimizing-authentication-11 (work in progress), July 450 2020. 452 [I-D.ietf-bfd-secure-sequence-numbers] 453 Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and 454 A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd- 455 secure-sequence-numbers-07 (work in progress), December 456 2020. 458 [I-D.ietf-bfd-yang] 459 Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S., 460 and G. Mirsky, "YANG Data Model for Bidirectional 461 Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work 462 in progress), August 2018. 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, 466 DOI 10.17487/RFC2119, March 1997, 467 . 469 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 470 DOI 10.17487/RFC3688, January 2004, 471 . 473 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 474 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 475 . 477 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 478 the Network Configuration Protocol (NETCONF)", RFC 6020, 479 DOI 10.17487/RFC6020, October 2010, 480 . 482 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 483 and A. Bierman, Ed., "Network Configuration Protocol 484 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 485 . 487 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 488 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 489 . 491 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 492 RFC 6991, DOI 10.17487/RFC6991, July 2013, 493 . 495 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 496 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 497 . 499 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 500 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 501 May 2017, . 503 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 504 Access Control Model", STD 91, RFC 8341, 505 DOI 10.17487/RFC8341, March 2018, 506 . 508 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 509 Routing Management (NMDA Version)", RFC 8349, 510 DOI 10.17487/RFC8349, March 2018, 511 . 513 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 514 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 515 . 517 11.2. Informative References 519 [IEEE802.1ag] 520 Institute of Electrical and Electronics Engineers, Inc., 521 "802.1ag - Connectivity Fault Management", September 2007, 522 . 524 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 525 Zekauskas, "A One-way Active Measurement Protocol 526 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 527 . 529 Authors' Addresses 531 Ashesh Mishra 532 SES 534 Email: mishra.ashesh@gmail.com 536 Mahesh Jethanandani 537 Kloud Services 538 CA 539 USA 541 Email: mjethanandani@gmail.com 542 Ankur Saxena 543 Ciena Corporation 544 3939 North 1st Street 545 San Jose, CA 95134 546 USA 548 Email: ankurpsaxena@gmail.com 549 URI: www.ciena.com 551 Santosh Pallagatti 552 VMware 553 Bangalore, Karnataka 560103 554 India 556 Email: santosh.pallagatti@gmail.com 558 Mach Chen 559 Huawei 561 Email: mach.chen@huawei.com 563 Peng Fan 564 China Mobile 565 32 Xuanwumen West Street 566 Beijing, Beijing 567 China 569 Email: fanp08@gmail.com