idnits 2.17.1 draft-ietf-bier-ping-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (January 22, 2018) is 2286 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 1008, but no explicit reference was found in the text == Unused Reference: 'RFC0792' is defined on line 1044, but no explicit reference was found in the text == Unused Reference: 'RFC6291' is defined on line 1048, but no explicit reference was found in the text == Unused Reference: 'RFC6424' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: 'RFC6425' is defined on line 1059, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-bier-ospf-bier-extensions-10 -- Obsolete informational reference (is this intentional?): RFC 6424 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 8 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: July 26, 2018 N. Akiya 6 Big Switch Networks 7 L. Zheng 8 M. Chen 9 Huawei Technologies 10 G. Mirsky 11 Ericsson 12 January 22, 2018 14 BIER Ping and Trace 15 draft-ietf-bier-ping-03 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 July 26, 2018. 53 Copyright Notice 55 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . 3 74 3. BIER OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3.1. BIER OAM message format . . . . . . . . . . . . . . . . . 4 76 3.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . 10 82 3.3.5. Responder BFER TLV . . . . . . . . . . . . . . . . . 13 83 3.3.6. Responder BFR TLV . . . . . . . . . . . . . . . . . . 14 84 3.3.7. Upstream Interface TLV . . . . . . . . . . . . . . . 14 85 3.3.8. Reply-To TLV . . . . . . . . . . . . . . . . . . . . 15 86 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 4.1. BIER OAM Processing . . . . . . . . . . . . . . . . . . . 16 88 4.2. Per BFER ECMP Discovery . . . . . . . . . . . . . . . . . 16 89 4.3. Sending BIER Echo Request . . . . . . . . . . . . . . . . 17 90 4.4. Receiving BIER Echo Request . . . . . . . . . . . . . . . 18 91 4.5. Sending Echo Reply . . . . . . . . . . . . . . . . . . . 20 92 4.6. Receiving Echo Reply . . . . . . . . . . . . . . . . . . 21 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 94 5.1. Message Types, Reply Modes, Return Codes . . . . . . . . 21 95 5.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 98 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22 99 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 22 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 101 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 102 9.2. Informative References . . . . . . . . . . . . . . . . . 23 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 ~ Message Type Dependent Data ~ 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Ver 169 Set to 1. 171 Message Type 173 This document defines the following Message Types: 175 Type Value Field 176 -------- --------------- 177 1 BIER Echo Request 178 2 BIER Echo Reply 180 Proto 182 This field is used to define if there is any data packet 183 immediately following the OAM payload which is used for passive 184 OAM functionality. This field is set to 0 if there is no data 185 packet following OAM payload. 187 The Echo Request/Reply header format is as follows: 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Ver | Echo Req/Rep | Proto | Reserved | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | QTF | RTF | Reply mode | Return Code | Return Subcode| 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Sender's Handle | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Sequence Number | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | TimeStamp Sent | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | TimeStamp Sent | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | TimeStamp Received | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | TimeStamp Received | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 ~ TLVs ~ 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Proto 213 Set to 0 for Echo Request/Reply header. 215 QTF 217 Querier Timestamp Format. When set to 2, the Timestamp Sent field 218 is (in seconds and microseconds, according to the Initiator's 219 clock) in NTP format [RFC5905]. When set to 3, the timestamp 220 format is in IEEE 1588-2008 (1588v2) Precision Time Protocol 221 format. Any other value SHOULD be considered as sanity check 222 failure 224 RTF 226 Responder Timestamp Format. When set to 2, the Timestamp Received 227 field is (in seconds and microseconds, according to the 228 Initiator's clock) in NTP format [RFC5905]. When set to 3, the 229 timestamp format is in IEEE 1588-2008 (1588v2) Precision Time 230 Protocol format. Any other value SHOULD be considered as sanity 231 check failure. 233 Reply mode 235 The Reply mode is set to one of the below: 237 Value Meaning 238 -------- --------------- 239 1 Do not Reply 240 2 Reply via IPv4/IPv6 UDP packet. 241 3 Reply via BIER packet 243 When Reply mode is set to 1, the receiver will not send any reply. 244 This is used for unidirectional path validation. The Reply mode by 245 default would be set to 2 and the Responder BFR will encapsulate the 246 Echo reply payload with IP header. When the Initiator intend to 247 validate the return BIER path, the Reply mode is set to 3 so that the 248 Responder BFR will encapsulate the Echo Reply with BIER header. 250 Return Code 252 Set to zero if Type is "BIER Echo Request". Set to one of the 253 value defined in section 3.2, if Type is "BIER Echo Reply". 255 Return subcode 257 To Be updated. 259 Sender's Handle, Sequence number and Timestamp 261 The Sender's Handle is filled by the Initiator, and returned 262 unchanged by responder BFR. This is used for matching the replies 263 to the request. 265 The Sequence number is assigned by the Initiator and can be used 266 to detect any missed replies. 268 The Timestamp Sent is the time when the Echo Request is sent. The 269 TimeStamp Received in Echo Reply is the time (accordingly to 270 responding BFR clock) that the corresponding Echo Request was 271 received. The format depends on the QTF/RTF value. 273 TLVs 275 Carries the TLVs as defined in Section 3.3. 277 3.2. Return Code 279 Responder uses Return Code field to reply with validity check or 280 other error message to Initiator. It does not carry any meaning in 281 Echo Request and MUST be set to zero. 283 The Return Code can be one of the following: 285 Value Value Meaning 286 -------- --------------- 287 0 No return code 288 1 Malformed Echo Request received 289 2 One or more of the TLVs was not understood 290 3 Replying BFR is the only BFER in header Bitstring 291 4 Replying BFR is one of the BFER in header Bitstring 292 5 Packet-Forward-Success 293 6 Invalid Multipath Info Request 294 8 No matching entry in forwarding table. 295 9 Set-Identifier Mismatch 296 10 DDMAP Mismatch 298 "No return code" will be used by Initiator in the Echo Request. This 299 Value MUST NOT be used in Echo Reply. 301 "Malformed Echo Request received" will be used by any BFR if the 302 received Echo Request packet is not properly formatted. 304 When any TLV included in the Echo Request is not understood by 305 receiver, the Return code will be set to "One or more of the TLVs was 306 not understood" carrying the respective TLVs. 308 When the received header BitString in Echo Request packet contains 309 only its own Bit-ID, "Replying BFR is the only BFER in header 310 BitString" is set in the reply. This implies that the receiver is 311 BFER and the packet is not forwarded to any more neighbors. 313 When the received header BitString in Echo Request packet contains 314 its own Bit-ID in addition to other Bit-IDs, "Replying BFR is one of 315 the BFER in header BitString" is set in the reply. This implies that 316 the responder is a BFER and the packet is further forwarded to one or 317 more neighbors. 319 Any transit BFR will send the Echo Reply with "Packet-Forward- 320 Success", if the TLV in received Echo Request are understood and 321 forwarding table have forwarding entries for the BitString. This is 322 used by transit BFR during traceroute mode. 324 When Echo Request is received with multipath info for more than one 325 BFER, the return-code is set to "Invalid Multipath Info Request". 327 If the BitString cannot be matched in local forwarding table, the BFR 328 will use "No matching entry in forwarding table" in the reply. 330 If the BIER-MPLS label in received Echo Request is not the one 331 assigned for SI in Original SI-BitString TLV, "Set-Identifier 332 Mismatch" is set inorder to report the mismatch. 334 3.3. BIER OAM TLV 336 This section defines various TLVs that can be used in BIER OAM 337 packet. The TLVs (Type-Length-Value tuples) have the following 338 format: 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Type | Length | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 ~ Value ~ 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 TLV Types are defined below; Length is the length of the Value field 351 in octets. The Value field depends on the TLV Type. 353 3.3.1. Original SI-BitString TLV 355 The Original SI-BitString TLV carries the set of BFER and carries the 356 same BitString that Initiator includes in BIER header.This TLV has 357 the following format: 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Type = 1 | Length = variable | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Set ID | Sub-domain ID |BS Len| Reserved | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | BitString (first 32 bits) ~ 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 ~ ~ 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | BitString (last 32 bits) | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Set ID field is set to the Set Identifier to which the BitString 374 belongs to. This value is derived as defined in [RFC8279] 376 Sub-domain ID is set to the Sub domain value to which BFER in 377 BitString belongs to. 379 BS Len is set based on the length of BitString as defined in 380 [RFC8296] 382 The BitString field carries the set of BFR-IDs that Initiator will 383 include in the BIER header. This TLV MUST be included by Initiator 384 in Echo Request packet 386 3.3.2. Target SI-BitString TLV 388 The Target SI-BitString TLV carries the set of BFER from which the 389 Initiator expects the reply from.This TLV has the following format: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Type = 2 | Length = variable | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Set ID | Sub-domain ID |BS Len| Reserved | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | BitString (first 32 bits) ~ 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 ~ ~ 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | BitString (last 32 bits) | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Set ID field is set to the Set Identifier to which the BitString 406 belongs to. This value is derived as defined in [RFC8279] 408 Sub-domain ID is set to the Sub domain value to which BFER in 409 BitString belongs to. 411 BS Len is set based on the length of BitString as defined in 412 [RFC8296] 414 The BitString field carries the set of BFR-IDs of BFER(s) that 415 Initiator expects the response from. The BitString in this TLV may 416 be different from the BitString in BIER header and allows to control 417 the BFER responding to the Echo Request. This TLV MUST be included 418 by Initiator in BIER OAM packet if the Downstream Mapping TLV 419 (section 3.3.4) is included. 421 3.3.3. Incoming SI-BitString TLV 423 The Incoming SI-BitString TLV will be included by Responder BFR in 424 Reply message and copies the BitString from BIER header of incoming 425 Echo Request message. This TLV has the following format: 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Type = 3 | Length = variable | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Set ID | Sub-domain ID |BS Len| Reserved | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | BitString (first 32 bits) ~ 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 ~ ~ 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | BitString (last 32 bits) | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 Set ID field is set to the Set Identifier to which the BitString 442 belongs to. This value is derived as defined in [RFC8279] 444 Sub-domain ID is set to the Sub domain value to which BFER in 445 BitString belongs to. 447 BS Len is set based on the length of BitString as defined in 448 [RFC8296] 450 The BitString field copies the BitString from BIER header of the 451 incoming Echo Request. A Responder BFR SHOULD include this TLV in 452 Echo Reply if the Echo Request is received with I flag set in 453 Downstream Mapping TLV. 455 An Initiator MUST NOT include this TLV in Echo Request. 457 3.3.4. Downstream Mapping TLV 459 This TLV has the following format: 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Type = 4 | Length = variable | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | MTU | Address Type | Flags | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Downstream Address (4 or 16 octets) | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Downstream Interface Address (4 or 16 octets) | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Sub-tlv Length | | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 474 . . 475 . List of Sub-TLVs . 476 . . 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 MTU 481 Set to MTU value of outgoing interface. 483 Address Type 485 The Address Type indicates the address type and length of IP 486 address for downstream interface. The Address type is set to one 487 of the below: 489 Type Addr. Type DA Length DIA Length 490 ------- --------------- ---------- ---------- 491 1 IPv4 Numbered 4 4 492 2 IPv4 Unnumbered 4 4 493 3 IPv6 Numbered 16 16 494 4 IPv6 Unnumbered 16 4 496 DA Length - Downstream Address field Length 497 DIA Length - Downstream Interface Address field Length 499 Flags 501 The Flags field has the following format: 503 0 1 2 3 4 5 6 7 504 +-+-+-+-+-+-+-+-+ 505 | Rsvd |I| 506 +-+-+-+-+-+-+-+-+ 508 When I flag is set, the Responding BFR SHOULD include the Incoming 509 SI-BitString TLV in Echo Reply message. 511 Downstream Address and Downstream Interface Address 513 If the Address Type is 1, the Downstream Address MUST be set to 514 IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address 515 is set to downstream interface address. 517 If the Address Type is 2, the Downstream Address MUST be set to 518 IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address 519 is set to the index assigned by upstream BFR to the interface. 521 If the Address Type is 3, the Downstream Address MUST be set to 522 IPV6 BFR-Prefix of downstream BFR and Downstream Interface Address 523 is set to downstream interface address. 525 If the Address Type is 4, the Downstream Address MUST be set to 526 IPv6 BFR-Prefix of downstream BFR and Downstream Interface Address 527 is set to index assigned by upstream BFR to the interface. 529 3.3.4.1. Downstream Detailed Mapping Sub-TLVs 531 This section defines the optional Sub-TLVs that can be included in 532 Downstream Mapping TLV. 534 Sub-TLV Type Value 535 --------------- -------------- 536 1 Multipath Entropy Data 537 2 Egress BitString 539 3.3.4.1.1. Multipath Entropy Data 541 0 1 2 3 542 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 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 |M| Reserved | | 545 +-+-+-+-+-+-+-+-+-+ | 546 | | 547 | (Multipath Information) | 548 | | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 M Flag 552 This flag is set to 0 if all packets will be forwarded out through 553 interface defined in Downstream Mapping TLV. When set to 1, 554 Multipath Information will be defined with Bit masked Entropy 555 data. 557 Multipath Information 559 Entropy Data encoded as defined in section x3. 561 3.3.4.1.2. Egress BitString 563 This Sub-TLV MAY be included by Responder BFR with the rewritten 564 BitString in outgoing interface as defined in section 6.1 of 565 [RFC8279] 567 0 1 2 3 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Set ID | Sub-domain ID |BS Len| Reserved | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | BitString (first 32 bits) ~ 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 ~ ~ 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | BitString (last 32 bits) | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 3.3.5. Responder BFER TLV 580 The Responder BFER TLV will be included by the BFER replying to the 581 request. This is used to identify the originator of BIER Echo Reply. 582 This TLV have the following format: 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Type = 5 | Length | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Reserved | BFR-ID | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 BFR-ID 594 The BFR-ID field carries the BFR-ID of replying BFER. This TLV 595 MAY be included by Responding BFER in BIER Echo Reply packet. 597 3.3.6. Responder BFR TLV 599 The Responder BFR TLV will be included by the transit BFR replying to 600 the request. This is used to identify the replying BFR without BFR- 601 ID. This TLV have the following format: 603 0 1 2 3 604 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 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | TLV Type = 6 | Length = variable | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Reserved | Address Type | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | | 611 ~ BFR-Prefix (4 or 16 bytes) ~ 612 | | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Length 617 The Length field varies depending on the Address Type. 619 Address Type 621 Set to 1 for IPv4 or 2 for IPv6. 623 BFR-Prefix 625 Carries the local BFR-Prefix of the replying BFR. This TLV MAY be 626 included by Responding BFR in BIER Echo Reply packet. 628 3.3.7. Upstream Interface TLV 630 The Upstream Interface TLV will be included by the replying BFR in 631 Echo Reply. This is used to identify the incoming interface and the 632 BIER-MPLS label in the incoming Echo Request. This TLV have the 633 following format: 635 0 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | TLV Type = 7 | Length = variable | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Reserved | Address Type | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | | 643 ~ Upstream Address (4 or 16 bytes) ~ 644 | | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 Length 649 The Length field varies depending on the Address Type. 651 Address Type 653 Set to 1 for IPv4 numbered, 2 for IPv4 Unnumbered 3 for IPv6 654 numbered or 4 for IPv6 Unnumbered. 656 Upstream Address 658 As defined in Section 3.3.4 660 3.3.8. Reply-To TLV 662 The Reply-To TLV MAY be included by the Initiator BFR in Echo 663 Request. This is used by transit BFR or BFER when the reply mode is 664 2. The IP address will be used to generate Echo Reply. This TLV 665 have the following format: 667 0 1 2 3 668 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 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | TLV Type = 8 | Length = variable | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Reserved | Address Type | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | | 675 ~ Reply-To Address (4 or 16 bytes) ~ 676 | | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 Length 681 The Length field varies depending on the Address Type. 683 Address Type 685 Set to 1 for IPv4 or 2 for IPv6. 687 Reply-To Address 689 Set to any locally configured address to which the Echo reply 690 should be sent to. 692 4. Procedures 694 This section describes aspects of Ping and traceroute operations. 695 While this document explains the behavior when Reply mode is "Reply 696 via BIER packet", the future version will be updated with details 697 about the format when the reply mode is "Reply via IP/UDP packet". 699 4.1. BIER OAM Processing 701 A BIER OAM packet MUST be sent to BIER control plane for OAM 702 processing if one of the following conditions is true: 704 o The receiving BFR is a BFER. 706 o TTL of BIER-MPLS Label expired. 708 o Presence of Router Alert label in the label stack. 710 4.2. Per BFER ECMP Discovery 712 As defined in [RFC8279], BIER follows unicast forwarding path and 713 allows load balancing over ECMP paths between BFIR and BFER. BIER 714 OAM MUST support ECMP path discovery between a BFIR and a given BFER 715 and MUST support path validation and failure detection of any 716 particular ECMP path between BFIR and BFER. 718 [RFC8296] proposes the BIER header with Entropy field that can be 719 leveraged to exercise all ECMP paths. Initiator/BFIR will use 720 traceroute message to query each hop about the Entropy information 721 for each downstream paths. To avoid complexity, it is suggested that 722 the ECMP query is performed per BFER by carrying required information 723 in BIER OAM message. 725 Initiator MUST include Multipath Entropy Data Sub-TLV in Downstream 726 Mapping TLV. It MUST also include the BFER in BitString TLV to which 727 the Multipath query is performed. 729 Any transit BFR will reply back with Bit-masked Entropy for each 730 downstream path as defined in [RFC8029] 732 4.3. Sending BIER Echo Request 734 Initiator MUST set the Message Type as 1 and Return Code as 0. The 735 Proto field in OAM packet MUST be set to 0. The choice of Sender's 736 Handle and Sequence number is a local matter to Initiator and SHOULD 737 increment the Sequence number by 1 for every subsequent Echo Request. 738 The QTF field is set to Initiator's local timestamp format and 739 TimeStamp Sent field is set to the time that the Echo Request is 740 sent. 742 Initiator MUST include Original SI-BitString TLV. Initiator MUST NOT 743 include more than one Original SI-BitString TLV. Initiator infers 744 the Set Identifier value and Sub-domain ID value from the respective 745 BitString that will be included in BIER header of the packet and 746 includes the values in "SI" and Sub-Domain ID fields respectively. 748 In Ping mode, Initiator MAY include Target SI-BitString TLV to 749 control the responding BFER(s) by listing all the BFERs from which 750 the Initiator expects a response. In trace route mode, Initiator MAY 751 include Target SI-Bitstring TLV to control the path trace towards any 752 specific BFER or set of BFERs. Initiator on receiving a reply with 753 Return code as "Replying BFR is the only BFER in header Bitstring" or 754 "Replying router is one of the BFER in header Bitstring", SHOULD 755 unset the respective BFR-id from Target SI-BitString for any 756 subsequent Echo Request. 758 When the Reply mode is set to 2, Initiator MUST include Reply-To TLV 759 (section 3.3.8) in the Echo Request. Initiator MUST also listen to 760 the UDP port defined in this TLV and process any segment received 761 with destination port as value defined in the TLV and sent to control 762 plane for BIER OAM payload processing. 764 Initiator MAY include Downstream Mapping TLV (section 3.3.4) in the 765 Echo Request to query additional information from transit BFRs and 766 BFERs. In case of ECMP discovery, Initiator MUST include the 767 Multipath Entropy Data Sub-TLV and SHOULD set the Target SI-BitString 768 TLV carrying a specific BFER id. 770 Initiator MUST encapsulate the OAM packet with BIER header and MUST 771 set the Proto as 5 and further encapsulates with BIER-MPLS label. In 772 ping mode, the BIER-MPLS Label TTL MUST be set to 255. In traceroute 773 mode, the BIER-MPLS Label TTL is set successively starting from 1 and 774 MUST stop sending the Echo Request if it receives a reply with Return 775 code as "Replying router is the only BFER in BIER header Bitstring" 776 from all BFER listed in Target SI-BitString TLV. 778 4.4. Receiving BIER Echo Request 780 Sending a BIER OAM Echo Request to control plane for payload 781 processing is triggered as mentioned in section 4.1. 783 Any BFR on receiving Echo Request MUST send Echo Reply with Return 784 Code set to "Malformed Echo Request received", if the packet fails 785 sanity check. If the packet sanity check is fine, it SHOULD 786 initiates the below set of variables: 788 Reply-Flag 790 This flag is initially set to 1. 792 Interface-I 794 The incoming interface on which the Echo Request was received. 795 This may be used to validate the DDMAP info and to populate the 796 Upstream Interface TLV. 798 BIER-Label-L 800 The BIER-MPLS Label received as the top label on received Echo 801 Request. This may be used to validate if the packet is traversing 802 the desired Set Identifier and sub-domain path. 804 Header-H 806 The BIER header from the received Echo Request. This may be used 807 to validate the DDMAP info and to populate the Incoming SI- 808 BitString TLV. In addition, it can be used to perform Entropy 809 calculation considering different field in header and reply via 810 Multipath Entropy Data Sub-TLV. 812 BFR MUST initialize Best-return-code variable to null value. 814 BFR will populate Interface-I with interface over which the Echo 815 Request is received, top label in the MPLS stack of the received Echo 816 Request to BIER-Label-L, and the BIER header to BIER-Header. If the 817 received Echo Request carries Target SI-BitString TLV, a BFR SHOULD 818 run boolean AND operation between BitString in Header-H and BitString 819 in Target SI-BitString TLV. If the resulting BitString is all-zero, 820 reset Reply-Flag=0 and go to section 4.5. Else: 822 o If the BIER-Label-L does not correspond to the local label 823 assigned for {sub-domain, BitStringLen, SI} in Original SI- 824 BitString TLV, Set the Best-return-code to "Set-Identifier 825 Mismatch" and Go to section 4.5. 827 * /* This detects any BIER-Label to {sub-domain, BitStringLen, 828 SI} synchronization problem in the upstream BFR causing any 829 unintended packet leak between sub-domains */ 831 o Set the Best-return-code to "One or more of the TLVs was not 832 understood", if any of the TLVs in Echo Request message is not 833 understood. Go to section 4.5. 835 o If the BitString in Header-H does not match the BitString in 836 Egress BitString Sub-TLV of DDMAP TLV, set the Best-return-code to 837 "DDMAP Mismatch" and go to section 4.5. When there are more than 838 one DDMAP TLV in the received Request packet, the Downstream 839 Address and Downstream Interface Address should be matched with 840 Interface-I to identify the right DDMAP TLV and then perform the 841 BitString match. 843 * /* This detects any deviation between in BIER control plane and 844 BIER forwarding plane in the previous hop that may result in 845 loop or packet duplication. */ 847 o Set the Best-return-code to "Invalid Multipath Info Request", when 848 the DDMAP TLV carries Multipath Entropy Data Sub-TLV and if the 849 Target SI-BitString TLV in the received Echo Request carries more 850 than 1 BFER id. Go to section 4.5. Else, list the ECMP 851 downstream neighbors to reach BFR-id in Target SI-BitString TLV, 852 calculate the Entropy considering the BitString in Header-H and 853 Multipath Entropy Data Sub-TLV from received Echo Request. Store 854 the Data for each Downstream interface in temporary variable. Set 855 the Best-return-code to 5 (Packet-Forward-Success) and goto 856 Section 4.5 858 * /* This instructs to calculate the Entropy Data for each 859 downstream interface to reach the BFER in Target SI-BitString 860 TLV by considering the incoming BitString and Entropy Data.*/ 862 o Set the Best-return-code to "Replying router is the only BFER in 863 BIER header Bitstring", and go to section 4.5 if the responder is 864 BFER and there is no more bits in BIER header Bitstring left for 865 forwarding. 867 o Set the Best-return-code to "Replying router is one of the BFER in 868 BIER header Bitstring", and include Downstream Mapping TLV, if the 869 responder is BFER and there are more bits in BitString left for 870 forwarding. In addition, include the Multipath information as 871 defined in Section 4.2 if the received Echo Request carries 872 Multipath Entropy Data Sub-TLV. Go to section 4.5. 874 o Set the Best-return-code to "No matching entry in forwarding 875 table", if the forwarding lookup defined in section 6.5 of 876 [RFC8279] does not match any entry for the received BitString in 877 BIER header. 879 * /* This detects any missing BFR-id in the BIER forwarding 880 table. It could be noted that it is difficult to detect such 881 missing BFR-id while sending the Request with more than one 882 BFR-id in BitString and so may need to just include the BFER id 883 that is not responding to detect such failure.*/ 885 o Set the Best-return-code to "Packet-Forward-Success", and include 886 Downstream Mapping TLV. Go to section 4.5 888 4.5. Sending Echo Reply 890 If Reply-Flag=0; BFR MUST release the variables and MUST not send any 891 response to the Initiator. If Reply-Flag=1, proceed as below: 893 The Responder BFR SHOULD include the BitString from Header-H to 894 Incoming SI-BitString TLV and include the Set ID, Sub-domain ID and 895 BS Len corresponding to BIER-Label-L. Responder BFR SHOULD include 896 the Upstream Interface TLV and populate the address from Interface-I. 898 When the Best-return-code is "Replying BFR is one of the BFER in 899 header Bitstring", it MUST include Responder BFER TLV. 901 If the received Echo Request had DDMAP with Multipath Entropy Data 902 Sub-TLV, Responder BFR MUST include DDMAP as defined in 903 Section 3.3.4 for each outgoing interface over which the packet 904 will be replicated and include the respective Multipath Entropy 905 Data Sub-TLV. For each outgoing interface, respective Egress 906 BitString MUST be included in DDMAP TLV. 908 If the received Echo Request had DDMAP without Multipath Entropy 909 Data Sub-TLV, Responder BFR MUST include DDMAP as defined in 910 Section 3.3.4 for each outgoing interface over which the packet 911 will be replicated. For each outgoing interface, respective 912 Egress BitString MUST be included in DDMAP TLV. 914 When the Best-return-code is "Replying BFR is the only BFER in header 915 Bitstring", it MUST include Responder BFER TLV. 917 Responder MUST set the Message Type as 2 and Return Code as Best- 918 return-code. The Proto field MUST be set to 0. 920 The Echo Reply can be sent either as BIER-encapsulated or IP/UDP 921 encapsulated depending on the Reply mode in received Echo Request. 923 When the Reply mode in received Echo Request is set to 3, Responder 924 appends BIER header listing the BitString with BFIR ID (from Header- 925 H), set the Proto to 5 and set the BFIR as 0. When the Reply mode in 926 received Echo Request is set to 2, Responder encapsulates with IP/UDP 927 header. The UDP destination port MUST be set to TBD1 and source port 928 MAY be set to TBD1 or other random local value. The source IP is any 929 local address of the responder and destiantion IP is derived from 930 Reply-To TLV. 932 4.6. Receiving Echo Reply 934 Initiator on receiving Echo Reply will use the Sender's Handle to 935 match with Echo Request sent. If no match is found, Initiator MUST 936 ignore the Echo Reply. 938 If receiving Echo Reply have Downstream Mapping, Initiator SHOULD 939 copy the same to subsequent Echo Request(s). 941 If one of the Echo Reply is received with Return Code as "Replying 942 BFR is one of the BFER in header Bitstring", it SHOULD reset the BFR- 943 id of the responder from Target SI-BisString TLV in subsequent Echo 944 Request. 946 /* This helps avoiding any BFR that is both BFER and also transit 947 BFR to continuously responding with Echo Reply.*/ 949 5. IANA Considerations 951 This document request UDP port TBD1 to be allocated by IANA for BIER 952 Echo. 954 This document request the IANA for creation and management of below 955 registries: 957 5.1. Message Types, Reply Modes, Return Codes 959 This document request to assign the Message Types and Reply mode 960 mentioned in section 3.1, , Return code mentioned in Section 3.2. 962 5.2. TLVs 964 The TLVs and Sub-TLVs defined in this document is not limited to Echo 965 Request or Reply message types and is applicable for other message 966 types. The TLVs and Sub-TLVs requested by this document for IANA 967 consideration are the following: 969 Type Sub-Type Value Field 970 ------- -------- ----------- 971 1 Original SI-BitString 972 2 Target SI-BitString 973 3 Incoming SI-BitString 974 4 Downstream Mapping 975 4 1 Multipath Entropy Data 976 4 2 Egress BitString 977 5 Responder BFER 978 6 Responder BFR 979 7 Upstream Interface 981 6. Security Considerations 983 The security consideration for BIER Ping is similar to ICMP or LSP 984 Ping. AS like ICMP or LSP ping, BFR may be exposed to Denial-of- 985 service attacks and it is RECOMMENDED to regulate the BIER Ping 986 packet flow to control plane. A rate limiter SHOULD be applied to 987 avoid any attack. 989 As like ICMP or LSP Ping, a traceroute can be used to obtain network 990 information. It is RECOMMENDED that the implementation check the 991 integrity of BFIR of the Echo messages against any local secured list 992 before processing the message further 994 7. Acknowledgement 996 The authors would like to thank Antoni Przygienda, Eric Rosen, Faisal 997 Iqbal Jeffrey (Zhaohui) Zhang and Shell Nakash for thier review and 998 comments. 1000 8. Contributing Authors 1002 TBD 1004 9. References 1006 9.1. Normative References 1008 [I-D.ietf-bier-ospf-bier-extensions] 1009 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 1010 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 1011 for BIER", draft-ietf-bier-ospf-bier-extensions-10 (work 1012 in progress), December 2017. 1014 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1015 Requirement Levels", BCP 14, RFC 2119, 1016 DOI 10.17487/RFC2119, March 1997, 1017 . 1019 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1020 "Network Time Protocol Version 4: Protocol and Algorithms 1021 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1022 . 1024 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 1025 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 1026 Switched (MPLS) Data-Plane Failures", RFC 8029, 1027 DOI 10.17487/RFC8029, March 2017, 1028 . 1030 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1031 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1032 Explicit Replication (BIER)", RFC 8279, 1033 DOI 10.17487/RFC8279, November 2017, 1034 . 1036 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1037 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 1038 for Bit Index Explicit Replication (BIER) in MPLS and Non- 1039 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 1040 2018, . 1042 9.2. Informative References 1044 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1045 RFC 792, DOI 10.17487/RFC0792, September 1981, 1046 . 1048 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 1049 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 1050 Acronym in the IETF", BCP 161, RFC 6291, 1051 DOI 10.17487/RFC6291, June 2011, 1052 . 1054 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 1055 Performing Label Switched Path Ping (LSP Ping) over MPLS 1056 Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, 1057 . 1059 [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., 1060 Yasukawa, S., and T. Nadeau, "Detecting Data-Plane 1061 Failures in Point-to-Multipoint MPLS - Extensions to LSP 1062 Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, 1063 . 1065 Authors' Addresses 1067 Nagendra Kumar 1068 Cisco Systems, Inc. 1069 7200 Kit Creek Road 1070 Research Triangle Park, NC 27709 1071 US 1073 Email: naikumar@cisco.com 1075 Carlos Pignataro 1076 Cisco Systems, Inc. 1077 7200 Kit Creek Road 1078 Research Triangle Park, NC 27709-4987 1079 US 1081 Email: cpignata@cisco.com 1083 Nobo Akiya 1084 Big Switch Networks 1085 Japan 1087 Email: nobo.akiya.dev@gmail.com 1089 Lianshu Zheng 1090 Huawei Technologies 1091 China 1093 Email: vero.zheng@huawei.com 1095 Mach Chen 1096 Huawei Technologies 1098 Email: mach.chen@huawei.com 1099 Greg Mirsky 1100 Ericsson 1102 Email: gregory.mirsky@ericsson.com