idnits 2.17.1 draft-chen-bier-te-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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 14 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-bier-architecture]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 12, 2017) is 2320 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: 'I-D.ietf-bier-ospf-bier-extensions' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'RFC0792' is defined on line 694, but no explicit reference was found in the text == Unused Reference: 'RFC4379' is defined on line 698, but no explicit reference was found in the text == Unused Reference: 'I-D.eckert-bier-te-arch' is defined on line 715, 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 normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) Summary: 4 errors (**), 0 flaws (~~), 6 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 Shaofu. Peng 4 Intended status: Standards Track ZTE Corporation 5 Expires: June 15, 2018 December 12, 2017 7 BIER-TE Ping and Trace 8 draft-chen-bier-te-ping-03 10 Abstract 12 Bit Index Explicit Replication (BIER)-TE shares architecture and 13 packet formats with BIER as described in 14 [I-D.ietf-bier-architecture]. BIER-TE forwards and replicates 15 packets based on a BitString in the packet header, but every 16 BitPosition of the BitString of a BIER-TE packet indicates one or 17 more adjacencies. 19 This document describes the mechanism and basic BIER-TE OAM packet 20 format that can be used to perform Ping and Traceroute on BIER-TE 21 network. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 15, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 3. BIER-TE OAM Packet format . . . . . . . . . . . . . . . . . . 3 60 3.1. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 5 61 3.1.1. BIER-TE forward_connected TLV . . . . . . . . . . . . 6 62 3.1.2. BIER-TE local_decap TLV . . . . . . . . . . . . . . . 7 63 3.1.3. BIER-TE forward_routed TLV . . . . . . . . . . . . . 7 64 3.2. Downstream Mapping TLV . . . . . . . . . . . . . . . . . 8 65 3.2.1. Downstream Mapping Sub-TLVs . . . . . . . . . . . . . 8 66 3.2.1.1. Multipath Entropy Data . . . . . . . . . . . . . 9 67 3.2.1.2. Egress BitString sub-TLV . . . . . . . . . . . . 9 68 3.2.1.3. FEC Stack Change Sub-TLV . . . . . . . . . . . . 9 69 3.3. Original SI-BitString TLV . . . . . . . . . . . . . . . . 10 70 3.4. Target SI-BitString TLV . . . . . . . . . . . . . . . . . 11 71 3.5. Responder BFER TLV . . . . . . . . . . . . . . . . . . . 11 72 3.6. Responder BFR TLV . . . . . . . . . . . . . . . . . . . . 11 73 3.7. Reply-To TLV . . . . . . . . . . . . . . . . . . . . . . 11 74 4. BIER-TE OAM Processing . . . . . . . . . . . . . . . . . . . 11 75 4.1. Sending BIER Echo Request . . . . . . . . . . . . . . . . 11 76 4.2. Receiving BIER Echo Request . . . . . . . . . . . . . . . 12 77 4.3. Sending Echo Reply . . . . . . . . . . . . . . . . . . . 14 78 4.4. Receiving Echo Reply . . . . . . . . . . . . . . . . . . 15 79 5. Security Consideration . . . . . . . . . . . . . . . . . . . 15 80 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 8.1. Normative references . . . . . . . . . . . . . . . . . . 15 84 8.2. Informative references . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 [I-D.ietf-bier-architecture] introduces and explains BIER-TE 90 architecture that provides optimal multicast forwarding through a 91 "BIER-TE domain" without requiring intermediate routers to maintain 92 any multicast related per-flow state. BIER-TE forwards and 93 replicates packets based on a BitString in the packet header, but 94 every BitPosition of the BitString of a BIER-TE packet indicates one 95 or more adjacencies. 97 This document describes the mechanism and basic BIER-TE OAM packet 98 format that can be used to perform Ping and Traceroute on BIER-TE 99 network. 101 This document is a supplement to [I-D.kumarzheng-bier-ping].BIER-MPLS 102 [I-D.ietf-bier-mpls-encapsulation] defines a 4-bit field as "Proto" 103 to identify the payload following BIER header. When the payload is 104 BIER-TE OAM, the "Proto" field will be set to 6 as defined in this 105 document. 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC2119. 113 3. BIER-TE OAM Packet format 115 The BIER-TE OAM packet header format is similar with the BIER OAM 116 header as described in [I-D.kumarzheng-bier-ping]. 118 The BIER-TE OAM packet header format is as follows: 120 0 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Ver | Echo Req/Rep | Proto | Reserved | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | QTF | RTF | Reply mode | Return Code | Return Subcode | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Sender's Handle | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Sequence Number | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | TimeStamp Sent | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | TimeStamp Sent | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | TimeStamp Received | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | TimeStamp Received | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 ~ TLVs ~ 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Ver:Set to 1. 144 Proto:Set to 0 for Echo Request/Reply header. 146 QTF:Querier Timestamp Format.When set to 2, the Timestamp Sent field 147 is (in seconds and microseconds, according to the Initiator'sclock) 148 in NTP format [RFC5905]. When set to 3, the timestamp format is in 149 IEEE 1588-2008 (1588v2) Precision Time Protocol format. Any other 150 value SHOULD be considered as sanity check failure. 152 RTF:Responder Timestamp Format. When set to 2, the Timestamp 153 Received field is (in seconds and microseconds, according to the 154 Initiator's clock) in NTP format [RFC5905]. When set to 3, the 155 timestamp format is in IEEE 1588-2008 (1588v2) Precision Time. 157 Reply mode:The Reply mode is set to one of the below: 159 Value Meaning 160 -------- --------------- 161 1 Do not Reply 162 2 Reply via IPv4/IPv6 UDP packet. 163 3 Reply via BIER-TE packet 165 Return Code:Set to zero if Type is " BIER Echo Request". Set to the 166 following value, if Type is "BIER Echo Reply". 168 Value Value Meaning 169 -------- --------------- 170 0 No return code 171 1 Malformed Echo Request received 172 2 One or more of the TLVs was not understood 173 3 Replying BFR is the only BFER in header Bitstring 174 4 Replying BFR is one of the BFER in header Bitstring 175 5 Packet-Forward-Success 176 6 Invalid Multipath Info Request 177 8 No matching entry in forwarding table. 178 9 Set-Identifier Mismatch 179 10 Replying BFR is not in the path to any target BFER 180 11 Mapping for this FEC is not the given bitposition in bitstring 182 Return subcode:To Be updated. 184 Sender's Handle:The Sender's Handle is filled by the Initiator, and 185 returned unchanged by responder BFR. This is used for matching the 186 replies to the request. 188 Sequence number:The Sequence number is assigned by the Initiator and 189 can be used to detect any missed replies. 191 Timestamp:The Timestamp Sent is the time when the Echo Request is 192 sent. The TimeStamp Received in Echo Reply is the time (accordingly 193 to responding BFR clock) that the corresponding Echo Request was 194 received. The format depends on the QTF/RTF value. 196 TLVs have the following format: 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Type | Length | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Value | 204 . . 205 . . 206 . . 207 | | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Length is the length of the Value field in octets. The Value field 211 depends on the TLV Type. 213 A description of the Types and Values for TLLVs are given below: 215 Type# value field 216 -------- --------------------------------- 217 1 Target FEC Stack 218 2 Downstream Mapping 219 3 Original SI-BitString TLV 220 4 Target SI-BitString TLV 221 5 Responder BFER TLV 222 6 Responder BFR TLV 223 7 Reply-To TLV 225 3.1. Target FEC Stack 227 A Target FEC Stack is a list of sub-TLVs. 229 Sub-Length Value Field 230 -------- ----------------- 231 29 BIER-TE forward_connected TLV 232 30 BIER-TE local_decap TLV 233 31 BIER-TE forward_routed TLV 235 Other FEC Types will be defined as needed. 237 3.1.1. BIER-TE forward_connected TLV 239 The format is as below: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Type | Length | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Protocol | Reserved | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Local Interface ID (4 or 16 octets) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Remote Interface ID (4 or 16 octets) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 ~ ~ 253 | Advertising Node Identifier (4 or 6 octets) | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 ~ ~ 256 | Receiving Node Identifier (4 or 6 octets) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Local Interface ID 261 Local Interface ID is assigned by local BFR for a link on which 262 Adjacency ID is bound. This field is set to local link address (IPv4 263 or IPv6). 265 Remote Interface ID 267 Remote Interface ID is assigned by remote BFR for a link on which 268 Adjacency ID is bound. This field is set to remote link address 269 (IPv4 or IPv6). 271 Advertising Node Identifier 272 Advertising Node Identifier is the advertising node identifier. When 273 Protocol is set to 1, then the 32 rightmost bits represent OSPF 274 Router ID and if protocol is set to 2, this field carries 48 bit ISIS 275 System ID. 277 Receiving Node Identifier 279 Receiving Node Identifier is downstream node identifier. When 280 Protocol is set to 1, then the 32 rightmost bits represent OSPF 281 Router ID and if protocol is set to 2, this field carries 48 bit ISIS 282 System ID. 284 3.1.2. BIER-TE local_decap TLV 286 The format is as below: 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type | Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Protocol | Reserved | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 ~ ~ 296 | Advertising Node Identifier (4 or 6 octets) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Advertising Node Identifier 301 Advertising Node Identifier is the advertising node identifier. When 302 Protocol is set to 1, then the 32 rightmost bits represent OSPF 303 Router ID and if protocol is set to 2, this field carries 48 bit ISIS 304 System ID. 306 3.1.3. BIER-TE forward_routed TLV 308 The ipv4 format is as below: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | BFR IPv4 Prefix | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |Prefix Length | Reserved | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 IPv4 Prefix:This field carries the IPv4 prefix. 320 Prefix Length is one octet, it gives the length of prefix in bits. 322 The ipv6 format is as below: 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | | 328 | BFR IPv6 Prefix | 329 | | 330 | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 |Prefix Length | Reserved | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 IPv6 Prefix:This field carries the IPv4 prefix. 337 Prefix Length is one octet, it gives the length of prefix in bits. 339 3.2. Downstream Mapping TLV 341 The TLV format is similar with Downstream Detailed Mapping TLV as 342 described in [I-D.kumarzheng-bier-ping]. 344 3.2.1. Downstream Mapping Sub-TLVs 346 This section defines the optional Sub-TLVs that can be included in. 348 Sub-TLV Type Value 349 --------------- ------------------------ 350 1 Multipath Entropy Data 351 2 Egress BitString 352 3. FEC stack change 354 3.2.1.1. Multipath Entropy Data 356 The format is as below: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 |Multipath Type | Multipath Length |Reserved (MBZ) | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | | 364 | (Multipath Information) | 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 The multipath data sub-TLV includes Multipath Information. 370 3.2.1.2. Egress BitString sub-TLV 372 The format is as below: 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type | Length | Resrved | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Set ID | Sub-domain ID |BS Len| Reserved | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | BitString (first 32 bits) ~ 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 ~ ~ 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | BitString (last 32 bits) | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 BitString:Adjacency BitString. 390 3.2.1.3. FEC Stack Change Sub-TLV 392 The format and the usage is the similar with [RFC6424]. 394 The format is as below: 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 2 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 |Operation Type | Address Type | FEC-tlv length| Reserved | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Remote Peer Address (0, 4 or 16 octets) | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 . . 404 . FEC TLV . 405 . . 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Operation Type 410 The operation type specifies the action associated with the FEC Stack 411 Change.A new operation type is defined: 413 Type Operation 414 ----- ----------- 415 3 Remove 417 Address type: 0. 419 FEC TLV Length:Length in bytes of the FEC TLV. 421 Reserved:This field is reserved for future use and MUST be set to 422 zero. 424 Remote Peer Address:0. 426 FEC TLV 428 The FEC TLV is present only when the FEC-tlv length field is nonzero. 429 The FEC TLV specifies the FEC associated with the FEC stack change 430 operation. The FEC type is defined in section 3.1. 432 3.3. Original SI-BitString TLV 434 The Incoming SI-BitString TLV will be included by Responder BFR in 435 Reply message and copies the BitString from BIER header of incoming 436 Echo Request message.The format and usage is similar with Original 437 SI-BitString TLV as defined in [I-D.kumarzheng-bier-ping]. 439 3.4. Target SI-BitString TLV 441 The Target SI-BitString TLV carries the set of BFER's local_decap 442 adjacency from which the Initiator expects the reply from. The 443 format and usage is similar with Target SI-BitString TLV as defined 444 in [I-D.kumarzheng-bier-ping]. 446 3.5. Responder BFER TLV 448 The Responder BFER TLV will be included by the BFER replying to the 449 request. This is used to identify the originator of BIER Echo Reply. 450 The format and usage is similar with Responder BFER TLV as defined in 451 [I-D.kumarzheng-bier-ping]. 453 3.6. Responder BFR TLV 455 The Responder BFR TLV will be included by the transit BFR replying to 456 the request. This is used to identify the replying BFR without 457 BFRID. The format and usage is similar with Responder BFR TLV as 458 defined in [I-D.kumarzheng-bier-ping]. 460 3.7. Reply-To TLV 462 The Reply-To TLV MAY be included by the Initiator BFR in Echo 463 Request. This is used by transit BFR or BFER when the reply mode is 464 the IP address will be used to generate Echo Reply. The format and 465 usage is similar with Reply-To TLV as defined in 466 [I-D.kumarzheng-bier-ping]. 468 4. BIER-TE OAM Processing 470 BIER-TE OAM packet MUST be sent to BIER control plane for OAM 471 processing if one of the following conditions is true: 473 o The receiving BFR is a BFER. 475 o TTL of BIER-MPLS Label expired. 477 o Presence of Router Alert label in the label stack. 479 4.1. Sending BIER Echo Request 481 o Message Type:1. 483 o Return Code:0. 485 o Proto:0. 487 o Sender's Handle and Sequence number:The local matter to Initiator 488 and SHOULD increment the Sequence number by 1 for every subsequent 489 Echo Request. 491 o QTF:Initiator's local timestamp format. 493 o TimeStamp Sent:the time that the Echo Request is sent. 495 o MUST include Original SI-BitString TLV. 497 o In Ping mode, Initiator MAY include Target SI-BitString TLV to 498 control the responding BFER(s) by listing all local_decap 499 adjacency id of the BFERs from which the Initiator expects a 500 response. Initiator on receiving a reply with Return code as 501 "Replying BFR is the only BFER in header Bitstring" or "Replying 502 router is one of the BFER in header Bitstring", SHOULD remove the 503 BFER's local_decap ID from Target SI-BitString for any subsequent 504 Echo Request. 506 o When the Reply mode is set to 2, Initiator MUST include Reply-To 507 TLV in the Echo Request. 509 o Initiator MAY include Downstream Mapping TLV in the Echo Request 510 to query additional information from transit BFRs and BFERs. In 511 case of ECMP discovery, Initiator MUST include the Multipath 512 Entropy Data Sub-TLV and SHOULD set the Target SI-BitString TLV 513 carrying a specific BFER's local_decap adjacency id. 515 o Initiator MUST encapsulate the OAM packet with BIER header and 516 MUST set the Proto as 6 and further encapsulates with BIER-MPLS 517 label. In ping mode, the BIER-MPLS Label TTL MUST be set to 255. 518 In traceroute mode, the BIER-MPLS Label TTL is set successively 519 starting from 1 and MUST stop sending the Echo Request if it 520 receives a reply with Return code as "Replying router is the only 521 BFER in BIER header Bitstring" from all BFER listed in Target SI- 522 BitString TLV. 524 o MUST PUSH the corresponding FEC to target FEC stack, which the 525 push order is the same with adjacency BitPosition of the 526 BitString. 528 4.2. Receiving BIER Echo Request 530 Reply-Flag:This flag is initially set to 1. 532 Interface-I:The incoming interface on which the Echo Request was 533 received. 535 BIER-Label-L:The BIER-MPLS Label received as the top label on 536 received Echo Request. 538 Header-H:The BIER header from the received Echo Request. 540 Best-return-code: contains the return code for the echo reply packet 541 as currently best known. 543 If the received Echo Request carries Target SI-BitString TLV, a BFR 544 SHOULD run boolean AND operation between BitString in Header-H and 545 BitString in Target SI-BitString TLV. 547 If the resulting BitString is all-zero, Set Best-return-code="Mapping 548 for this FEC is not the given bitposition in bitstring" and Go to 549 section 4.3, Else: 551 o If the BIER-Label-L does not correspond to the local label 552 assigned for {sub-domain, BitStringLen, SI} in Original 553 SIBitString TLV, Set the Best-return-code to "Set-Identifier 554 Mismatch" and Go to section 4.3. 556 o If any of the TLVs in Echo Request message is not understood. Set 557 the Best-return-code to "One or more of the TLVs was not 558 understood" and Go to section 4.3. 560 o If the BitString in Header-H does not match the BitString in 561 Egress BitString Sub-TLV of DSMAP TLV, set the Best-return-code to 562 ERR-TBD and Go to section 4.3. 564 o If the forwarding lookup defined in section 6.5 of 565 [I-D.ietf-bier-architecture] does not match any entry for the 566 received BitString in BIER header. Set the Best-return-code to 567 "No matching entry in forwarding table" and Go to section 4.3. 569 o If any FEC which get from the matched BIFT entry is not consistent 570 with the FEC get from the FEC stack at same position as entry's 571 BitPosition in Header-H, Set the Best-return-code to "Mapping for 572 this FEC is not the given bitposition in bitstring" and Go to 573 section 4.3. 575 o If the DSMAP TLV carries Multipath Entropy Data Sub-TLV and if the 576 BitString in Header-H carries more than one forward routed 577 adjacency and each matches the BIFT entry. Set the Best-return- 578 code to "Invalid Multipath Info Request" and Go to section 4.3. 579 Else, list the ECMP downstream neighbors to reach forward routed 580 adjacency, calculate the Entropy considering the BitString in 581 Header-H and Multipath Entropy Data Sub-TLV from received Echo 582 Request. Set the Best-return-code to 5 (Packet-Forward-Success). 584 o For all the forward_connected adjacency and local_decap adjacency 585 which match the BIFT entry, FEC change sub-TLV should be carried 586 in DSMAP TLV, and set the operation type filed in the FEC change 587 sub-TLV to remove. 589 o For all the forward_routed adjacency which match the BIFT entry, 590 if the BIFT entry indicate that not local decapsulation but 591 continue forwarding the OAM packet, FEC change sub-TLV should not 592 carried in DSMAP TLV. If the BIFT entry indicate that local 593 decapsulation the OAM packet, FEC change sub-TLV should be carried 594 in DSMAP TLV, and set the operation type filed in the FEC change 595 sub-TLV to remove. 597 o If the responder is BFER which match the local_decap BIFT, and 598 there is no more bits in BIER header Bitstring left for 599 forwarding.Set the Best-return-code to "Replying router is the 600 only BFER in BIER header Bitstring", and go to section 4.3. 602 o If the responder is BFER which match the local_decap BIFT, and 603 there are more bits in in BitString left for forwarding. Set the 604 Best-return-code to " Replying router is one of the BFER in BIER 605 header Bitstring", and go to section 4.3. 607 4.3. Sending Echo Reply 609 o Message Type:2. 611 o Return Code:Best-return-code. 613 o The Proto :0. 615 o When the Best-return-code is "Replying BFR is one of the BFER in 616 header Bitstring", it MUST include Responder BFER TLV. 618 o If the received Echo Request had DSMAP with Multipath Entropy Data 619 Sub-TLV, Responder BFR MUST include DSMAP for each outgoing 620 interface over which the packet will be replicated and include the 621 respective Multipath Entropy Data Sub-TLV. For each outgoing 622 interface, respective Egress BitString MUST be included in DSMAP 623 TLV. 625 o If the received Echo Request had DSMAP without Multipath Entropy 626 Data Sub-TLV, Responder BFR MUST include DSMAP for each outgoing 627 interface over which the packet will be replicated. For each 628 outgoing interface, respective Egress BitString MUST be included 629 in DSMAP TLV. 631 o When the Best-return-code is "Replying BFR is the only BFER in 632 header Bitstring", it MUST include Responder BFER TLV. 634 o When the Reply mode in received Echo Request is set to 3, 635 Responder appends BIER header listing the BitString with the 636 BFIR's local_decap id and set the Proto to 6 and set the BFIR as 637 0. 639 o When the Reply mode in received Echo Request is set to 2, 640 Responder encapsulates with IP/UDP header. The UDP destination 641 port MUST be set to TBD1 and source port MAY be set to TBD1 or 642 other random local value. The source IP is any local address of 643 the responder and destiantion IP is derived from Reply-To TLV. 645 4.4. Receiving Echo Reply 647 o Initiator on receiving Echo Reply will use the Sender's Handle to 648 match with Echo Request sent. If no match is found, Initiator 649 MUST ignore the Echo Reply. 651 o If receiving Echo Reply have Downstream Mapping, Initiator SHOULD 652 copy the same to subsequent Echo Request(s). 654 o If one of the Echo Reply is received with Return Code as "Replying 655 BFR is one of the BFER in header Bitstring", it SHOULD remove the 656 BFER' s local_decap ID from Target SI-BitString for any subsequent 657 Echo Request. 659 5. Security Consideration 661 The section will be added in next version. 663 6. Acknowledgements 665 TBD. 667 7. IANA Considerations 669 TBD. 671 8. References 673 8.1. Normative references 675 [I-D.ietf-bier-architecture] 676 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 677 S. Aldrin, "Multicast using Bit Index Explicit 678 Replication", draft-ietf-bier-architecture-08 (work in 679 progress), September 2017. 681 [I-D.ietf-bier-mpls-encapsulation] 682 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., 683 Aldrin, S., and I. Meilik, "Encapsulation for Bit Index 684 Explicit Replication in MPLS and non-MPLS Networks", 685 draft-ietf-bier-mpls-encapsulation-12 (work in progress), 686 October 2017. 688 [I-D.ietf-bier-ospf-bier-extensions] 689 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 690 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 691 for BIER", draft-ietf-bier-ospf-bier-extensions-10 (work 692 in progress), December 2017. 694 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 695 RFC 792, DOI 10.17487/RFC0792, September 1981, 696 . 698 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 699 Label Switched (MPLS) Data Plane Failures", RFC 4379, 700 DOI 10.17487/RFC4379, February 2006, 701 . 703 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 704 "Network Time Protocol Version 4: Protocol and Algorithms 705 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 706 . 708 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 709 Performing Label Switched Path Ping (LSP Ping) over MPLS 710 Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, 711 . 713 8.2. Informative references 715 [I-D.eckert-bier-te-arch] 716 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 717 Engineering for Bit Index Explicit Replication BIER-TE", 718 draft-eckert-bier-te-arch-06 (work in progress), November 719 2017. 721 [I-D.kumarzheng-bier-ping] 722 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 723 and G. Mirsky, "BIER Ping and Trace", draft-kumarzheng- 724 bier-ping-03 (work in progress), July 2016. 726 Authors' Addresses 728 Ran Chen 729 ZTE Corporation 730 No.50 Software Avenue,Yuhuatai District 731 Nanjing, Jiangsu Province 210012 732 China 734 Phone: +86 025 88014636 735 Email: chen.ran@zte.com.cn 737 Shaofu Peng 738 ZTE Corporation 740 Email: peng.shaofu@zte.com.cn