idnits 2.17.1 draft-ietf-bier-ping-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If Return-Flag=0; BFR MUST release the variables and MUST not send any response to the Initiator. If Return-Flag=1, proceed as below: -- The document date (July 19, 2016) is 2830 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-bier-ospf-bier-extensions' is defined on line 1027, but no explicit reference was found in the text == Unused Reference: 'RFC0792' is defined on line 1050, but no explicit reference was found in the text == Unused Reference: 'RFC6291' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: 'RFC6424' is defined on line 1060, but no explicit reference was found in the text == Unused Reference: 'RFC6425' is defined on line 1065, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-04 == Outdated reference: A later version (-12) exists of draft-ietf-bier-mpls-encapsulation-05 == Outdated reference: A later version (-18) exists of draft-ietf-bier-ospf-bier-extensions-02 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 6424 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Work group N. Kumar 3 Internet-Draft C. Pignataro 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: January 20, 2017 N. Akiya 6 Big Switch Networks 7 L. Zheng 8 M. Chen 9 Huawei Technologies 10 G. Mirsky 11 Ericsson 12 July 19, 2016 14 BIER Ping and Trace 15 draft-ietf-bier-ping-00 17 Abstract 19 Bit Index Explicit Replication (BIER) is an architecture that 20 provides optimal multicast forwarding through a "BIER domain" without 21 requiring intermediate routers to maintain any multicast related per- 22 flow state. BIER also does not require any explicit tree-building 23 protocol for its operation. A multicast data packet enters a BIER 24 domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the 25 BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). 26 The BFIR router adds a BIER header to the packet. The BIER header 27 contains a bit-string in which each bit represents exactly one BFER 28 to forward the packet to. The set of BFERs to which the multicast 29 packet needs to be forwarded is expressed by setting the bits that 30 correspond to those routers in the BIER header. 32 This document describes the mechanism and basic BIER OAM packet 33 format that can be used to perform failure detection and isolation on 34 BIER data plane. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 20, 2017. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Conventions used in this document . . . . . . . . . . . . . . 3 72 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 73 2.2. Requirements notation . . . . . . . . . . . . . . . . . . 4 74 3. BIER OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3.1. BIER OAM message format . . . . . . . . . . . . . . . . . 4 76 3.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.3. BIER OAM TLV . . . . . . . . . . . . . . . . . . . . . . 8 78 3.3.1. Original SI-BitString TLV . . . . . . . . . . . . . . 8 79 3.3.2. Target SI-BitString TLV . . . . . . . . . . . . . . . 9 80 3.3.3. Incoming SI-BitString TLV . . . . . . . . . . . . . . 10 81 3.3.4. Downstream Mapping TLV . . . . . . . . . . . . . . . 11 82 3.3.5. Responder BFER TLV . . . . . . . . . . . . . . . . . 14 83 3.3.6. Responder BFR TLV . . . . . . . . . . . . . . . . . . 15 84 3.3.7. Upstream Interface TLV . . . . . . . . . . . . . . . 15 85 3.3.8. Reply-To TLV . . . . . . . . . . . . . . . . . . . . 16 86 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 4.1. BIER OAM Processing . . . . . . . . . . . . . . . . . . . 17 88 4.2. Per BFER ECMP Discovery . . . . . . . . . . . . . . . . . 17 89 4.3. Sending BIER Echo Request . . . . . . . . . . . . . . . . 18 90 4.4. Receiving BIER Echo Request . . . . . . . . . . . . . . . 19 91 4.5. Sending Echo Reply . . . . . . . . . . . . . . . . . . . 21 92 4.6. Receiving Echo Reply . . . . . . . . . . . . . . . . . . 22 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 94 5.1. Message Types, Reply Modes, Return Codes . . . . . . . . 22 95 5.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 22 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 98 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23 99 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 23 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 101 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 102 9.2. Informative References . . . . . . . . . . . . . . . . . 24 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 105 1. Introduction 107 [I-D.ietf-bier-architecture] introduces and explains BIER 108 architecture that provides optimal multicast forwarding through a 109 "BIER domain" without requiring intermediate routers to maintain any 110 multicast related per-flow state. BIER also does not require any 111 explicit tree-building protocol for its operation. A multicast data 112 packet enters a BIER domain at a "Bit-Forwarding Ingress Router" 113 (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding 114 Egress Routers" (BFERs). The BFIR router adds a BIER header to the 115 packet. The BIER header contains a bit-string in which each bit 116 represents exactly one BFER to forward the packet to. The set of 117 BFERs to which the multicast packet needs to be forwarded is 118 expressed by setting the bits that correspond to those routers in the 119 BIER header. 121 This document describes the mechanism and basic BIER OAM packet 122 format that can be used to perform failure detection and isolation on 123 BIER data plane without any dependency on other layers like IP layer. 125 2. Conventions used in this document 127 2.1. Terminology 129 BFER - Bit Forwarding Egress Router 131 BFIR - Bit Forwarding Ingress Router 133 BIER - Bit Index Explicit Replication 135 ECMP - Equal Cost Multi-Path 137 OAM - Operation, Administration and Maintenance 139 SI - Set Identifier 141 2.2. Requirements notation 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 3. BIER OAM 149 BIER OAM is defined in a way that it stays within BIER layer by 150 following directly the BIER header without mandating the need for IP 151 header. [I-D.ietf-bier-mpls-encapsulation] defines a 4-bit field as 152 "Proto" to identify the payload following BIER header. When the 153 payload is BIER OAM, the "Proto" field will be set to 5 as defined in 154 [I-D.ietf-bier-mpls-encapsulation] 156 3.1. BIER OAM message format 158 The BIER OAM packet header format that follows BIER header is as 159 follows: 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Ver | Message Type | Proto | Reserved | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 ~ Message Type Dependent Data ~ 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Ver 171 Set to 1. 173 Message Type 175 This document defines the following Message Types: 177 Type Value Field 178 -------- --------------- 179 1 BIER Echo Request 180 2 BIER Echo Reply 182 Proto 184 This field is used to define if there is any data packet 185 immediately following the OAM payload which is used for passive 186 OAM functionality. This field is set to 0 if there is no data 187 packet following OAM payload. 189 The Echo Request/Reply header format is as follows: 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Ver | Echo Req/Rep | Proto | Reserved | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | QTF | RTF | Reply mode | Return Code | Return Subcode| 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Sender's Handle | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Sequence Number | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | TimeStamp Sent | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | TimeStamp Sent | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | TimeStamp Received | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | TimeStamp Received | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 ~ TLVs ~ 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Proto 215 Set to 0 for Echo Request/Reply header. 217 QTF 219 Querier Timestamp Format. When set to 2, the Timestamp Sent field 220 is (in seconds and microseconds, according to the Initiator's 221 clock) in NTP format [RFC5905]. When set to 3, the timestamp 222 format is in IEEE 1588-2008 (1588v2) Precision Time Protocol 223 format. Any other value SHOULD be considered as sanity check 224 failure 226 RTF 228 Responder Timestamp Format. When set to 2, the Timestamp Received 229 field is (in seconds and microseconds, according to the 230 Initiator's clock) in NTP format [RFC5905]. When set to 3, the 231 timestamp format is in IEEE 1588-2008 (1588v2) Precision Time 232 Protocol format. Any other value SHOULD be considered as sanity 233 check failure. 235 Reply mode 237 The Reply mode is set to one of the below: 239 Value Meaning 240 -------- --------------- 241 1 Do not Reply 242 2 Reply via IPv4/IPv6 UDP packet. 243 3 Reply via BIER packet 245 When Reply mode is set to 1, the receiver will not send any reply. 246 This is used for unidirectional path validation. The Reply mode by 247 default would be set to 2 and the Responder BFR will encapsulate the 248 Echo reply payload with IP header. When the Initiator intend to 249 validate the return BIER path, the Reply mode is set to 3 so that the 250 Responder BFR will encapsulate the Echo Reply with BIER header. 252 Return Code 254 Set to zero if Type is "BIER Echo Request". Set to one of the 255 value defined in section 3.2, if Type is "BIER Echo Reply". 257 Return subcode 259 To Be updated. 261 Sender's Handle, Sequence number and Timestamp 263 The Sender's Handle is filled by the Initiator, and returned 264 unchanged by responder BFR. This is used for matching the replies 265 to the request. 267 The Sequence number is assigned by the Initiator and can be used 268 to detect any missed replies. 270 The Timestamp Sent is the time when the Echo Request is sent. The 271 TimeStamp Received in Echo Reply is the time (accordingly to 272 responding BFR clock) that the corresponding Echo Request was 273 received. The format depends on the QTF/RTF value. 275 TLVs 277 Carries the TLVs as defined in Section 3.3. 279 3.2. Return Code 281 Responder uses Return Code field to reply with validity check or 282 other error message to Initiator. It does not carry any meaning in 283 Echo Request and MUST be set to zero. 285 The Return Code can be one of the following: 287 Value Value Meaning 288 -------- --------------- 289 0 No return code 290 1 Malformed Echo Request received 291 2 One or more of the TLVs was not understood 292 3 Replying BFR is the only BFER in header Bitstring 293 4 Replying BFR is one of the BFER in header Bitstring 294 5 Packet-Forward-Success 295 6 Invalid Multipath Info Request 296 8 No matching entry in forwarding table. 297 9 Set-Identifier Mismatch 299 "No return code" will be used by Initiator in the Echo Request. This 300 Value MUST NOT be used in Echo Reply. 302 "Malformed Echo Request received" will be used by any BFR if the 303 received Echo Request packet is not properly formatted. 305 When any TLV included in the Echo Request is not understood by 306 receiver, the Return code will be set to "One or more of the TLVs was 307 not understood" carrying the respective TLVs. 309 When the received header BitString in Echo Request packet contains 310 only its own Bit-ID, "Replying BFR is the only BFER in header 311 BitString" is set in the reply. This implies that the receiver is 312 BFER and the packet is not forwarded to any more neighbors. 314 When the received header BitString in Echo Request packet contains 315 its own Bit-ID in addition to other Bit-IDs, "Replying BFR is one of 316 the BFER in header BitString" is set in the reply. This implies that 317 the responder is a BFER and the packet is further forwarded to one or 318 more neighbors. 320 Any transit BFR will send the Echo Reply with "Packet-Forward- 321 Success", if the TLV in received Echo Request are understood and 322 forwarding table have forwarding entries for the BitString. This is 323 used by transit BFR during traceroute mode. 325 When Echo Request is received with multipath info for more than one 326 BFER, the return-code is set to "Invalid Multipath Info Request". 328 If the receiving BFER does not have any state entry in Overlay 329 Multicast table. For example, if there is no Opaque value in mLDP 330 table or S,G entry in respective PIM table, the return-code is set to 331 "No matching entry in forwarding table". 333 If the BitString cannot be matched in local forwarding table, the BFR 334 will use "No matching entry in forwarding table" in the reply. 336 If the BIER-MPLS label in received Echo Request is not the one 337 assigned for SI in Original SI-BitString TLV, "Set-Identifier 338 Mismatch" is set inorder to report the mismatch. 340 3.3. BIER OAM TLV 342 This section defines various TLVs that can be used in BIER OAM 343 packet. The TLVs (Type-Length-Value tuples) have the following 344 format: 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type | Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | | 352 ~ Value ~ 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 TLV Types are defined below; Length is the length of the Value field 357 in octets. The Value field depends on the TLV Type. 359 3.3.1. Original SI-BitString TLV 361 The Original SI-BitString TLV carries the set of BFER and carries the 362 same BitString that Initiator includes in BIER header.This TLV has 363 the following format: 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Type = 1 | Length = variable | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Set ID | Sub-domain ID |BS Len| Reserved | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | BitString (first 32 bits) ~ 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 ~ ~ 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | BitString (last 32 bits) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Set ID field is set to the Set Identifier to which the BitString 380 belongs to. This value is derived as defined in section 3 of 381 [I-D.ietf-bier-architecture] 383 Sub-domain ID is set to the Sub domain value to which BFER in 384 BitString belongs to. 386 BS Len is set based on the length of BitString as defined in section 387 3 of [I-D.ietf-bier-mpls-encapsulation] 389 The BitString field carries the set of BFR-IDs that Initiator will 390 include in the BIER header. This TLV MUST be included by Initiator 391 in Echo Request packet 393 3.3.2. Target SI-BitString TLV 395 The Target SI-BitString TLV carries the set of BFER from which the 396 Initiator expects the reply from.This TLV has the following format: 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Type = 2 | Length = variable | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Set ID | Sub-domain ID |BS Len| Reserved | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | BitString (first 32 bits) ~ 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 ~ ~ 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | BitString (last 32 bits) | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 Set ID field is set to the Set Identifier to which the BitString 413 belongs to. This value is derived as defined in section 3 of 414 [I-D.ietf-bier-architecture] 416 Sub-domain ID is set to the Sub domain value to which BFER in 417 BitString belongs to. 419 BS Len is set based on the length of BitString as defined in section 420 3 of [I-D.ietf-bier-mpls-encapsulation] 422 The BitString field carries the set of BFR-IDs of BFER(s) that 423 Initiator expects the response from. The BitString in this TLV may 424 be different from the BitString in BIER header and allows to control 425 the BFER responding to the Echo Request. This TLV MUST be included 426 by Initiator in BIER OAM packet if the Downstream Mapping TLV 427 (section 3.3.4) is included. 429 3.3.3. Incoming SI-BitString TLV 431 The Incoming SI-BitString TLV will be included by Responder BFR in 432 Reply message and copies the BitString from BIER header of incoming 433 Echo Request message. This TLV has the following format: 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Type = 3 | Length = variable | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Set ID | Sub-domain ID |BS Len| Reserved | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | BitString (first 32 bits) ~ 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 ~ ~ 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | BitString (last 32 bits) | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 Set ID field is set to the Set Identifier to which the BitString 450 belongs to. This value is derived as defined in section 3 of 451 [I-D.ietf-bier-architecture] 453 Sub-domain ID is set to the Sub domain value to which BFER in 454 BitString belongs to. 456 BS Len is set based on the length of BitString as defined in section 457 3 of [I-D.ietf-bier-mpls-encapsulation] 459 The BitString field copies the BitString from BIER header of the 460 incoming Echo Request. A Responder BFR SHOULD include this TLV in 461 Echo Reply if the Echo Request is received with I flag set in 462 Downstream Mapping TLV. 464 An Initiator MUST NOT include this TLV in Echo Request. 466 3.3.4. Downstream Mapping TLV 468 This TLV has the following format: 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Type = 4 | Length = variable | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | MTU | Address Type | Flags | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Downstream Address (4 or 16 octets) | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Downstream Interface Address (4 or 16 octets) | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Sub-tlv Length | | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 483 . . 484 . List of Sub-TLVs . 485 . . 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 MTU 490 Set to MTU value of outgoing interface. 492 Address Type 494 The Address Type indicates the address type and length of IP 495 address for downstream interface. The Address type is set to one 496 of the below: 498 Type Addr. Type DA Length DIA Length 499 ------- --------------- ---------- ---------- 500 1 IPv4 Numbered 4 4 501 2 IPv4 Unnumbered 4 4 502 3 IPv6 Numbered 16 16 503 4 IPv6 Unnumbered 16 4 505 DA Length - Downstream Address field Length 506 DIA Length - Downstream Interface Address field Length 508 Flags 510 The Flags field has the following format: 512 0 1 2 3 4 5 6 7 513 +-+-+-+-+-+-+-+-+ 514 | Rsvd |I| 515 +-+-+-+-+-+-+-+-+ 517 When I flag is set, the Responding BFR SHOULD include the Incoming 518 SI-BitString TLV in Echo Reply message. 520 Downstream Address and Downstream Interface Address 522 If the Address Type is 1, the Downstream Address MUST be set to 523 IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address 524 is set to downstream interface address. 526 If the Address Type is 2, the Downstream Address MUST be set to 527 IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address 528 is set to the index assigned by upstream BFR to the interface. 530 If the Address Type is 3, the Downstream Address MUST be set to 531 IPV6 BFR-Prefix of downstream BFR and Downstream Interface Address 532 is set to downstream interface address. 534 If the Address Type is 4, the Downstream Address MUST be set to 535 IPv6 BFR-Prefix of downstream BFR and Downstream Interface Address 536 is set to index assigned by upstream BFR to the interface. 538 3.3.4.1. Downstream Detailed Mapping Sub-TLVs 540 This section defines the optional Sub-TLVs that can be included in 541 Downstream Mapping TLV. 543 Sub-TLV Type Value 544 --------------- -------------- 545 1 Multipath Entropy Data 546 2 Egress BitString 548 3.3.4.1.1. Multipath Entropy Data 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 |M| Reserved | | 554 +-+-+-+-+-+-+-+-+-+ | 555 | | 556 | (Multipath Information) | 557 | | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 M Flag 561 This flag is set to 0 if all packets will be forwarded out through 562 interface defined in Downstream Mapping TLV. When set to 1, 563 Multipath Information will be defined with Bit masked Entropy 564 data. 566 Multipath Information 568 Entropy Data encoded as defined in section x3. 570 3.3.4.1.2. Egress BitString 572 This Sub-TLV MAY be included by Responder BFR with the rewritten 573 BitString in outgoing interface as defined in section 6.1 of 574 [I-D.ietf-bier-architecture] 576 0 1 2 3 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Set ID | Sub-domain ID |BS Len| Reserved | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | BitString (first 32 bits) ~ 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 ~ ~ 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | BitString (last 32 bits) | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 3.3.5. Responder BFER TLV 589 The Responder BFER TLV will be included by the BFER replying to the 590 request. This is used to identify the originator of BIER Echo Reply. 591 This TLV have the following format: 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Type = 5 | Length | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Reserved | BFR-ID | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 BFR-ID 603 The BFR-ID field carries the BFR-ID of replying BFER. This TLV 604 MAY be included by Responding BFER in BIER Echo Reply packet. 606 3.3.6. Responder BFR TLV 608 The Responder BFR TLV will be included by the transit BFR replying to 609 the request. This is used to identify the replying BFR without BFR- 610 ID. This TLV have the following format: 612 0 1 2 3 613 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 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | TLV Type = 6 | Length = variable | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Reserved | Address Type | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | | 620 ~ BFR-Prefix (4 or 16 bytes) ~ 621 | | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 Length 626 The Length field varies depending on the Address Type. 628 Address Type 630 Set to 1 for IPv4 or 2 for IPv6. 632 BFR-Prefix 634 Carries the local BFR-Prefix of the replying BFR. This TLV MAY be 635 included by Responding BFR in BIER Echo Reply packet. 637 3.3.7. Upstream Interface TLV 639 The Upstream Interface TLV will be included by the replying BFR in 640 Echo Reply. This is used to identify the incoming interface and the 641 BIER-MPLS label in the incoming Echo Request. This TLV have the 642 following format: 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | TLV Type = 7 | Length = variable | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Reserved | Address Type | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | | 652 ~ Upstream Address (4 or 16 bytes) ~ 653 | | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Length 658 The Length field varies depending on the Address Type. 660 Address Type 662 Set to 1 for IPv4 numbered, 2 for IPv4 Unnumbered 3 for IPv6 663 numbered or 4 for IPv6 Unnumbered. 665 Upstream Address 667 As defined in Section 3.3.4 669 3.3.8. Reply-To TLV 671 The Reply-To TLV MAY be included by the Initiator BFR in Echo 672 Request. This is used by transit BFR or BFER when the reply mode is 673 2. The IP address will be used to generate Echo Reply. This TLV 674 have the following format: 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | TLV Type = 8 | Length = variable | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Reserved | Address Type | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | | 684 ~ Reply-To Address (4 or 16 bytes) ~ 685 | | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Length 690 The Length field varies depending on the Address Type. 692 Address Type 694 Set to 1 for IPv4 or 2 for IPv6. 696 Reply-To Address 698 Set to any locally configured address to which the Echo reply 699 should be sent to. 701 4. Procedures 703 This section describes aspects of Ping and traceroute operations. 704 While this document explains the behavior when Reply mode is "Reply 705 via BIER packet", the future version will be updated with details 706 about the format when the reply mode is "Reply via IP/UDP packet". 708 4.1. BIER OAM Processing 710 A BIER OAM packet MUST be sent to BIER control plane for OAM 711 processing if one of the following conditions is true: 713 o The receiving BFR is a BFER. 715 o TTL of BIER-MPLS Label expired. 717 o Presence of Router Alert label in the label stack. 719 4.2. Per BFER ECMP Discovery 721 As defined in [I-D.ietf-bier-architecture], BIER follows unicast 722 forwarding path and allows load balancing over ECMP paths between 723 BFIR and BFER. BIER OAM MUST support ECMP path discovery between a 724 BFIR and a given BFER and MUST support path validation and failure 725 detection of any particular ECMP path between BFIR and BFER. 727 [I-D.ietf-bier-mpls-encapsulation] proposes the BIER header with 728 Entropy field that can be leveraged to exercise all ECMP paths. 729 Initiator/BFIR will use traceroute message to query each hop about 730 the Entropy information for each downstream paths. To avoid 731 complexity, it is suggested that the ECMP query is performed per BFER 732 by carrying required information in BIER OAM message. 734 Initiator MUST include Multipath Entropy Data Sub-TLV in Downstream 735 Mapping TLV. It MUST also include the BFER in BitString TLV to which 736 the Multipath query is performed. 738 Any transit BFR will reply back with Bit-masked Entropy for each 739 downstream path as defined in [RFC4379] 741 4.3. Sending BIER Echo Request 743 Initiator MUST set the Message Type as 1 and Return Code as 0. The 744 Proto field in OAM packet MUST be set to 0. The choice of Sender's 745 Handle and Sequence number is a local matter to Initiator and SHOULD 746 increment the Sequence number by 1 for every subsequent Echo Request. 747 The QTF field is set to Initiator's local timestamp format and 748 TimeStamp Sent field is set to the time that the Echo Request is 749 sent. 751 Initiator MUST include Original SI-BitString TLV. Initiator MUST NOT 752 include more than one Original SI-BitString TLV. Initiator infers 753 the Set Identifier value and Sub-domain ID value from the respective 754 BitString that will be included in BIER header of the packet and 755 includes the values in "SI" and Sub-Domain ID fields respectively. 757 In Ping mode, Initiator MAY include Target SI-BitString TLV to 758 control the responding BFER(s) by listing all the BFERs from which 759 the Initiator expects a response. In trace route mode, Initiator MAY 760 include Target SI-Bitstring TLV to control the path trace towards any 761 specific BFER or set of BFERs. Initiator on receiving a reply with 762 Return code as "Replying BFR is the only BFER in header Bitstring" or 763 "Replying router is one of the BFER in header Bitstring", SHOULD 764 unset the respective BFR-id from Target SI-BitString for any 765 subsequent Echo Request. 767 When the Reply mode is set to 2, Initiator MUST include Reply-To TLV 768 (section 3.3.8) in the Echo Request. Initiator MUST also listen to 769 the UDP port defined in this TLV and process any segment received 770 with destination port as value defined in the TLV and sent to control 771 plane for BIER OAM payload processing. 773 Initiator MAY include Downstream Mapping TLV (section 3.3.4) in the 774 Echo Request to query additional information from transit BFRs and 775 BFERs. In case of ECMP discovery, Initiator MUST include the 776 Multipath Entropy Data Sub-TLV and SHOULD set the Target SI-BitString 777 TLV carrying a specific BFER id. 779 Initiator MUST encapsulate the OAM packet with BIER header and MUST 780 set the Proto as 5 and further encapsulates with BIER-MPLS label. In 781 ping mode, the BIER-MPLS Label TTL MUST be set to 255. In traceroute 782 mode, the BIER-MPLS Label TTL is set successively starting from 1 and 783 MUST stop sending the Echo Request if it receives a reply with Return 784 code as "Replying router is the only BFER in BIER header Bitstring" 785 from all BFER listed in Target SI-BitString TLV. 787 4.4. Receiving BIER Echo Request 789 Sending a BIER OAM Echo Request to control plane for payload 790 processing is triggered as mentioned in section 4.1. 792 Any BFR on receiving Echo Request MUST send Echo Reply with Return 793 Code set to "Malformed Echo Request received", if the packet fails 794 sanity check. If the packet sanity check is fine, it SHOULD 795 initiates the below set of variables: 797 Reply-Flag 799 This flag is initially set to 1. 801 Interface-I 803 The incoming interface on which the Echo Request was received. 804 This may be used to validate the DDMAP info and to populate the 805 Upstream Interface TLV. 807 BIER-Label-L 809 The BIER-MPLS Label received as the top label on received Echo 810 Request. This may be used to validate if the packet is traversing 811 the desired Set Identifier and sub-domain path. 813 Header-H 815 The BIER header from the received Echo Request. This may be used 816 to validate the DDMAP info and to populate the Incoming SI- 817 BitString TLV. In addition, it can be used to perform Entropy 818 calculation considering different field in header and reply via 819 Multipath Entropy Data Sub-TLV. 821 BFR MUST initialize Best-return-code variable to null value. 823 BFR will populate Interface-I with interface over which the Echo 824 Request is received, top label in the MPLS stack of the received Echo 825 Request to BIER-Label-L, and the BIER header to BIER-Header. If the 826 received Echo Request carries Target SI-BitString TLV, a BFR SHOULD 827 run boolean NAD operation between BitString in Header-H and BitString 828 in Target SI-BitString TLV. If the resulting BitString is all-zero, 829 reset Return-Flag=0 and go to section 4.5. Else: 831 o If the BIER-Label-L does not correspond to the local label 832 assigned for {sub-domain, BitStringLen, SI} in Original SI- 833 BitString TLV, Set the Best-return-code to "Set-Identifier 834 Mismatch" and Go to section 4.5. 836 * /* This detects any BIER-Label to {sub-domain, BitStringLen, 837 SI} synchronization problem in the upstream BFR causing any 838 unintended packet leak between sub-domains */ 840 o Set the Best-return-code to "One or more of the TLVs was not 841 understood", if any of the TLVs in Echo Request message is not 842 understood. Go to section 4.5. 844 o If the BitString in Header-H does not match the BitString in 845 Egress BitString Sub-TLV of DDMAP TLV, set the Best-return-code to 846 ERR-TBD. When there are more than one DDMAP TLV in the received 847 Request packet, the Downstream Address and Downstream Interface 848 Address should be matched with Interface-I to identify the right 849 DDMAP TLV and then perform the BitString match. 851 * /* This detects any deviation between in BIER control plane and 852 BIER forwarding plane in the previous hop that may result in 853 loop or packet duplication. */ 855 o Set the Best-return-code to "Invalid Multipath Info Request", when 856 the DDMAP TLV carries Multipath Entropy Data Sub-TLV and if the 857 Target SI-BitString TLV in the received Echo Request carries more 858 than 1 BFER id. Go to section 4.5. Else, list the ECMP 859 downstream neighbors to reach BFR-id in Target SI-BitString TLV, 860 calculate the Entropy considering the BitString in Header-H and 861 Multipath Entropy Data Sub-TLV from received Echo Request. Store 862 the Data for each Downstream interface in temporary variable. Set 863 the Best-return-code to 5 (Packet-Forward-Success) and goto 864 Section 4.5 866 * /* This instructs to calculate the Entropy Data for each 867 downstream interface to reach the BFER in Target SI-BitString 868 TLV by considering the incoming BitString and Entropy Data.*/ 870 o Set the Best-return-code to "Replying router is the only BFER in 871 BIER header Bitstring", and go to section 4.5 if the responder is 872 BFER and there is no more bits in BIER header Bitstring left for 873 forwarding. 875 o Set the Best-return-code to "Replying router is one of the BFER in 876 BIER header Bitstring", and include Downstream Mapping TLV, if the 877 responder is BFER and there are more bits in BitString left for 878 forwarding. In addition, include the Multipath information as 879 defined in Section 4.2 if the received Echo Request carries 880 Multipath Entropy Data Sub-TLV. Go to section 4.5. 882 o Set the Best-return-code to "No matching entry in forwarding 883 table", if the forwarding lookup defined in section 6.5 of 885 [I-D.ietf-bier-architecture] does not match any entry for the 886 received BitString in BIER header. 888 * /* This detects any missing BFR-id in the BIER forwarding 889 table. It could be noted that it is difficult to detect such 890 missing BFR-id while sending the Request with more than one 891 BFR-id in BitString and so may need to just include the BFER id 892 that is not responding to detect such failure.*/ 894 o Set the Best-return-code to "Packet-Forward-Success", and include 895 Downstream Mapping TLV. Go to section 4.5 897 4.5. Sending Echo Reply 899 If Return-Flag=0; BFR MUST release the variables and MUST not send 900 any response to the Initiator. If Return-Flag=1, proceed as below: 902 The Responder BFR SHOULD include the BitString from Header-H to 903 Incoming SI-BitString TLV and include the Set ID, Sub-domain ID and 904 BS Len corresponding to BIER-Label-L. Responder BFR SHOULD include 905 the Upstream Interface TLV and populate the address from Interface-I. 907 When the Best-return-code is "Replying BFR is one of the BFER in 908 header Bitstring", it MUST include Responder BFER TLV. 910 If the received Echo Request had DDMAP with Multipath Entropy Data 911 Sub-TLV, Responder BFR MUST include DDMAP as defined in 912 Section 3.3.4 for each outgoing interface over which the packet 913 will be replicated and include the respective Multipath Entropy 914 Data Sub-TLV. For each outgoing interface, respective Egress 915 BitString MUST be included in DDMAP TLV. 917 If the received Echo Request had DDMAP without Multipath Entropy 918 Data Sub-TLV, Responder BFR MUST include DDMAP as defined in 919 Section 3.3.4 for each outgoing interface over which the packet 920 will be replicated. For each outgoing interface, respective 921 Egress BitString MUST be included in DDMAP TLV. 923 When the Best-return-code is "Replying BFR is the only BFER in header 924 Bitstring", it MUST include Responder BFER TLV. 926 Responder MUST set the Message Type as 2 and Return Code as Best- 927 return-code. The Proto field MUST be set to 0. 929 The Echo Reply can be sent either as BIER-encapsulated or IP/UDP 930 encapsulated depending on the Reply mode in received Echo Request. 931 When the Reply mode in received Echo Request is set to 3, Responder 932 appends BIER header listing the BitString with BFIR ID (from Header- 933 H), set the Proto to 5 and set the BFIR as 0. When the Reply mode in 934 received Echo Request is set to 2, Responder encapsulates with IP/UDP 935 header. The UDP destination port MUST be set to TBD1 and source port 936 MAY be set to TBD1 or other random local value. The source IP is any 937 local address of the responder and destiantion IP is derived from 938 Reply-To TLV. 940 4.6. Receiving Echo Reply 942 Initiator on receiving Echo Reply will use the Sender's Handle to 943 match with Echo Request sent. If no match is found, Initiator MUST 944 ignore the Echo Reply. 946 If receiving Echo Reply have Downstream Mapping, Initiator SHOULD 947 copy the same to subsequent Echo Request(s). 949 If one of the Echo Reply is received with Return Code as "Replying 950 BFR is one of the BFER in header Bitstring", it SHOULD reset the BFR- 951 id of the responder from Target SI-BisString TLV in subsequent Echo 952 Request. 954 /* This helps avoiding any BFR that is both BFER and also transit 955 BFR to continuously responding with Echo Reply.*/ 957 5. IANA Considerations 959 This document request UDP port TBD1 to be allocated by IANA for BIER 960 Echo. 962 This document request the IANA for creation and management of below 963 registries: 965 5.1. Message Types, Reply Modes, Return Codes 967 This document request to assign the Message Types and Reply mode 968 mentioned in section 3.1, , Return code mentioned in Section 3.2. 970 5.2. TLVs 972 The TLVs and Sub-TLVs defined in this document is not limited to Echo 973 Request or Reply message types and is applicable for other message 974 types. The TLVs and Sub-TLVs requested by this document for IANA 975 consideration are the following: 977 Type Sub-Type Value Field 978 ------- -------- ----------- 979 1 Original SI-BitString 980 2 Target SI-BitString 981 3 Incoming SI-BitString 982 4 Downstream Mapping 983 4 1 Multipath Entropy Data 984 4 2 Egress BitString 985 5 Responder BFER 986 6 Responder BFR 987 7 Upstream Interface 989 6. Security Considerations 991 The security consideration for BIER Ping is similar to ICMP or LSP 992 Ping. AS like ICMP or LSP ping, BFR may be exposed to Denial-of- 993 service attacks and it is RECOMMENDED to regulate the BIER Ping 994 packet flow to control plane. A rate limiter SHOULD be applied to 995 avoid any attack. 997 As like ICMP or LSP Ping, a traceroute can be used to obtain network 998 information. It is RECOMMENDED that the implementation check the 999 integrity of BFIR of the Echo messages against any local secured list 1000 before processing the message further 1002 7. Acknowledgement 1004 The authors would like to thank Antoni Przygienda, Eric Rosen, Faisal 1005 Iqbal and Jeffrey (Zhaohui) Zhang for thier review and comments. 1007 8. Contributing Authors 1009 TBD 1011 9. References 1013 9.1. Normative References 1015 [I-D.ietf-bier-architecture] 1016 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 1017 S. Aldrin, "Multicast using Bit Index Explicit 1018 Replication", draft-ietf-bier-architecture-04 (work in 1019 progress), July 2016. 1021 [I-D.ietf-bier-mpls-encapsulation] 1022 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., 1023 Aldrin, S., and I. Meilik, "Encapsulation for Bit Index 1024 Explicit Replication in MPLS Networks", draft-ietf-bier- 1025 mpls-encapsulation-05 (work in progress), July 2016. 1027 [I-D.ietf-bier-ospf-bier-extensions] 1028 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 1029 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 1030 for BIER", draft-ietf-bier-ospf-bier-extensions-02 (work 1031 in progress), March 2016. 1033 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1034 Requirement Levels", BCP 14, RFC 2119, 1035 DOI 10.17487/RFC2119, March 1997, 1036 . 1038 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1039 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1040 DOI 10.17487/RFC4379, February 2006, 1041 . 1043 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1044 "Network Time Protocol Version 4: Protocol and Algorithms 1045 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1046 . 1048 9.2. Informative References 1050 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1051 RFC 792, DOI 10.17487/RFC0792, September 1981, 1052 . 1054 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 1055 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 1056 Acronym in the IETF", BCP 161, RFC 6291, 1057 DOI 10.17487/RFC6291, June 2011, 1058 . 1060 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 1061 Performing Label Switched Path Ping (LSP Ping) over MPLS 1062 Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, 1063 . 1065 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 1066 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 1067 Failures in Point-to-Multipoint MPLS - Extensions to LSP 1068 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 1069 . 1071 Authors' Addresses 1073 Nagendra Kumar 1074 Cisco Systems, Inc. 1075 7200 Kit Creek Road 1076 Research Triangle Park, NC 27709 1077 US 1079 Email: naikumar@cisco.com 1081 Carlos Pignataro 1082 Cisco Systems, Inc. 1083 7200 Kit Creek Road 1084 Research Triangle Park, NC 27709-4987 1085 US 1087 Email: cpignata@cisco.com 1089 Nobo Akiya 1090 Big Switch Networks 1091 Japan 1093 Email: nobo.akiya.dev@gmail.com 1095 Lianshu Zheng 1096 Huawei Technologies 1097 China 1099 Email: vero.zheng@huawei.com 1101 Mach Chen 1102 Huawei Technologies 1104 Email: mach.chen@huawei.com 1105 Greg Mirsky 1106 Ericsson 1108 Email: gregory.mirsky@ericsson.com