idnits 2.17.1 draft-chen-bier-te-ping-04.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 130 characters in excess of 72. 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: A BIER-TE echo request MAY include the Target FEC Stack TLV that describes the FEC Stack being tested. If there aren't adjacency keyword information in BFIR, the FEC Stack MUST not be tested, and the Nil FEC MUST be used. -- The document date (February 26, 2019) is 1883 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC0792' is defined on line 556, but no explicit reference was found in the text == Unused Reference: 'RFC4379' is defined on line 560, but no explicit reference was found in the text == Unused Reference: 'RFC5905' is defined on line 565, but no explicit reference was found in the text == Unused Reference: 'RFC8279' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'RFC8401' is defined on line 587, but no explicit reference was found in the text == Unused Reference: 'RFC8444' is defined on line 592, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-bier-ping-04 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-01 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group Ran. Chen 3 Internet-Draft Greg. Mirsky 4 Intended status: Standards Track Shaofu. Peng 5 Expires: August 30, 2019 ZTE Corporation 6 February 26, 2019 8 BIER-TE Ping and Trace 9 draft-chen-bier-te-ping-04 11 Abstract 13 Bit Index Explicit Replication (BIER)-TE shares architecture and 14 packet formats with BIER-TE forwards and replicates packets based on 15 a BitString in the packet header, but every BitPosition of the 16 BitString of a BIER-TE packet indicates one or more adjacencies. 18 This document describes the mechanism and basic BIER-TE OAM packet 19 format that can be used to perform Ping and Traceroute on the BIER-TE 20 network. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 30, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 3 58 3. BIER-TE OAM Packet format . . . . . . . . . . . . . . . . . . 3 59 3.1. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 3 60 3.1.1. BIER-TE forward-connected TLV . . . . . . . . . . . . 4 61 3.1.2. BIER-TE local-decap sub-TLV . . . . . . . . . . . . . 5 62 3.1.3. BIER-TE forward-routed TLV . . . . . . . . . . . . . 6 63 3.2. Downstream Mapping TLV . . . . . . . . . . . . . . . . . 6 64 3.2.1. FEC Stack Change Sub-TLV . . . . . . . . . . . . . . 6 65 3.3. Reply-To TLV . . . . . . . . . . . . . . . . . . . . . . 7 66 4. BIER-TE OAM Processing . . . . . . . . . . . . . . . . . . . 8 67 4.1. Sending BIER Echo Request . . . . . . . . . . . . . . . . 8 68 4.2. Receiving BIER Echo Request . . . . . . . . . . . . . . . 9 69 4.3. Sending Echo Reply . . . . . . . . . . . . . . . . . . . 10 70 4.4. Receiving Echo Reply . . . . . . . . . . . . . . . . . . 11 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 6.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 6.2. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 12 75 6.3. Downstream Detailed Mapping Sub-TLVs . . . . . . . . . . 12 76 7. Normative references . . . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 [I-D.ietf-bier-te-arch] introduces and explains BIER-TE architecture 82 that provides policy-based multicast forwarding through a "BIER-TE 83 domain" without requiring intermediate routers to maintain any 84 multicast related per-flow state. BIER-TE forwards and replicates 85 packets based on a BitString in the packet header, but every 86 BitPosition of the BitString of a BIER-TE packet indicates one or 87 more adjacencies. 89 This document describes the mechanism and the basic BIER-TE OAM 90 packet format that can be used to perform Ping and Traceroute on the 91 BIER-TE network. 93 This document enhances the BIER Ping and Traceroute, as defined in 94 [I-D.ietf-bier-ping]. [RFC8296] defines a 4-bit field as "Proto" to 95 identify the payload following BIER header. When the payload is 96 BIER-TE OAM, the "Proto" field is the same with the BIER OAM "Proto" 97 field. 99 2. Conventions used in this document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC2119. 105 3. BIER-TE OAM Packet format 107 The BIER-TE OAM packet header format and the fields are the same as 108 the BIER OAM header [I-D.ietf-bier-ping]. This document defines two 109 new return codes and the new TLVs and Sub-TLVs. 111 The new Return codes are follows: 113 TBA1 Replying BFR is not in the path to any target BFER 115 TBA2 Mapping for this FEC is not the given BitPosition in BitString 117 The TLVs and Sub-TLVs requested by this document for IANA 118 consideration are the following: 120 Type value field 121 -------- --------------------------------- 122 9 Target FEC Stack 123 10 Reply-To TLV 125 3.1. Target FEC Stack 127 A BIER-TE echo request MAY include the Target FEC Stack TLV that 128 describes the FEC Stack being tested. If there aren't adjacency 129 keyword information in BFIR, the FEC Stack MUST not be tested, and 130 the Nil FEC MUST be used. 132 We define three new FEC Stack types. The Target FEC Stack is a list 133 of sub-TLVs. 135 Sub-Type Length Value Field 136 -------- -------- ------------------------------- 137 29 20 or 48 octets BIER-TE forward-connected 138 30 8 or 10 octets BIER-TE local-decap 139 31 4 or 6 octets BIER-TE forward-routed 141 Other FEC Types will be defined as needed. 143 3.1.1. BIER-TE forward-connected TLV 145 The format is as below: 147 0 1 2 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Type | Length | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Protocol | Address Type | Reserved | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Local Interface ID (4 or 16 octets) | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Remote Interface ID (4 or 16 octets) | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 ~ ~ 159 | Advertising Node Identifier (4 or 6 octets) | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 ~ ~ 162 | Receiving Node Identifier (4 or 6 octets) | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Address Type 167 The Address Type indicates the address type and length of the IP 168 address for the downstream interface. The Address type MAY be set to 169 one of the values listed in Table below: 171 Type Addr. Type DA Length DIA Length 172 -------- -------------- -------------- ----------------- 173 1 IPv4 Numbered 4 4 174 2 IPv4 Unnumbered 4 4 175 3 IPv6 Numbered 16 16 176 4 IPv6 Unnumbered 16 4 178 DA Length - Downstream Address field Length. 180 DIA Length - Downstream Interface Address field Length. 182 Local Interface ID 184 Local BFR assigns Local Interface ID for a link to which Adjacency ID 185 is bound. This field is set to local link address (IPv4 or IPv6). 187 Remote Interface ID 189 Remote BFR assigns Remote Interface ID for a link to which Adjacency 190 ID is bound. This field is set to remote link address (IPv4 or 191 IPv6). 193 Advertising Node Identifier 195 Advertising Node Identifier is the advertising node identifier. When 196 Protocol is set to 1, then the 32 rightmost bits represent OSPF 197 Router ID, and if Protocol is set to 2, this field carries 48 bit 198 ISIS System ID. 200 Receiving Node Identifier 202 Receiving Node Identifier is the downstream node identifier. When 203 Protocol is set to 1, then the 32 rightmost bits represent OSPF 204 Router ID, and if Protocol is set to 2, this field carries 48 bit 205 ISIS System ID. 207 3.1.2. BIER-TE local-decap sub-TLV 209 The format is as below: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Type | Length | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Protocol | Reserved | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 ~ ~ 219 | Advertising Node Identifier (4 or 6 octets) | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Advertising Node Identifier 224 Advertising Node Identifier is the advertising node identifier. When 225 Protocol is set to 1, then the 32 rightmost bits represent OSPF 226 Router ID and if protocol is set to 2, this field carries 48 bit ISIS 227 System ID. 229 3.1.3. BIER-TE forward-routed TLV 231 The ipv4 format is as below: 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Type | Length | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFR IPv4 Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 IPv4 Prefix:This field carries the IPv4 prefix. 241 The ipv6 format is as below: 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type | Length | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Reserved | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 | BFR IPv6 Prefix | 252 | | 253 | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 IPv6 Prefix:This field carries the IPv6 prefix. 258 3.2. Downstream Mapping TLV 260 This TLV format is the same with the BIER OAM [I-D.ietf-bier-ping] 261 and we a new Sub-TLV: FEC stack change Sub-TLV. 263 Sub-TLV Type Value 264 --------------- ------------------------ 265 3 FEC stack change 267 3.2.1. FEC Stack Change Sub-TLV 269 The format and the usage as defined in [RFC6424]. 271 0 1 2 3 272 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 2 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 |Operation Type | Address Type | FEC-tlv length| Reserved | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Remote Peer Address (0, 4 or 16 octets) | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 . . 279 . FEC TLV . 280 . . 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Operation Type 285 The operation type specifies the action associated with the FEC Stack 286 Change. A new operation type is defined: 288 Type Operation 289 ----- ----------- 290 3 Remove 292 Address type: 0. 294 FEC TLV Length: Length in bytes of the FEC TLV. 296 Reserved: This field is reserved for future use and MUST be set to 297 zero. 299 Remote Peer Address: 0. 301 FEC TLV 303 The FEC TLV is present only when the FEC-tlv length field is nonzero. 304 The FEC TLV specifies the FEC associated with the FEC stack change 305 operation. The FEC type is defined in section 3.1. 307 3.3. Reply-To TLV 309 The Initiator BFR MAY include the Reply-To TLV in Echo Request 310 message. The Reply-to TLV is used by a transit BFR or BFER when the 311 reply mode is "Reply via IPv4/IPv6 UDP packet". 313 The IP address will be used as the destination IP address for the 314 Echo Reply. The format and usage are the same as defined for the 315 BIER OAM header [I-D.ietf-bier-ping]. 317 4. BIER-TE OAM Processing 319 BIER-TE OAM packet MUST be sent to BIER control plane for OAM 320 processing if one of the following conditions is true: 322 o The receiving BFR is a BFER. 324 o TTL of BIER-MPLS Label expired. 326 o Presence of Router Alert label in the label stack. 328 4.1. Sending BIER Echo Request 330 o Message Type:1. 332 o Return Code:0. 334 o Proto:0. 336 o Sender's Handle and Sequence number:The local matter to Initiator 337 and SHOULD increment the Sequence number by 1 for every subsequent 338 Echo Request. 340 o QTF:Initiator's local timestamp format. 342 o TimeStamp Sent:the time that the Echo Request is sent. 344 o MUST include Original SI-BitString TLV. 346 o In Ping mode, the Initiator MAY include Target SI-BitString TLV to 347 control the responding BFER(s) by listing all local-decap 348 Adjacency ID of the BFERs from which the Initiator expects a 349 response. Initiator on receiving a reply with Return code as 350 "Replying BFR is the only BFER in header Bitstring" or "Replying 351 router is one of the BFER in header Bitstring", SHOULD remove the 352 BFER's local-decap ID from Target SI-BitString for any subsequent 353 Echo Request. 355 o When the Reply mode is set to 2, Initiator MUST include Reply-To 356 TLV in the Echo Request. 358 o The Initiator MAY include Downstream Mapping TLV in the Echo 359 Request to query additional information from transit BFRs and 360 BFERs. In the case of ECMP discovery, Initiator MUST include the 361 Multipath Entropy Data Sub-TLV and SHOULD set the Target SI- 362 BitString TLV carrying a specific BFER's local-decap Adjacency ID. 364 o The Initiator MUST encapsulate the OAM packet with BIER header and 365 MUST set the Proto as 6 and further encapsulates with BIER-MPLS 366 label. In ping mode, the BIER-MPLS Label TTL MUST be set to 255. 367 In traceroute mode, the BIER-MPLS Label TTL is set successively 368 starting from 1 and MUST stop sending the Echo Request if it 369 receives a reply with Return code as "Replying router is the only 370 BFER in BIER header Bitstring" from all BFER listed in Target SI- 371 BitString TLV. 373 o MUST PUSH the corresponding FEC to Target FEC stack, in the same 374 with as the order of the adjacency's bit-position in the 375 BitString. 377 4.2. Receiving BIER Echo Request 379 Reply-Flag:This flag is initially set to 1. 381 Interface-I:The incoming interface on which the Echo Request was 382 received. 384 BIER-Label-L:The BIER-MPLS Label received as the top label on 385 received Echo Request. 387 Header-H:The BIER header from the received Echo Request. 389 Best-return-code: contains the return code for the echo reply packet 390 as currently best known. 392 If the received Echo Request carries Target SI-BitString TLV, a BFR 393 SHOULD run boolean AND operation between BitString in Header-H and 394 BitString in Target SI-BitString TLV. 396 If the resulting BitString is all-zero, Set Best-return-code to 397 "Mapping for this FEC is not the given BitPosition in BitString" and 398 Go to section 4.3, Else: 400 o If the BIER-Label-L does not correspond to the local label 401 assigned for {sub-domain, BitStringLen, SI} in Original 402 SIBitString TLV, Set the Best-return-code to "Set-Identifier 403 Mismatch" and Go to section 4.3. 405 o If any of the TLVs in Echo Request message is not understood. Set 406 the Best-return-code to "One or more of the TLVs was not 407 understood" and Go to section 4.3. 409 o If the forwarding lookup defined in section 6.5 of RFC8279 does 410 not match any entry for the received BitString in BIER header. 412 Set the Best-return-code to "No matching entry in forwarding 413 table" and Go to section 4.3. 415 o If any FEC which get from the matched BIFT entry is not consistent 416 with the FEC get from the FEC stack at the same position as 417 entry's BitPosition in Header-H, Set the Best-return-code to 418 "Mapping for this FEC is not the given BitPosition in BitString" 419 and Go to section 4.3. 421 o If the DSMAP TLV carries Multipath Entropy Data Sub-TLV and if the 422 BitString in Header-H carries more than one forward routed 423 adjacency and each matches the BIFT entry. Set the Best-return- 424 code to "Invalid Multipath Info Request" and Go to section 4.3. 425 Else, list the ECMP downstream neighbors to reach forward routed 426 adjacency, calculate the Entropy considering the BitString in 427 Header-H and Multipath Entropy Data Sub-TLV from received Echo 428 Request. Set the Best-return-code to 5 (Packet-Forward-Success). 430 o For all the forward-connected adjacencies and all the local-decap 431 adjacencies which match the BIFT entry, FEC Change sub-TLV SHOULD 432 be carried in DSMAP TLV and set the operation type filed in the 433 FEC change sub-TLV to remove. 435 o For all the forward-routed adjacencies which match the BIFT entry, 436 if the BIFT entry indicates that not the local decapsulation but 437 continue forwarding the OAM packet, FEC change sub-TLV SHOULD NOT 438 be carried in DSMAP TLV. If the BIFT entry indicate that the 439 local decapsulation the OAM packet, FEC change sub-TLV SHOULD be 440 carried in DSMAP TLV, and set the operation type filed in the FEC 441 change sub-TLV to remove. 443 o If the responder is BFER which matches the local-decap BIFT, and 444 there are no more bits in BIER header BitString left for 445 forwarding.Set the Best-return-code to "Replying router is the 446 only BFER in BIER header BitString", and go to section 4.3. 448 o If the responder is BFER which match the local-decap BIFT, and 449 there are more bits in the BitString left for forwarding. Set the 450 Best-return-code to " Replying router is one of the BFER in BIER 451 header BitString", and go to section 4.3. 453 4.3. Sending Echo Reply 455 o Message Type:2. 457 o Return Code:Best-return-code. 459 o The Proto :0. 461 o When the Best-return-code is "Replying BFR is one of the BFER in 462 header BitString", it MUST include Responder BFER TLV. 464 o If the received Echo Request had DSMAP with Multipath Entropy Data 465 Sub-TLV, Responder BFR MUST include DSMAP for each outgoing 466 interface over which the packet will be replicated and include the 467 respective Multipath Entropy Data Sub-TLV. 469 o If the received Echo Request had DSMAP without Multipath Entropy 470 Data Sub-TLV, Responder BFR MUST include DSMAP for each outgoing 471 interface over which the packet will be replicated. 473 o When the Best-return-code is "Replying BFR is the only BFER in 474 header BitString", it MUST include Responder BFER TLV. 476 o When the Reply mode in received Echo Request is set to " Reply via 477 BIER packet", Responder appends BIER header listing the BitString 478 with the BFIR's local-decap id and set the Proto to "OAM" and set 479 the BFIR value to 0. 481 o When the Reply mode in received Echo Request is set to "Reply via 482 IPv4/IPv6 UDP packet", Responder encapsulates with IP/UDP header. 483 The UDP destination port MUST be set to TBD1 and source port MAY 484 be randomly selected from the dynamic range of port numbers. The 485 source IP is any local address of the responder and destination IP 486 is derived from Reply-To TLV. 488 4.4. Receiving Echo Reply 490 o Initiator on receiving Echo Reply will use the Sender's Handle to 491 match with Echo Request sent. If no match is found, Initiator 492 MUST ignore the Echo Reply. 494 o If receiving Echo Reply have Downstream Mapping, Initiator SHOULD 495 copy the same to subsequent Echo Request(s). 497 o If one of the Echo Reply is received with Return Code as "Replying 498 BFR is one of the BFER in header BitString", it SHOULD remove the 499 BFER's local-decap ID from Target SI-BitString for any subsequent 500 Echo Request. 502 5. Security Considerations 504 TBD. 506 6. IANA Considerations 508 This document request UDP port TBD1 to be allocated by IANA for BIER- 509 TE Echo. 511 This document request the IANA for creation and management of below 512 registries and sub-registries: 514 Return codes defined in this document are the following: 516 Value value Meaning 517 ----- -------------------------------------------------- 518 10 Replying BFR is not in the path to any target BFER 519 11 Mapping for this FEC is not the given BitPosition in BitString 521 6.1. TLVs 523 The TLVs and Sub-TLVs requested by this document for IANA 524 consideration are the following: 526 6.2. Target FEC Stack 528 Sub-Type Value Field 529 ---------- ---------------------------- 530 29 BIER-TE forward-connected 531 30 BIER-TE local-decap 532 31 BIER-TE forward-routed 534 6.3. Downstream Detailed Mapping Sub-TLVs 536 This section defines the optional Sub-TLVs that can be included in 537 Downstream Mapping TLV. 539 Sub-TLV Type Value 540 ---------- ---------------------------- 541 3 FEC stack change 543 7. Normative references 545 [I-D.ietf-bier-ping] 546 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 547 and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier- 548 ping-04 (work in progress), October 2018. 550 [I-D.ietf-bier-te-arch] 551 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 552 Engineering for Bit Index Explicit Replication (BIER-TE)", 553 draft-ietf-bier-te-arch-01 (work in progress), October 554 2018. 556 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 557 RFC 792, DOI 10.17487/RFC0792, September 1981, 558 . 560 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 561 Label Switched (MPLS) Data Plane Failures", RFC 4379, 562 DOI 10.17487/RFC4379, February 2006, 563 . 565 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 566 "Network Time Protocol Version 4: Protocol and Algorithms 567 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 568 . 570 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 571 Performing Label Switched Path Ping (LSP Ping) over MPLS 572 Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, 573 . 575 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 576 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 577 Explicit Replication (BIER)", RFC 8279, 578 DOI 10.17487/RFC8279, November 2017, 579 . 581 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 582 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 583 for Bit Index Explicit Replication (BIER) in MPLS and Non- 584 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 585 2018, . 587 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 588 Zhang, "Bit Index Explicit Replication (BIER) Support via 589 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 590 . 592 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 593 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 594 Extensions for Bit Index Explicit Replication (BIER)", 595 RFC 8444, DOI 10.17487/RFC8444, November 2018, 596 . 598 Authors' Addresses 600 Ran Chen 601 ZTE Corporation 603 Email: chen.ran@zte.com.cn 605 Greg Mirsky 606 ZTE Corporation 608 Email: gregimirsky@gmail.com 610 Shaofu Peng 611 ZTE Corporation 613 Email: peng.shaofu@zte.com.cn