idnits 2.17.1 draft-swallow-mpls-mcast-cv-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 31. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 463. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 436. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 449. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 1) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2007) is 6224 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) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) == Outdated reference: A later version (-02) exists of draft-katz-ward-bfd-multipoint-00 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-05 == Outdated reference: A later version (-09) exists of draft-ietf-bfd-multihop-04 == Outdated reference: A later version (-18) exists of draft-ietf-mpls-p2mp-lsp-ping-02 == Outdated reference: A later version (-07) exists of draft-ietf-bfd-mpls-03 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 I inadvertantly got the date wrong. This one is corrected. Please 2 post. 4 Thanks, 6 ....George 8 ======================================================================== 10 Network Working Group George Swallow 11 Internet Draft Cisco Systems, Inc. 12 Category: Standards Track 13 Expiration Date: September 2007 14 Thomas D. Nadeau 15 Cisco Systems, Inc. 17 Rahul Aggarwal 18 Juniper Networks, Inc. 20 March 2007 22 Connectivity Verification for Multicast Label Switched Paths 24 draft-swallow-mpls-mcast-cv-01.txt 26 Status of this Memo 28 By submitting this Internet-Draft, each author represents that any 29 applicable patent or other IPR claims of which he or she is aware 30 have been or will be disclosed, and any of which he or she becomes 31 aware will be disclosed, in accordance with Section 6 of BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 Abstract 51 Requirements for MPLS P2MP LSPs extend to hundreds or even thousands 52 of endpoints. This document defines a more scalable approach to 53 verifying connectivity for P2MP LSPs. 55 Contents 57 1 Introduction .............................................. 3 58 1.1 Conventions ............................................... 3 59 2 Overview .................................................. 3 60 3 Connectivity Verification Bootstrapping and Maintenance ... 4 61 3.1 Bootstrap and Maintenance Procedures at the Root .......... 4 62 3.1.1 Special Considerations for RSVP-TE P2MP Tunnels ........... 5 63 3.1.2 Special Considerations for mLDP P2MP Tunnels .............. 5 64 3.2 Procedures at an Egress ................................... 6 65 3.2.1 Creating Egress Connectivity Verification State ........... 6 66 3.2.2 Updating Egress Connectivity Verification State ........... 7 67 3.2.3 CV Session State Machine .................................. 7 68 4 Connectivity Verification Session Object .................. 7 69 4.1 Administratively Down IPv4 Nodes .......................... 8 70 4.2 Administratively Down IPv6 Nodes .......................... 8 71 5 Security Considerations ................................... 9 72 6 IANA Considerations ....................................... 9 73 7 Acknowledgments ........................................... 9 74 8 References ................................................ 10 75 8.1 Normative References ...................................... 10 76 8.2 Informative References .................................... 10 77 9 Authors' Addresses ........................................ 11 79 1. Introduction 81 Requirements for Multi-protocol Label Switching (MPLS) Point-to-mul- 82 tipoint (P2MP) Label Switched Paths (LSPs) call for scaling up to 83 hundreds or even thousands of endpoints. Existing tools such as 84 those defined in [RFC4379] and [MPLS-BFD] generally require explicit 85 acknowledgment to each connectivity probe. Such explicit acknowledg- 86 ments adversely affect the scalability and/or practicality of per- 87 forming connectivity verification. That is, the response load at the 88 root would either be overwhelming unless the probing was done infre- 89 quently. This document defines a more scalable approach to monitor- 90 ing P2MP LSP connectivity. 92 MPLS Echo Request/Reply messages [RFC4379] are used to bootstrap a 93 Bi-directional Forwarding Detection (BFD) session across the P2MP LSP 94 in a manner similar to "BFD For MPLS LSPs" [MPLS-BFD]. The actual 95 monitoring uses extensions to BFD defined in [BFD-MCST]. 97 1.1. Conventions 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 103 Based on context the terms leaf, egress and receiver are used some- 104 what interchangeably. The first two are exactly the same. Egress is 105 used where consistency with [RFC4379] was deemed appropriate. 106 Receiver is used in the context of receiving protocol messages. 108 2. Overview 110 In order to scale to large numbers of leaves and to be able to verify 111 connectivity on a frequent basis the protocol defined herein uses BFD 112 packets as unidirectional probes. As specified in [BFD-MCST] BFD 113 packets are sent by the root at a fixed minimum interval. The leaves 114 receive BFD packets and declare a connectivity fault if more than a 115 fixed number of BFD messages are missed. 117 The session is bootstrapped by an MPLS Echo Request/Reply message 118 exchange. The root periodically sends MPLS Echo Request messages 119 containing a Connectivity Verification Session object which is 120 defined in section 3.1. The Echo Request message contains a FEC 121 stack to identify the LSP. This serves to bind the FEC to a BFD dis- 122 criminator. 124 Further discussion on the necessity of bootstrapping the BFD session 125 with with MPLS Echo Request/Reply messages can be found in section 126 3.2 of [MPLS-BFD]. 128 3. Connectivity Verification Bootstrapping and Maintenance 130 The root of the multicast tree initiates Connectivity Verification 131 and is responsible for most of the parameters involved in the Connec- 132 tivity Verification (CV) Session. These parameters are communicated 133 both through MPLS echo request messages and through BFD. The primary 134 role of of the echo request message is to provide the binding between 135 the root's address and chosen BFD discriminator and a particular FEC. 136 It further enables the root to scope the session to a subset of 137 leaves. It also provides a facility for declare some leaves adminis- 138 tratively down while maintaining the CV session for the balance of 139 the leaves. 141 The balance of the session parameters are communicated through BFD. 143 3.1. Bootstrap and Maintenance Procedures at the Root 145 The root first selects a discriminator and an IP destination address 146 to be used both in the BFD packets and in the Connectivity Verifica- 147 tion Session object. Prior to sending an MPLS Echo Request message, 148 the root SHOULD begin sending BFD packets with the selected Discrimi- 149 nator in the My Discriminator field and destination IP address in- 150 band of the subject LSP. Failure to do this could result in false 151 alarms. 153 The root then bootstraps the CV Sessions by creating an MPLS Echo 154 Request message containing a Connectivity Verification Session object 155 and a FEC stack which specifies the LSP for which connectivity veri- 156 fication is desired. The Connectivity Verification Session object 157 MUST contain the selected discriminator and destination IP address. 158 For IPv4 the address MUST be in the range 127/8; for IPv6 the address 159 MUST be in the range 0:0:0:0:0:FFFF:127/104. 161 The Lifetime SHOULD be set to a large value as compared to the BFD 162 Detection Time. 164 Echo reply messages can be jittered by using the Echo Jitter object 165 defined in [[MCSTPING]. the jitter time is set to value that is a 166 function of the rate at which the root is able to process responses 167 and the expected number of responders to this particular message. 168 Exactly how values are chosen is implementation and platform 169 dependent. As such, the exact setting of this interval is beyond the 170 scope of this document. 172 The source and destination IP address of the MPLS echo request packet 173 MUST be the same as those used in the BFD packets. The message is 174 then sent in-band of the LSP. 176 The root (assuming the root does not want the session to time-out) 177 MUST refresh the session within Lifetime milliseconds. It is RECOM- 178 MENDED that the root refresh the CV Session at approximately one 179 third of the Lifetime. 181 If the root wishes to increase the Lifetime, it should behave as if 182 it were first bootstrapping the session. That is it should seek Echo 183 reply messages from all receivers. 185 If the entire CV Session is administratively taken down, this SHOULD 186 be handled through BFD. If, however, a subset of the egress nodes is 187 to be administratively taken down, this is accomplished by including 188 the Administratively Down Nodes sub-object listing the subject nodes. 189 This list may be modified on any refresh message to indicate addi- 190 tional nodes being taken down or to indicate certain nodes as no- 191 longer administratively down. Note that refresh messages MAY be sent 192 at any time to accomplish this. 194 3.1.1. Special Considerations for RSVP-TE P2MP Tunnels 196 For RSVP P2MP tunnels the root knows all of the leaves. When boot- 197 strapping a session, the root can know when all the leaves have 198 responded. Suppose that an initial bootstrap message has been sent 199 and sufficient time for responses have been allowed. If the root has 200 not received MPLS Echo Reply messages from all of the leaves, the 201 root MAY send a subsequent bootstrap message immediately using the 202 scoping techniques of [MCSTPING] to limit the responses. 204 If a new leaf is added to the tree, the root MAY send a refresh mes- 205 sage immediately. Further it MAY use the scoping techniques of 206 [MCSTPING] to limit the response to just the new leaf. 208 3.1.2. Special Considerations for mLDP P2MP Tunnels 210 For Multicast LDP P2MP tunnels the root generally does not know all 211 of the leaves. It is therefore RECOMMENDED that the initial boot- 212 strapping messages be retransmitted several times at relatively short 213 intervals. The number of times SHOULD be equal to or greater than 214 the value of bfd.DetectMult of the associated BFD MultipointHead 215 session. 217 Note that the root can learn who the leaves are from the MPLS Echo 218 Reply messages. It is RECOMMENDED that the root keep a list of 219 active leaves. When the any of the parameters in section 3.2 above 220 are changed, the root can then use the technique in section 3.2.1 to 221 ensure that state is updated, noting however, that some leaves may 222 have ceased connectivity to the tree, while others may have joined. 224 3.2. Procedures at an Egress 226 [Note: this section needs to be brought into in sync with [BFD-MCST]] 228 BFD packets which have the M bit set and are addressed to IPv4 229 addresses in the range 127/8 or IPv6 addresses in the range 230 0:0:0:0:0:FFFF:127/104 SHOULD be ignored if no MPLS Echo Request has 231 been received containing the associated IP source address and dis- 232 criminator combination. 234 When a node receives a MPLS Echo Request containing a Connectivity 235 Verification object, it begins by processing the message as it would 236 any other MPLS Echo Request message. If the result of that process- 237 ing is error free and this node is an egress for the FEC at the bot- 238 tom of the FEC stack, it checks to see if it has CV session state 239 matching the source IP address, discriminator and FEC stack. If not 240 it creates state as specified in section 3.2.1 below. If it does it 241 updates that state as specified in section 3.2.2. Normal response 242 processing for the received MPLS Echo is then done. 244 3.2.1. Creating Egress Connectivity Verification State 246 CV session state is created keyed on the source IP address and Dis- 247 criminator value. This state is set to expire in Lifetime millisec- 248 onds. The session is considered to have expired if not refreshed 249 prior to the expiration of this timer. Included in this state is the 250 FEC and CV Session state, initially set to Init. The egress SHOULD 251 now process BFD packets with this source IP address and Discriminator 252 value. 254 When a BFD packet is received that matches the source IP address and 255 Discriminator it is processed and a BFD session is created. The BFD 256 session is linked to this CV state. In particular the CV session is 257 informed of the BFD state transitions. The CV Session state is 258 changed to UP. 260 3.2.2. Updating Egress Connectivity Verification State 262 [Note, this section will be updated when the Egress CV Session State 263 Machine is added]. 265 If a Connectivity Verification Session object is received which 266 matches the Source_IP_Addr, Discriminator and FEC Stack of existing 267 CV state the Lifetime is reset and the message is examined to deter- 268 mine if there have been any changes in parameters. If the IP address 269 of the egress has been added to the Administratively down nodes, the 270 egress MUST change the CV session state to Administratively Down. 272 If the IP address of the egress has been removed from the Administra- 273 tively Down nodes, then if the BFD session state is Down or the BFD 274 session has been deleted, the CV state is set to INIT; if the BFD 275 session state is UP the CV session state is set to UP. 277 3.2.3. CV Session State Machine 279 [To be written] 281 4. Connectivity Verification Session Object 283 The Connectivity Verification Session object is used to notify leaves 284 that connectivity verification will be performed on the LSP and to 285 set the connectivity verification parameters. 287 The Connectivity Verification Session object has the following for- 288 mat: 290 0 1 2 3 291 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Discriminator | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Lifetime | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Sub-Objects | 298 . . 299 . . 300 | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Discriminator 304 The unique, nonzero discriminator value generated by the 305 transmitting system, which will be used to identify this BFD 306 session. 308 Lifetime 310 This is the minimum period before a refresh message is sent in 311 milliseconds. 313 Sub-Objects 315 Two sub-objects are defined 317 Sub-Type Length Value Field 318 -------- ------ ----------- 319 1 4+ Administratively Down IPv4 Nodes 320 2 16+ Administratively Down IPv6 Nodes 322 4.1. Administratively Down IPv4 Nodes 324 The Administratively Down IPv4 Nodes sub-object is used to suppress 325 alarms from specific nodes. 327 0 1 2 3 328 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | IPv4 Address | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Additional IPv4 Address | 333 . . 334 . . 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 4.2. Administratively Down IPv6 Nodes 340 The Administratively Down IPv6 Nodes sub-object is used to suppress 341 alarms from specific nodes. 343 0 1 2 3 344 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | IPv6 prefix | 347 | (16 octets) | 348 | | 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Additional IPv6 Address | 352 . . 353 . . 354 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 5. Security Considerations 359 Security considerations discussed in [BFD], [BFD-MHOP] and 360 [RFC4379] 361 apply to this document. 363 6. IANA Considerations 365 This document makes the following codepoint assignments from the LSP 366 Ping Object Type registry (pending IANA action): 368 Object Codepoint 369 Sub-objects 371 Connectivity Verification Session tba 372 Administratively Down IPv4 Nodes 1 373 Administratively Down IPv6 Nodes 2 375 7. Acknowledgments 377 The authors would like to thank Dave Katz, Dave Ward, and Vanson Lim 378 for their comments and suggestions. 380 8. References 382 8.1. Normative References 384 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 385 Label Switched (MPLS) Data Plane Failures", RFC 4379, 386 February 2006. 388 [BFD-MCST] Katz, D. and D. Ward, "BFD for Multipoint Networks", 389 draft-katz-ward-bfd-multipoint-00.txt, February 2007. 391 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding 392 Detection", draft-ietf-bfd-base-05.txt, June 2006. 394 [BFD-MHOP] D. Katz, D. Ward, "BFD for Multihop Paths", 395 draft-ietf-bfd-multihop-04.txt, June 2006. 397 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 [MCSTPING] Farrel, A. et al, "Detecting Data Plane Failures in 401 Point-to-Multipoint MPLS Traffic Engineering - 402 Extensions to LSP Ping", 403 draft-ietf-mpls-p2mp-lsp-ping-02.txt, September 2006. 405 8.2. Informative References 407 [MPLS-BFD] Aggarwal, R., et al., "BFD For MPLS LSPs", 408 draft-ietf-bfd-mpls-03.txt, June 2006. 410 9. Authors' Addresses 412 George Swallow 413 Cisco Systems, Inc. 415 Email: swallow@cisco.com 417 Tom Nadeau 418 Cisco Systems, Inc. 420 Email: tnadeau@cisco.com 422 Rahul Aggarwal 423 Juniper Networks, Inc. 425 Email: rahul@juniper.net 427 Intellectual Property 429 The IETF takes no position regarding the validity or scope of any 430 Intellectual Property Rights or other rights that might be claimed to 431 pertain to the implementation or use of the technology described in 432 this document or the extent to which any license under such rights 433 might or might not be available; nor does it represent that it has 434 made any independent effort to identify any such rights. Information 435 on the procedures with respect to rights in RFC documents can be 436 found in BCP 78 and BCP 79. 438 Copies of IPR disclosures made to the IETF Secretariat and any assur- 439 ances of licenses to be made available, or the result of an attempt 440 made to obtain a general license or permission for the use of such 441 proprietary rights by implementers or users of this specification can 442 be obtained from the IETF on-line IPR repository at 443 http://www.ietf.org/ipr. 445 The IETF invites any interested party to bring to its attention any 446 copyrights, patents or patent applications, or other proprietary 447 rights that may cover technology that may be required to implement 448 this standard. Please address the information to the IETF at ietf- 449 ipr@ietf.org. 451 Full Copyright Notice 453 Copyright (C) The IETF Trust (2007). This document is subject to the 454 rights, licenses and restrictions contained in BCP 78, and except as 455 set forth therein, the authors retain all their rights. 457 This document and the information contained herein are provided on an 458 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 459 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 460 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 461 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 462 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 463 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 465 Notes: 467 Destination address in CV object 469 The destination address is included to allow out of band pings to 470 solicit responses from individual destinations. Is this desir- 471 able? 473 Alarm mode 475 Would it be useful to have any configuration of alarm mode? 476 I.e. syslog vs NMS. Notification back to the root is covered in 477 BFD-MCST 479 Think about later: 481 Finer control on how individual nodes alarm 483 Individual tails could be configured via LSP Ping so that they 484 never send BFD control packets to the head, even when the head 485 wishes notification of path failure from the tail. Such tails 486 will 487 never be known to the head, but will still be able to detect 488 multipoint path failures from the head. Is such a thing useful? 490 Automatic authentication configuration (is that an oxymoron?) 492 If authentication is in use, all tails must be configured to have 493 a 494 common authentication key in order to receive the multipoint BFD 495 Control packets. The bootstrap *could* be used to configure the 496 BFD auth info, but I'm not at all sure that can be done securely. 498 Updating section needs to have change of FEC covered. 500 Configuration at the egress needs to be discussed.