idnits 2.17.1 draft-ietf-bier-ping-06.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 Reply-Flag=0; BFR MUST release the variables and MUST not send any response to the Initiator. If Reply-Flag=1, proceed as below: -- The document date (October 31, 2019) is 1637 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: 'RFC0792' is defined on line 1061, but no explicit reference was found in the text == Unused Reference: 'RFC6291' is defined on line 1065, but no explicit reference was found in the text == Unused Reference: 'RFC6424' is defined on line 1071, but no explicit reference was found in the text == Unused Reference: 'RFC6425' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: 'RFC8444' is defined on line 1082, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6424 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 7 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: May 3, 2020 N. Akiya 6 Big Switch Networks 7 L. Zheng 8 M. Chen 9 Huawei Technologies 10 G. Mirsky 11 ZTE Corp. 12 October 31, 2019 14 BIER Ping and Trace 15 draft-ietf-bier-ping-06 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 https://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 May 3, 2020. 53 Copyright Notice 55 Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . 14 84 3.3.7. Upstream Interface TLV . . . . . . . . . . . . . . . 15 85 3.3.8. Reply-To TLV . . . . . . . . . . . . . . . . . . . . 15 86 3.4. Multipath Entropy Data Encoding . . . . . . . . . . . . . 16 87 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 4.1. BIER OAM Processing . . . . . . . . . . . . . . . . . . . 16 89 4.2. Per BFER ECMP Discovery . . . . . . . . . . . . . . . . . 17 90 4.3. Sending BIER Echo Request . . . . . . . . . . . . . . . . 17 91 4.4. Receiving BIER Echo Request . . . . . . . . . . . . . . . 18 92 4.5. Sending Echo Reply . . . . . . . . . . . . . . . . . . . 20 93 4.6. Receiving Echo Reply . . . . . . . . . . . . . . . . . . 21 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 95 5.1. BIER OAM Registry . . . . . . . . . . . . . . . . . . . . 22 96 5.2. Message Types, Reply Modes, Return Codes . . . . . . . . 22 97 5.3. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 22 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 99 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 101 8.1. Normative References . . . . . . . . . . . . . . . . . . 23 102 8.2. Informative References . . . . . . . . . . . . . . . . . 24 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 105 1. Introduction 107 [RFC8279] introduces and explains BIER architecture that provides 108 optimal multicast forwarding through a "BIER domain" without 109 requiring intermediate routers to maintain any multicast related per- 110 flow state. BIER also does not require any explicit tree-building 111 protocol for its operation. A multicast data packet enters a BIER 112 domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the 113 BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). 114 The BFIR router adds a BIER header to the packet. The BIER header 115 contains a bit-string in which each bit represents exactly one BFER 116 to forward the packet to. The set of BFERs to which the multicast 117 packet needs to be forwarded is expressed by setting the bits that 118 correspond to those routers in the BIER header. 120 This document describes the mechanism and basic BIER OAM packet 121 format that can be used to perform failure detection and isolation on 122 BIER data plane without any dependency on other layers like IP layer. 124 2. Conventions used in this document 126 2.1. Terminology 128 BFER - Bit Forwarding Egress Router 130 BFIR - Bit Forwarding Ingress Router 132 BIER - Bit Index Explicit Replication 134 ECMP - Equal Cost Multi-Path 136 OAM - Operation, Administration and Maintenance 138 SI - Set Identifier 140 2.2. Requirements notation 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 3. BIER OAM 148 BIER OAM is defined in a way that it stays within BIER layer by 149 following directly the BIER header without mandating the need for IP 150 header. [RFC8296] defines a 4-bit field as "Proto" to identify the 151 payload following BIER header. When the payload is BIER OAM, the 152 "Proto" field will be set to 5 as defined in [RFC8296] 154 3.1. BIER OAM message format 156 The BIER OAM packet header format that follows BIER header is as 157 follows: 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Ver | Message Type | Proto | Reserved | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | OAM Message Length | 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 OAM Message Length 191 This field defines the length of the OAM message including the 192 header and Dependent Data field. 194 The Echo Request/Reply header format is as follows: 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Ver | Echo Req/Rep | Proto | Reserved | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | QTF | RTF | Reply mode | Return Code | Reserved | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Sender's Handle | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Sequence Number | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | TimeStamp Sent | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | TimeStamp Sent | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | TimeStamp Received | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | TimeStamp Received | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 ~ TLVs ~ 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Proto 220 Set to 0 for Echo Request/Reply header. 222 QTF 224 Querier Timestamp Format. When set to 2, the Timestamp Sent field 225 is (in seconds and microseconds, according to the Initiator's 226 clock) in NTP format [RFC5905]. When set to 3, the timestamp 227 format is in IEEE 1588-2008 (1588v2) Precision Time Protocol 228 format. Any other value SHOULD be considered as sanity check 229 failure 231 RTF 232 Responder Timestamp Format. When set to 2, the Timestamp Received 233 field is (in seconds and microseconds, according to the 234 Initiator's clock) in NTP format [RFC5905]. When set to 3, the 235 timestamp format is in IEEE 1588-2008 (1588v2) Precision Time 236 Protocol format. Any other value SHOULD be considered as sanity 237 check failure. 239 Reply mode 241 The Reply mode is set to one of the below: 243 Value Meaning 244 -------- --------------- 245 1 Do not Reply 246 2 Reply via IPv4/IPv6 UDP packet. 247 3 Reply via BIER packet 249 When Reply mode is set to 1, the receiver will not send any reply. 250 This is used for unidirectional path validation. The Reply mode by 251 default would be set to 2 and the Responder BFR will encapsulate the 252 Echo reply payload with IP header. When the Initiator intend to 253 validate the return BIER path, the Reply mode is set to 3 so that the 254 Responder BFR will encapsulate the Echo Reply with BIER header. 256 Return Code 258 Set to zero if Type is "BIER Echo Request". Set to one of the 259 value defined in section 3.2, if Type is "BIER Echo Reply". 261 Reserved 263 Set to all zero value. 265 Sender's Handle, Sequence number and Timestamp 267 The Sender's Handle is filled by the Initiator, and returned 268 unchanged by responder BFR. This is used for matching the replies 269 to the request. 271 The Sequence number is assigned by the Initiator and can be used 272 to detect any missed replies. 274 The Timestamp Sent is the time when the Echo Request is sent. The 275 TimeStamp Received in Echo Reply is the time (accordingly to 276 responding BFR clock) that the corresponding Echo Request was 277 received. The format depends on the QTF/RTF value. 279 TLVs 280 Carries the TLVs as defined in Section 3.3. 282 3.2. Return Code 284 Responder uses Return Code field to reply with validity check or 285 other error message to Initiator. It does not carry any meaning in 286 Echo Request and MUST be set to zero. 288 The Return Code can be one of the following: 290 Value Value Meaning 291 -------- --------------- 292 0 No return code 293 1 Malformed Echo Request received 294 2 One or more of the TLVs was not understood 295 3 Replying BFR is the only BFER in header Bitstring 296 4 Replying BFR is one of the BFER in header Bitstring 297 5 Packet-Forward-Success 298 6 Invalid Multipath Info Request 299 8 No matching entry in forwarding table. 300 9 Set-Identifier Mismatch 301 10 DDMAP Mismatch 303 "No return code" will be used by Initiator in the Echo Request. This 304 Value MUST NOT be used in Echo Reply. 306 "Malformed Echo Request received" will be used by any BFR if the 307 received Echo Request packet is not properly formatted. 309 When any TLV included in the Echo Request is not understood by 310 receiver, the Return code will be set to "One or more of the TLVs was 311 not understood" carrying the respective TLVs. 313 When the received header BitString in Echo Request packet contains 314 only its own Bit-ID, "Replying BFR is the only BFER in header 315 BitString" is set in the reply. This implies that the receiver is 316 BFER and the packet is not forwarded to any more neighbors. 318 When the received header BitString in Echo Request packet contains 319 its own Bit-ID in addition to other Bit-IDs, "Replying BFR is one of 320 the BFER in header BitString" is set in the reply. This implies that 321 the responder is a BFER and the packet is further forwarded to one or 322 more neighbors. 324 Any transit BFR will send the Echo Reply with "Packet-Forward- 325 Success", if the TLV in received Echo Request are understood and 326 forwarding table have forwarding entries for the BitString. This is 327 used by transit BFR during traceroute mode. 329 When Echo Request is received with multipath info for more than one 330 BFER, the return-code is set to "Invalid Multipath Info Request". 332 If the BitString cannot be matched in local forwarding table, the BFR 333 will use "No matching entry in forwarding table" in the reply. 335 If the BIER-MPLS label in received Echo Request is not the one 336 assigned for SI in Original SI-BitString TLV, "Set-Identifier 337 Mismatch" is set inorder to report the mismatch. 339 3.3. BIER OAM TLV 341 This section defines various TLVs that can be used in BIER OAM 342 packet. The TLVs (Type-Length-Value tuples) have the following 343 format: 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Type | Length | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | 351 ~ Value ~ 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 TLV Types are defined below; Length is the length of the Value field 356 in octets. The Value field depends on the TLV Type. 358 3.3.1. Original SI-BitString TLV 360 The Original SI-BitString TLV carries the set of BFER and carries the 361 same BitString that Initiator includes in BIER header.This TLV has 362 the following format: 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type = 1 | Length = variable | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Set ID | Sub-domain ID |BS Len| Reserved | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | BitString (first 32 bits) ~ 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 ~ ~ 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | BitString (last 32 bits) | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Set ID field is set to the Set Identifier to which the BitString 379 belongs to. This value is derived as defined in [RFC8279] 381 Sub-domain ID is set to the Sub domain value to which BFER in 382 BitString belongs to. 384 BS Len is set based on the length of BitString as defined in 385 [RFC8296] 387 The BitString field carries the set of BFR-IDs that Initiator will 388 include in the BIER header. This TLV MUST be included by Initiator 389 in Echo Request packet 391 3.3.2. Target SI-BitString TLV 393 The Target SI-BitString TLV carries the set of BFER from which the 394 Initiator expects the reply from.This TLV has the following format: 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Type = 2 | Length = variable | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Set ID | Sub-domain ID |BS Len| Reserved | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | BitString (first 32 bits) ~ 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 ~ ~ 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | BitString (last 32 bits) | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Set ID field is set to the Set Identifier to which the BitString 411 belongs to. This value is derived as defined in [RFC8279] 413 Sub-domain ID is set to the Sub domain value to which BFER in 414 BitString belongs to. 416 BS Len is set based on the length of BitString as defined in 417 [RFC8296] 419 The BitString field carries the set of BFR-IDs of BFER(s) that 420 Initiator expects the response from. The BitString in this TLV may 421 be different from the BitString in BIER header and allows to control 422 the BFER responding to the Echo Request. This TLV MUST be included 423 by Initiator in BIER OAM packet if the Downstream Mapping TLV 424 (section 3.3.4) is included. 426 3.3.3. Incoming SI-BitString TLV 428 The Incoming SI-BitString TLV will be included by Responder BFR in 429 Reply message and copies the BitString from BIER header of incoming 430 Echo Request message. This TLV has the following format: 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Type = 3 | Length = variable | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Set ID | Sub-domain ID |BS Len| Reserved | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | BitString (first 32 bits) ~ 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 ~ ~ 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | BitString (last 32 bits) | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Set ID field is set to the Set Identifier to which the BitString 447 belongs to. This value is derived as defined in [RFC8279] 449 Sub-domain ID is set to the Sub domain value to which BFER in 450 BitString belongs to. 452 BS Len is set based on the length of BitString as defined in 453 [RFC8296] 454 The BitString field copies the BitString from BIER header of the 455 incoming Echo Request. A Responder BFR SHOULD include this TLV in 456 Echo Reply if the Echo Request is received with I flag set in 457 Downstream Mapping TLV. 459 An Initiator MUST NOT include this TLV in Echo Request. 461 3.3.4. Downstream Mapping TLV 463 This TLV has the following format: 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Type = 4 | Length = variable | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | MTU | Address Type | Flags | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Downstream Address (4 or 16 octets) | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Downstream Interface Address (4 or 16 octets) | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Sub-tlv Length | | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 478 . . 479 . List of Sub-TLVs . 480 . . 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 MTU 485 Set to MTU value of outgoing interface. 487 Address Type 489 The Address Type indicates the address type and length of IP 490 address for downstream interface. The Address type is set to one 491 of the below: 493 Type Addr. Type DA Length DIA Length 494 ------- --------------- ---------- ---------- 495 1 IPv4 Numbered 4 4 496 2 IPv4 Unnumbered 4 4 497 3 IPv6 Numbered 16 16 498 4 IPv6 Unnumbered 16 4 500 DA Length - Downstream Address field Length 501 DIA Length - Downstream Interface Address field Length 503 Flags 505 The Flags field has the following format: 507 0 1 2 3 4 5 6 7 508 +-+-+-+-+-+-+-+-+ 509 | Rsvd |I| 510 +-+-+-+-+-+-+-+-+ 512 When I flag is set, the Responding BFR MUST include the Incoming SI- 513 BitString TLV in Echo Reply message. 515 Downstream Address and Downstream Interface Address 517 If the Address Type is 1, the Downstream Address MUST be set to 518 IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address 519 is set to downstream interface address. 521 If the Address Type is 2, the Downstream Address MUST be set to 522 IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address 523 is set to the index assigned by upstream BFR to the interface. 525 If the Address Type is 3, the Downstream Address MUST be set to 526 IPV6 BFR-Prefix of downstream BFR and Downstream Interface Address 527 is set to downstream interface address. 529 If the Address Type is 4, the Downstream Address MUST be set to 530 IPv6 BFR-Prefix of downstream BFR and Downstream Interface Address 531 is set to index assigned by upstream BFR to the interface. 533 3.3.4.1. Downstream Detailed Mapping Sub-TLVs 535 This section defines the optional Sub-TLVs that can be included in 536 Downstream Mapping TLV. 538 Sub-TLV Type Value 539 --------------- -------------- 540 1 Multipath Entropy Data 541 2 Egress BitString 543 3.3.4.1.1. Multipath Entropy Data 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 |M| Reserved | | 549 +-+-+-+-+-+-+-+-+-+ | 550 | | 551 | (Multipath Information) | 552 | | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 M Flag 557 This flag is set to 0 if all packets will be forwarded out through 558 the interface defined in the Downstream Mapping TLV. When set to 559 1, Multipath Information will be defined by the Bit masked Entropy 560 data. 562 Multipath Information 564 Entropy Data encoded as defined in section 3.4 566 3.3.4.1.2. Egress BitString 568 Responder BFR MAY include this Sub-TLV with the rewritten BitString 569 in the outgoing interface as defined in section 6.1 of [RFC8279] 571 0 1 2 3 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Set ID | Sub-domain ID |BS Len| Reserved | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | BitString (first 32 bits) ~ 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 ~ ~ 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | BitString (last 32 bits) | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 3.3.5. Responder BFER TLV 584 The BFER replying to the request MAY include the Responder BFER TLV. 585 This is used to identify the originator of BIER Echo Reply. This TLV 586 has the following format: 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Type = 5 | Length | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Reserved | BFR-ID | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 BFR-ID 598 The BFR-ID field carries the BFR-ID of replying BFER. This TLV 599 MAY be included by Responding BFER in BIER Echo Reply packet. 601 3.3.6. Responder BFR TLV 603 Any transit BFR replying to the request MAY include the Responder BFR 604 TLV. This is used to identify the replying BFR without BFR-ID. This 605 TLV has the following format: 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | TLV Type = 6 | Length = variable | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Reserved | Address Type | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | | 615 ~ BFR-Prefix (4 or 16 bytes) ~ 616 | | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 Length 621 The Length field varies depending on the Address Type. 623 Address Type 625 Set to 1 for IPv4 or 2 for IPv6. 627 BFR-Prefix 629 This field carries the local BFR-Prefix of the replying BFR. This 630 TLV MAY be included by Responding BFR in BIER Echo Reply packet. 632 3.3.7. Upstream Interface TLV 634 The BFR replying to the request will include the Upstream Interface 635 TLV. This is used to identify the incoming interface and the BIER- 636 MPLS label in the incoming Echo Request. This TLV has the following 637 format: 639 0 1 2 3 640 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 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | TLV Type = 7 | Length = variable | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Reserved | Address Type | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | | 647 ~ Upstream Address (4 or 16 bytes) ~ 648 | | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 Length 653 The Length field varies depending on the Address Type. 655 Address Type 657 Set to 1 for IPv4 numbered, 2 for IPv4 Unnumbered 3 for IPv6 658 numbered or 4 for IPv6 Unnumbered. 660 Upstream Address 662 As defined in Section 3.3.4 664 3.3.8. Reply-To TLV 666 The Initiator BFR MAY include Reply-To TLV in the Echo Request. This 667 is used by transit BFR or BFER when the reply mode is 2. The IP 668 address will be used to generate the Echo Reply. This TLV has the 669 following format: 671 0 1 2 3 672 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 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | TLV Type = 8 | Length = variable | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Reserved | Address Type | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | | 679 ~ Reply-To Address (4 or 16 bytes) ~ 680 | | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 Length 685 The Length field varies depending on the Address Type. 687 Address Type 689 Set to 1 for IPv4 or 2 for IPv6. 691 Reply-To Address 693 Set to any locally configured address to which the Echo reply 694 should be sent. 696 3.4. Multipath Entropy Data Encoding 698 The size of Entropy field in BIER header is 20 bits as defined in 699 section 2 of [RFC8296]. This is similar to Multipath Type 9 encoding 700 defined in Section 3.4.1.1.1 of [RFC8029]. 702 4. Procedures 704 This section describes aspects of Ping and traceroute operations. 706 4.1. BIER OAM Processing 708 A BIER OAM packet MUST be sent to BIER control plane for OAM 709 processing if one of the following conditions is true: 711 o The receiving BFR is a BFER. 713 o TTL of BIER-MPLS Label expired. 715 o Router Alert label is present in the label stack. 717 4.2. Per BFER ECMP Discovery 719 As defined in [RFC8279], BIER follows the unicast forwarding path and 720 allows load balancing over ECMP paths between BFIR and BFER. BIER 721 OAM MUST support ECMP path discovery between a BFIR and a given BFER 722 and MUST support path validation and failure detection of any 723 particular ECMP path between BFIR and BFER. 725 [RFC8296] proposes the BIER header with Entropy field that can be 726 leveraged to exercise all ECMP paths. The Initiator/BFIR will use 727 traceroute message to query each hop about the Entropy information 728 for each downstream paths. To avoid complexity, it is suggested that 729 the ECMP query is performed per BFER by carrying required information 730 in BIER OAM message. 732 The Initiator MUST include Multipath Entropy Data Sub-TLV in 733 Downstream Mapping TLV. It MUST also include the BFER in BitString 734 TLV to which the Multipath query is performed. 736 Any transit BFR will reply with Bit-masked Entropy for each 737 downstream path as defined in [RFC8029] 739 4.3. Sending BIER Echo Request 741 The Initiator MUST set the Message Type as 1 and Return Code as 0. 742 The Proto field in OAM packet MUST be set to 0. The choice of 743 Sender's Handle and Sequence number is a local matter to the 744 Initiator and SHOULD increment the Sequence number by 1 for every 745 subsequent Echo Request. The QTF field is set to Initiator's local 746 timestamp format and TimeStamp Sent field is set to the time that the 747 Echo Request is sent. 749 The Initiator MUST include Original SI-BitString TLV. The Initiator 750 MUST NOT include more than one Original SI-BitString TLV. The 751 Initiator infers the Set Identifier value and Sub-domain ID value 752 from the respective BitString that will be included in BIER header of 753 the packet and includes the values in "SI" and Sub-Domain ID fields 754 respectively. 756 In Ping mode, the Initiator MAY include Target SI-BitString TLV to 757 control the responding BFER(s) by listing all the BFERs from which 758 the Initiator expects a response. In trace route mode, the Initiator 759 MAY include Target SI-Bitstring TLV to control the path trace towards 760 any specific BFER or set of BFERs. The Initiator on receiving a 761 reply with Return code as "Replying BFR is the only BFER in header 762 Bitstring" or "Replying router is one of the BFER in header 763 Bitstring", SHOULD unset the respective BFR-id from Target SI- 764 BitString for any subsequent Echo Request. 766 When the Reply mode is set to 2, the Initiator MUST include Reply-To 767 TLV (section 3.3.8) in the Echo Request. The Initiator MUST also 768 listen to the UDP port defined in this TLV and process any segment 769 received with destination port as the value defined in the TLV and 770 sent to control plane for BIER OAM payload processing. 772 The Initiator MAY include Downstream Mapping TLV (section 3.3.4) in 773 the Echo Request to query additional information from transit BFRs 774 and BFERs. In case of ECMP discovery, the Initiator MUST include the 775 Multipath Entropy Data Sub-TLV and SHOULD set the Target SI-BitString 776 TLV carrying a specific BFER ID. 778 The Initiator MUST encapsulate the OAM packet with BIER header and 779 MUST set the Proto as 5 and further encapsulates with BIER-MPLS 780 label. In ping mode, the BIER-MPLS Label TTL MUST be set to 255. In 781 traceroute mode, the BIER-MPLS Label TTL is set successively starting 782 from 1 and MUST stop sending the Echo Request if it receives a reply 783 with Return code as "Replying router is the only BFER in BIER header 784 Bitstring" from all BFER listed in Target SI-BitString TLV. 786 4.4. Receiving BIER Echo Request 788 Sending a BIER OAM Echo Request to control plane for payload 789 processing is triggered as mentioned in section 4.1. 791 Any BFR on receiving Echo Request MUST perform the basic sanity 792 check. If the BFR cannot parse the OAM Dependent data payload 793 completely if the OAM Message Length is incorrect. BFR MUST send 794 Echo Reply with Return Code set to "Malformed Echo Request received" 795 if the OAM Message Length is incorrect. If the packet sanity check 796 is fine, it SHOULD initiate the below set of variables: 798 Reply-Flag 800 This flag is initially set to 1. 802 Interface-I 804 The incoming interface on which the Echo Request was received. 805 This may be used to validate the DDMAP info and to populate the 806 Upstream Interface TLV. 808 BIER-Label-L 810 The BIER-MPLS Label received as the top label on received Echo 811 Request. This may be used to validate if the packet is traversing 812 the desired Set Identifier and sub-domain path. 814 Header-H 816 The BIER header from the received Echo Request. This may be used 817 to validate the DDMAP info and to populate the Incoming SI- 818 BitString TLV. Also, it can be used to perform Entropy 819 calculation considering a different field in the header and reply 820 via Multipath Entropy Data Sub-TLV. 822 BFR MUST initialize Best-return-code variable to null value. 824 BFR will populate Interface-I with interface over which the Echo 825 Request is received, the top label in the MPLS stack of the received 826 Echo Request to BIER-Label-L, and the BIER header to BIER-Header. If 827 the received Echo Request carries Target SI-BitString TLV, a BFR 828 SHOULD run boolean AND operation between BitString in Header-H and 829 BitString in Target SI-BitString TLV. If the resulting BitString is 830 all-zero, reset Reply-Flag=0 and go to section 4.5. Else: 832 o If the BIER-Label-L does not correspond to the local label 833 assigned for {sub-domain, BitStringLen, SI} in Original SI- 834 BitString TLV, Set the Best-return-code to "Set-Identifier 835 Mismatch" and Go to section 4.5. 837 * /* This detects any BIER-Label to {sub-domain, BitStringLen, 838 SI} synchronization problem in the upstream BFR causing any 839 unintended packet leak between sub-domains */ 841 o Set the Best-return-code to "One or more of the TLVs was not 842 understood", if any of the TLVs in Echo Request message is not 843 understood. Go to section 4.5. 845 o If the BitString in Header-H does not match the BitString in 846 Egress BitString Sub-TLV of DDMAP TLV, set the Best-return-code to 847 "DDMAP Mismatch" and go to section 4.5. When there are more than 848 one DDMAP TLV in the received Request packet, the Downstream 849 Address and Downstream Interface Address should be matched with 850 Interface-I to identify the right DDMAP TLV and then perform the 851 BitString match. 853 * /* This detects any deviation between in BIER control plane and 854 BIER forwarding plane in the previous hop that may result in 855 loop or packet duplication. */ 857 o Set the Best-return-code to "Invalid Multipath Info Request", when 858 the DDMAP TLV carries Multipath Entropy Data Sub-TLV and if the 859 Target SI-BitString TLV in the received Echo Request carries more 860 than 1 BFER id. Go to section 4.5. Else, list the ECMP 861 downstream neighbors to reach BFR-id in Target SI-BitString TLV, 862 calculate the Entropy considering the BitString in Header-H and 863 Multipath Entropy Data Sub-TLV from received Echo Request. Store 864 the Data for each Downstream interface in a temporary variable. 865 Set the Best-return-code to 5 (Packet-Forward-Success) and goto 866 Section 4.5 868 * /* This instructs to calculate the Entropy Data for each 869 downstream interface to reach the BFER in Target SI-BitString 870 TLV by considering the incoming BitString and Entropy Data.*/ 872 o Set the Best-return-code to "Replying router is the only BFER in 873 BIER header Bitstring", and go to section 4.5 if the responder is 874 BFER and there are no more bits in BIER header Bitstring left for 875 forwarding. 877 o Set the Best-return-code to "Replying router is one of the BFER in 878 BIER header Bitstring", and include Downstream Mapping TLV, if the 879 responder is BFER and there are more bits in BitString left for 880 forwarding. Also, include the Multipath information as defined in 881 Section 4.2 if the received Echo Request carries Multipath Entropy 882 Data Sub-TLV. Go to section 4.5. 884 o Set the Best-return-code to "No matching entry in forwarding 885 table", if the forwarding lookup defined in section 6.5 of 886 [RFC8279] does not match any entry for the received BitString in 887 BIER header. 889 * /* This detects any missing BFR-id in the BIER forwarding 890 table. It could be noted that it is difficult to detect such 891 missing BFR-id while sending the Request with more than one 892 BFR-id in BitString and so may need to include the BFER id that 893 is not responding to detect such failure.*/ 895 o Set the Best-return-code to "Packet-Forward-Success", and include 896 Downstream Mapping TLV. Go to section 4.5 898 4.5. Sending Echo Reply 900 If Reply-Flag=0; BFR MUST release the variables and MUST not send any 901 response to the Initiator. If Reply-Flag=1, proceed as below: 903 The Responder BFR SHOULD include the BitString from Header-H to 904 Incoming SI-BitString TLV and include the Set ID, Sub-domain ID and 905 BS Len that corresponds to BIER-Label-L. Responder BFR SHOULD 906 include the Upstream Interface TLV and populate the address from 907 Interface-I. 909 When the Best-return-code is "Replying BFR is one of the BFER in 910 header Bitstring", it MUST include Responder BFER TLV. 912 If the received Echo Request had DDMAP with Multipath Entropy Data 913 Sub-TLV, Responder BFR MUST include DDMAP as defined in 914 Section 3.3.4 for each outgoing interface over which the packet 915 will be replicated and include the respective Multipath Entropy 916 Data Sub-TLV. For each outgoing interface, respective Egress 917 BitString MUST be included in DDMAP TLV. 919 If the received Echo Request had DDMAP without Multipath Entropy 920 Data Sub-TLV, Responder BFR MUST include DDMAP as defined in 921 Section 3.3.4 for each outgoing interface over which the packet 922 will be replicated. For each outgoing interface, respective 923 Egress BitString MUST be included in DDMAP TLV. 925 When the Best-return-code is "Replying BFR is the only BFER in header 926 Bitstring", it MUST include Responder BFER TLV. 928 Responder MUST set the Message Type as 2 and Return Code as Best- 929 return-code. The Proto field MUST be set to 0. 931 The Echo Reply can be sent either as BIER-encapsulated or IP/UDP 932 encapsulated depending on the Reply mode in received Echo Request. 933 When the Reply mode in received Echo Request is set to 3, Responder 934 appends BIER header listing the BitString with BFIR ID (from Header- 935 H), set the Proto to 5 and set the BFIR as 0. When the Reply mode in 936 received Echo Request is set to 2, Responder encapsulates with IP/UDP 937 header. The UDP destination port MUST be set to TBD1 and source port 938 MAY be set to TBD1 or other random local value. The source IP is any 939 local address of the responder and destination IP is derived from 940 Reply-To TLV. 942 4.6. Receiving Echo Reply 944 The Initiator on receiving Echo Reply will use the Sender's Handle to 945 match with Echo Request sent. If no match is found, the Initiator 946 MUST ignore the Echo Reply. 948 If receiving Echo Reply have Downstream Mapping, the Initiator SHOULD 949 copy the same to subsequent Echo Request(s). 951 If one of the Echo Reply is received with Return Code as "Replying 952 BFR is one of the BFER in header Bitstring", it SHOULD reset the BFR- 953 id of the responder from Target SI-BisString TLV in subsequent Echo 954 Request. 956 /* This helps to avoid any BFR that is both BFER and also transit 957 BFR to continuously responding with Echo Reply.*/ 959 5. IANA Considerations 961 This document request UDP port TBD1 to be allocated by IANA for BIER 962 Echo. 964 This document request the IANA for creation and management of below 965 registries and sub-registries: 967 5.1. BIER OAM Registry 969 IANA is requested to create and maintain "BIER OAM Parameters" 970 registry. 972 5.2. Message Types, Reply Modes, Return Codes 974 IANA is requested to create "Message Type" sub-registry under "BIER 975 OAM Parameters" registry and assign the Message Types defined in 976 section 3.1 978 IANA is requested to also create "Echo Reply Mode" sub-registry under 979 "BIER OAM Parameters" registry and assign the Echo Reply Modes 980 defined in section 3.1 982 IANA is requested to create "Echo Return Codes" sub-registry under 983 "BIER OAM Parameters" registry and assign the Return Codes defined in 984 section 3.2 986 5.3. TLVs 988 The TLVs and Sub-TLVs defined in this document is not limited to Echo 989 Request or Reply message types and is applicable for other message 990 types. The TLVs and Sub-TLVs requested by this document for IANA 991 consideration are the following: 993 Type Sub-Type Value Field 994 ------- -------- ----------- 995 1 Original SI-BitString 996 2 Target SI-BitString 997 3 Incoming SI-BitString 998 4 Downstream Mapping 999 4 1 Multipath Entropy Data 1000 4 2 Egress BitString 1001 5 Responder BFER 1002 6 Responder BFR 1003 7 Upstream Interface 1005 6. Security Considerations 1007 The security consideration for BIER Ping is similar to ICMP or LSP 1008 Ping. As like ICMP or LSP ping, BFR may be exposed to Denial-of- 1009 Service (DoS) attacks and it is RECOMMENDED to regulate the BIER Ping 1010 packet flow to control plane. A rate limiter SHOULD be applied to 1011 avoid any attack. 1013 As like ICMP or LSP Ping, a traceroute can be used to obtain network 1014 information. It is RECOMMENDED that the implementation checks the 1015 integrity of BFIR of the Echo messages against any local secured list 1016 before processing the message further 1018 7. Acknowledgement 1020 The authors would like to thank Antoni Przygienda, Eric Rosen, Faisal 1021 Iqbal Jeffrey (Zhaohui) Zhang and Shell Nakash for their review and 1022 comments. 1024 The authors would like to thank Mankamana Mishra for this thorough 1025 review and comments. 1027 8. References 1029 8.1. Normative References 1031 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1032 Requirement Levels", BCP 14, RFC 2119, 1033 DOI 10.17487/RFC2119, March 1997, 1034 . 1036 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1037 "Network Time Protocol Version 4: Protocol and Algorithms 1038 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1039 . 1041 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 1042 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 1043 Switched (MPLS) Data-Plane Failures", RFC 8029, 1044 DOI 10.17487/RFC8029, March 2017, 1045 . 1047 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1048 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1049 Explicit Replication (BIER)", RFC 8279, 1050 DOI 10.17487/RFC8279, November 2017, 1051 . 1053 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1054 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 1055 for Bit Index Explicit Replication (BIER) in MPLS and Non- 1056 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 1057 2018, . 1059 8.2. Informative References 1061 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1062 RFC 792, DOI 10.17487/RFC0792, September 1981, 1063 . 1065 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 1066 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 1067 Acronym in the IETF", BCP 161, RFC 6291, 1068 DOI 10.17487/RFC6291, June 2011, 1069 . 1071 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 1072 Performing Label Switched Path Ping (LSP Ping) over MPLS 1073 Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, 1074 . 1076 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 1077 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 1078 Failures in Point-to-Multipoint MPLS - Extensions to LSP 1079 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 1080 . 1082 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 1083 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 1084 Extensions for Bit Index Explicit Replication (BIER)", 1085 RFC 8444, DOI 10.17487/RFC8444, November 2018, 1086 . 1088 Authors' Addresses 1090 Nagendra Kumar 1091 Cisco Systems, Inc. 1092 7200 Kit Creek Road 1093 Research Triangle Park, NC 27709 1094 US 1096 Email: naikumar@cisco.com 1097 Carlos Pignataro 1098 Cisco Systems, Inc. 1099 7200 Kit Creek Road 1100 Research Triangle Park, NC 27709-4987 1101 US 1103 Email: cpignata@cisco.com 1105 Nobo Akiya 1106 Big Switch Networks 1107 Japan 1109 Email: nobo.akiya.dev@gmail.com 1111 Lianshu Zheng 1112 Huawei Technologies 1113 China 1115 Email: vero.zheng@huawei.com 1117 Mach Chen 1118 Huawei Technologies 1120 Email: mach.chen@huawei.com 1122 Greg Mirsky 1123 ZTE Corp. 1125 Email: gregimirsky@gmail.com