idnits 2.17.1 draft-akiya-bfd-seamless-alert-discrim-03.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 (October 21, 2014) is 3474 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 (-04) exists of draft-akiya-bfd-seamless-sr-03 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-seamless-base-03 == Outdated reference: A later version (-06) exists of draft-ietf-bfd-seamless-ip-00 == Outdated reference: A later version (-02) exists of draft-ietf-isis-sbfd-discriminator-01 == Outdated reference: A later version (-06) exists of draft-ietf-ospf-sbfd-discriminator-00 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. Akiya 3 Internet-Draft C. Pignataro 4 Intended status: Standards Track D. Ward 5 Expires: April 24, 2015 Cisco Systems 6 October 21, 2014 8 Seamless Bidirectional Forwarding Detection (S-BFD) Alert Discriminator 9 draft-akiya-bfd-seamless-alert-discrim-03 11 Abstract 13 This document defines the Alert Discriminator which operates on the 14 Seamless Bidirectional Forwarding Detection (S-BFD), and Alert 15 Discriminator Diagnostic Codes which operates on the Alert 16 Discriminator. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 24, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Extended S-BFD Use Cases . . . . . . . . . . . . . . . . . . 2 60 2.1. Target S-BFD Discriminator Discovery . . . . . . . . . . 3 61 2.2. S-BFD Path Tracing . . . . . . . . . . . . . . . . . . . 3 62 3. Alert Discriminator . . . . . . . . . . . . . . . . . . . . . 4 63 4. Alert Discriminator Diagnostic Codes . . . . . . . . . . . . 4 64 4.1. Diagnostic Code: Target S-BFD Discriminator Discovery . . 4 65 4.2. Diagnostic Code: S-BFD Path Tracing . . . . . . . . . . . 5 66 4.3. Diagnostic Code: Not Supported . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 6.1. Alert Discriminator Diagnostic Codes Registry . . . . . . 7 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 7 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 9.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 [I-D.ietf-bfd-seamless-base] defines the Seamless Bidirectional 80 Forwarding Detection (S-BFD): a simplified mechanism which uses 81 Bidirectional Forwarding Detection (BFD) with large portions of 82 negotiation aspects eliminated. 84 This document defines the Alert Discriminator which operates on the 85 S-BFD, and the Alert Discriminator Diagnostic Codes which operates on 86 the Alert Discriminator, for extended S-BFD use cases described in 87 Section 2. 89 2. Extended S-BFD Use Cases 91 This section describes extended S-BFD use cases. 93 2.1. Target S-BFD Discriminator Discovery 95 IS-IS ([I-D.ietf-isis-sbfd-discriminator]) and OSPF 96 ([I-D.ietf-ospf-sbfd-discriminator]) protocols have been extended to 97 advertise S-BFD discriminator values. These extensions will suffice 98 for number of scenarios where S-BFD is used to verify the network 99 reachability to other network devices. Other protocols may be 100 extended to support S-BFD in further scenarios. 102 There are, however, some scenarios where it is desirable to have a 103 mechanism within the S-BFD protocol to discover the target S-BFD 104 discriminator value. 106 o In some scenarios, direct protocol communications are 107 intentionally kept minimal for reasons such as administrative 108 policy. One such example is the usage of S-BFD across Autonomous 109 System (AS) boundaries (i.e. inter-AS). 111 o In some scenarios, there is no control plane which can easily 112 advertise S-BFD discriminators. MPLS-TP and static routes are 113 such examples. 115 o In some scenarios, defining and standardizing protocol extensions 116 to advertise S-BFD discriminator values may be more work than the 117 value it brings. 119 To accommodate the two scenarios described, it is desirable to have a 120 mechanism within the S-BFD protocol to discover the target S-BFD 121 discriminator value. 123 2.2. S-BFD Path Tracing 125 When a multihop S-BFD session, IP based or MPLS based, determines a 126 loss of reachability to the target entity, the responsibility of 127 identifying the problematic point in the paths is often left to 128 operators. ICMP echo request/reply (IP Ping/Trace) [RFC0792] and 129 MPLS echo request/reply (LSP Ping/Trace) [RFC4379] allow for tracing 130 of hops to a specific target, and these are often used by operators, 131 manually or automatically, to attempt to isolate faults. However, 132 when it comes to identifying the problematic point that caused the 133 S-BFD session to declare the failure, there are couple of issues. 135 o Usage of non-S-BFD packets can result in them being load balanced 136 differently along the paths, causing those packets to traverse 137 different paths than S-BFD packets did. 139 o Usage of non-S-BFD packets may not identify the problematic points 140 which only affect specific flows (which affects S-BFD packets). 142 o In order to isolate short lived transient issues, it is desirable 143 to immediately perform the task of fault isolation. IP/MPLS Ping/ 144 Trace implementations often require more processing overhead than 145 S-BFD. Usage of heavier tool to attempt to isolate fault can 146 result in missing more instances of identifying short lived 147 transient issues. 149 Although the task of "fault isolation" does not belong in the BFD/ 150 S-BFD protocols, if the task of "fault isolation" can be done with 151 simple extensions within the S-BFD protocol, the result does provide 152 additional benefit to operators. 154 3. Alert Discriminator 156 This document reserves the value zero of the S-BFD discriminator pool 157 as the Alert Discriminator. A reflector BFD session is to monitor 158 incoming S-BFD packets with value zero in the "Your Discriminator" 159 field. The reflector BFD session is to process the S-BFD packets 160 according to the value specified in the received "Diagnostic" field. 161 Procedures specific to each "Diagnostic" code are described in 162 Section 4. 164 4. Alert Discriminator Diagnostic Codes 166 This section defines the Alert Discriminator Diagnostic Codes, and 167 procedures for each defined code point. The Alert Discriminator 168 Diagnostic Codes MUST operate on the Alert Discriminator. 169 Specifically: 171 o In the direction from an SBFDInitiator to an SBFDReflector, the 172 Alert Discriminator Diagnostic Codes MUST only be used with "Your 173 Discriminator" field set to the Alert Discriminator. 175 o In the direction from an SBFDReflector to an SBFDInitiator, the 176 Alert Discriminator Diagnostic Code MUST only be used in a reply 177 S-BFD packet if received S-BFD packet contained "Your 178 Discriminator" field set to the Alert Discriminator. 180 4.1. Diagnostic Code: Target S-BFD Discriminator Discovery 182 The Alert Discriminator Diagnostic Code 29 is defined for the purpose 183 of discovering the target S-BFD discriminator. 185 Value Alert Discriminator Diagnostic Code Name 186 ------ ---------------------------------------- 187 29 Target S-BFD Discriminator Discovery 189 When a reflector BFD session receives an S-BFD packet containing the 190 Alert Discriminator and the Alert Discriminator Diagnostic Code of 191 29, then the reflector BFD session SHOULD send a reply S-BFD packet. 192 The format and the contents of the generated reply S-BFD packet MUST 193 follow the definition in the S-BFD protocol documents, except for 194 following fields: 196 o "My Discriminator" field MUST be set to one of local S-BFD 197 discriminators. 199 o "Diagnostic" field MUST be set to value 29. 201 4.2. Diagnostic Code: S-BFD Path Tracing 203 The Alert Discriminator Diagnostic Code 30 is defined for the purpose 204 of S-BFD path tracing. 206 Value Alert Discriminator Diagnostic Code Name 207 ------ ---------------------------------------- 208 30 S-BFD Path Trace 210 When a reflector BFD session receives an S-BFD packet containing the 211 Alert Discriminator and the Alert Discriminator Diagnostic Code of 212 30, then the reflector BFD session SHOULD send a reply S-BFD packet. 213 The format and the contents of the generated reply S-BFD packet MUST 214 follow the definition in the S-BFD protocol documents, except for 215 following fields: 217 o "My Discriminator" field MUST be set to zero. 219 o "Diagnostic" field MUST be set to value 30. 221 4.3. Diagnostic Code: Not Supported 223 The Alert Discriminator Diagnostic Code 31 is defined for a reflector 224 BFD session to communicate, in reply S-BFD packet, that specified 225 Alert Discriminator Diagnostic Code in received S-BFD packet is not 226 understood or is not supported. 228 Value Alert Discriminator Diagnostic Code Name 229 ------ ---------------------------------------- 230 31 Not Supported 232 When a reflector BFD session receives an S-BFD packet containing the 233 Alert Discriminator and an Alert Discriminator Diagnostic Code which 234 is not understood or supported by the reflector BFD session, then the 235 reflector BFD session SHOULD send a reply S-BFD packet. The format 236 and the contents of the generated reply S-BFD packet MUST follow the 237 definition in the S-BFD protocol documents, except for following 238 fields: 240 o "My Discriminator" field MUST be set to zero. 242 o "Diagnostic" field MUST be set to value 31. 244 Note that in the direction from an SBFDInitiator to an SBFDReflector, 245 the Alert Discriminator Diagnostic Code 31 MUST NOT be used. If a 246 reflector BFD session receives an S-BFD packet with the Alert 247 Discriminator and the Alert Discriminator Diagnostic Code 31, then 248 the reflector BFD session MUST drop the packet. 250 5. Security Considerations 252 Conceptually the Alert Discriminator is similar to an IP Router Alert 253 Option or an MPLS Router Alert Label. The Alert Discriminator 254 introduces a way which remote network devices can instruct a 255 reflector BFD sessions to perform specific tasks corresponding to 256 specified Alert Discriminator Diagnostic Codes, and without remote 257 network devices knowing a valid S-BFD discriminator on the target 258 device. Hence, it is very critical that reflector BFD session 259 services the Alert Discriminator only from trusted sources and for 260 allowed Alert Diagnostic Codes for those sources. Therefore, this 261 document RECOMMENDS following security procedures to be implemented: 263 o S-BFD packets with Alert Discriminator is accepted only from 264 trusted sources. An implementation SHOULD provide a mechanism for 265 operators to specify an access-list to describe the trusted 266 sources. 268 o An implementation SHOULD provide a mechanism for operators to 269 specify the Alert Discriminator Diagnostic Codes which are 270 supported on the device. If required, such configuration should 271 be set per a trusted source. 273 Additionally, it is RECOMMENDED that implementations supporting the 274 Alert Discriminator considers the security considerations described 275 in [I-D.ietf-bfd-seamless-base], [I-D.ietf-bfd-seamless-ip] and 276 [I-D.akiya-bfd-seamless-sr] documents. 278 6. IANA Considerations 280 This document requests IANA to create a new registry within 281 [IANA-BFD] protocol to maintain "Alert Discriminator Diagnostic 282 Codes" field. Initial values are described in immediate sub-section 283 to follow. 285 6.1. Alert Discriminator Diagnostic Codes Registry 287 The IANA is requested to create and maintain a registry entitled 288 "Alert Discriminator Diagnostic Codes" with the following 289 registration procedures: 291 Registry Name: Alert Discriminator Diagnostic Codes 293 Value Alert Discriminator Diagnostic Code Name Reference 294 ------ ---------------------------------------- ------------- 295 0-7 Experimental This document 296 8-28 Reserved This document 297 29 Target S-BFD Discriminator Discovery This document 298 30 S-BFD Path Trace This document 299 31 Not Supported This document 301 Assignments of Alert Discriminator Diagnostic Codes are via Standards 302 Action [RFC5226]. 304 7. Acknowledgements 306 Authors would like to thank Srihari Raghavan and Girija Raghavendra 307 Rao for reviewing and providing comments on this document. 309 8. Contributing Authors 311 Nagendra Kumar 312 Cisco Systems 313 Email: naikumar@cisco.com 315 Mallik Mudigonda 316 Cisco Systems 317 Email: mmudigon@cisco.com 319 Aswatnarayan Raghuram 320 AT&T 321 Email: ar2521@att.com 323 Glenward D. Hayden 324 AT&T 325 Email: gh1691@att.com 327 9. References 328 9.1. Normative References 330 [I-D.akiya-bfd-seamless-sr] 331 Akiya, N., Pignataro, C., and N. Kumar, "Seamless 332 Bidirectional Forwarding Detection (S-BFD) for Segment 333 Routing", draft-akiya-bfd-seamless-sr-03 (work in 334 progress), August 2014. 336 [I-D.ietf-bfd-seamless-base] 337 Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. 338 Networks, "Seamless Bidirectional Forwarding Detection 339 (S-BFD)", draft-ietf-bfd-seamless-base-03 (work in 340 progress), August 2014. 342 [I-D.ietf-bfd-seamless-ip] 343 Akiya, N., Pignataro, C., and D. Ward, "Seamless 344 Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 345 and MPLS", draft-ietf-bfd-seamless-ip-00 (work in 346 progress), September 2014. 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 9.2. Informative References 353 [I-D.ietf-isis-sbfd-discriminator] 354 Ginsberg, L., Akiya, N., and M. Chen, "Advertising S-BFD 355 Discriminators in IS-IS", draft-ietf-isis-sbfd- 356 discriminator-01 (work in progress), October 2014. 358 [I-D.ietf-ospf-sbfd-discriminator] 359 Bhatia, M., Pignataro, C., Aldrin, S., and T. Ranganath, 360 "OSPF extensions to advertise S-BFD Target Discriminator", 361 draft-ietf-ospf-sbfd-discriminator-00 (work in progress), 362 September 2014. 364 [IANA-BFD] 365 IANA, "Bidirectional Forwarding Detection (BFD) 366 Parameters", . 369 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 370 RFC 792, September 1981. 372 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 373 Label Switched (MPLS) Data Plane Failures", RFC 4379, 374 February 2006. 376 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 377 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 378 May 2008. 380 Authors' Addresses 382 Nobo Akiya 383 Cisco Systems 385 Email: nobo@cisco.com 387 Carlos Pignataro 388 Cisco Systems 390 Email: cpignata@cisco.com 392 Dave Ward 393 Cisco Systems 395 Email: wardd@cisco.com