draft-ietf-bier-ping-04.txt   draft-ietf-bier-ping-05.txt 
Network Work group N. Kumar Network Work group N. Kumar
Internet-Draft C. Pignataro Internet-Draft C. Pignataro
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: April 24, 2019 N. Akiya Expires: October 26, 2019 N. Akiya
Big Switch Networks Big Switch Networks
L. Zheng L. Zheng
M. Chen M. Chen
Huawei Technologies Huawei Technologies
G. Mirsky G. Mirsky
ZTE Corp. ZTE Corp.
October 21, 2018 April 24, 2019
BIER Ping and Trace BIER Ping and Trace
draft-ietf-bier-ping-04 draft-ietf-bier-ping-05
Abstract Abstract
Bit Index Explicit Replication (BIER) is an architecture that Bit Index Explicit Replication (BIER) is an architecture that
provides optimal multicast forwarding through a "BIER domain" without provides optimal multicast forwarding through a "BIER domain" without
requiring intermediate routers to maintain any multicast related per- requiring intermediate routers to maintain any multicast related per-
flow state. BIER also does not require any explicit tree-building flow state. BIER also does not require any explicit tree-building
protocol for its operation. A multicast data packet enters a BIER protocol for its operation. A multicast data packet enters a BIER
domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2019. This Internet-Draft will expire on October 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 5, line 19 skipping to change at page 5, line 19
This field defines the length of the OAM message including the This field defines the length of the OAM message including the
header and Dependent Data field. header and Dependent Data field.
The Echo Request/Reply header format is as follows: The Echo Request/Reply header format is as follows:
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Echo Req/Rep | Proto | Reserved | | Ver | Echo Req/Rep | Proto | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QTF | RTF | Reply mode | Return Code | Return Subcode| | QTF | RTF | Reply mode | Return Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle | | Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent | | TimeStamp Sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent | | TimeStamp Sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received | | TimeStamp Received |
skipping to change at page 6, line 33 skipping to change at page 6, line 33
default would be set to 2 and the Responder BFR will encapsulate the default would be set to 2 and the Responder BFR will encapsulate the
Echo reply payload with IP header. When the Initiator intend to Echo reply payload with IP header. When the Initiator intend to
validate the return BIER path, the Reply mode is set to 3 so that the validate the return BIER path, the Reply mode is set to 3 so that the
Responder BFR will encapsulate the Echo Reply with BIER header. Responder BFR will encapsulate the Echo Reply with BIER header.
Return Code Return Code
Set to zero if Type is "BIER Echo Request". Set to one of the Set to zero if Type is "BIER Echo Request". Set to one of the
value defined in section 3.2, if Type is "BIER Echo Reply". value defined in section 3.2, if Type is "BIER Echo Reply".
Return subcode Reserved
To Be updated. Set to all zero value.
Sender's Handle, Sequence number and Timestamp Sender's Handle, Sequence number and Timestamp
The Sender's Handle is filled by the Initiator, and returned The Sender's Handle is filled by the Initiator, and returned
unchanged by responder BFR. This is used for matching the replies unchanged by responder BFR. This is used for matching the replies
to the request. to the request.
The Sequence number is assigned by the Initiator and can be used The Sequence number is assigned by the Initiator and can be used
to detect any missed replies. to detect any missed replies.
skipping to change at page 12, line 24 skipping to change at page 12, line 24
Flags Flags
The Flags field has the following format: The Flags field has the following format:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Rsvd |I| | Rsvd |I|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
When I flag is set, the Responding BFR SHOULD include the Incoming When I flag is set, the Responding BFR MUST include the Incoming SI-
SI-BitString TLV in Echo Reply message. BitString TLV in Echo Reply message.
Downstream Address and Downstream Interface Address Downstream Address and Downstream Interface Address
If the Address Type is 1, the Downstream Address MUST be set to If the Address Type is 1, the Downstream Address MUST be set to
IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address
is set to downstream interface address. is set to downstream interface address.
If the Address Type is 2, the Downstream Address MUST be set to If the Address Type is 2, the Downstream Address MUST be set to
IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address
is set to the index assigned by upstream BFR to the interface. is set to the index assigned by upstream BFR to the interface.
skipping to change at page 16, line 39 skipping to change at page 16, line 39
3.4. Multipath Entropy Data Encoding 3.4. Multipath Entropy Data Encoding
The size of Entropy field in BIER header is 20 bits as defined in The size of Entropy field in BIER header is 20 bits as defined in
section 2 of [RFC8296]. This is similar to Multipath Type 9 encoding section 2 of [RFC8296]. This is similar to Multipath Type 9 encoding
defined in Section 3.4.1.1.1 of [RFC8029]. defined in Section 3.4.1.1.1 of [RFC8029].
4. Procedures 4. Procedures
This section describes aspects of Ping and traceroute operations. This section describes aspects of Ping and traceroute operations.
While this document explains the behavior when Reply mode is "Reply
via BIER packet", the future version will be updated with details
about the format when the reply mode is "Reply via IP/UDP packet".
4.1. BIER OAM Processing 4.1. BIER OAM Processing
A BIER OAM packet MUST be sent to BIER control plane for OAM A BIER OAM packet MUST be sent to BIER control plane for OAM
processing if one of the following conditions is true: processing if one of the following conditions is true:
o The receiving BFR is a BFER. o The receiving BFR is a BFER.
o TTL of BIER-MPLS Label expired. o TTL of BIER-MPLS Label expired.
skipping to change at page 18, line 30 skipping to change at page 18, line 30
traceroute mode, the BIER-MPLS Label TTL is set successively starting traceroute mode, the BIER-MPLS Label TTL is set successively starting
from 1 and MUST stop sending the Echo Request if it receives a reply from 1 and MUST stop sending the Echo Request if it receives a reply
with Return code as "Replying router is the only BFER in BIER header with Return code as "Replying router is the only BFER in BIER header
Bitstring" from all BFER listed in Target SI-BitString TLV. Bitstring" from all BFER listed in Target SI-BitString TLV.
4.4. Receiving BIER Echo Request 4.4. Receiving BIER Echo Request
Sending a BIER OAM Echo Request to control plane for payload Sending a BIER OAM Echo Request to control plane for payload
processing is triggered as mentioned in section 4.1. processing is triggered as mentioned in section 4.1.
Any BFR on receiving Echo Request MUST send Echo Reply with Return Any BFR on receiving Echo Request MUST perform the basic sanity
Code set to "Malformed Echo Request received", if the packet fails check. If the BFR cannot parse the OAM Dependent data payload
sanity check. If the packet sanity check is fine, it SHOULD initiate completely if the OAM Message Length is incorrect. BFR MUST send
the below set of variables: Echo Reply with Return Code set to "Malformed Echo Request received"
if the OAM Message Length is incorrect. If the packet sanity check
is fine, it SHOULD initiate the below set of variables:
Reply-Flag Reply-Flag
This flag is initially set to 1. This flag is initially set to 1.
Interface-I Interface-I
The incoming interface on which the Echo Request was received. The incoming interface on which the Echo Request was received.
This may be used to validate the DDMAP info and to populate the This may be used to validate the DDMAP info and to populate the
Upstream Interface TLV. Upstream Interface TLV.
skipping to change at page 23, line 24 skipping to change at page 23, line 24
information. It is RECOMMENDED that the implementation checks the information. It is RECOMMENDED that the implementation checks the
integrity of BFIR of the Echo messages against any local secured list integrity of BFIR of the Echo messages against any local secured list
before processing the message further before processing the message further
7. Acknowledgement 7. Acknowledgement
The authors would like to thank Antoni Przygienda, Eric Rosen, Faisal The authors would like to thank Antoni Przygienda, Eric Rosen, Faisal
Iqbal Jeffrey (Zhaohui) Zhang and Shell Nakash for their review and Iqbal Jeffrey (Zhaohui) Zhang and Shell Nakash for their review and
comments. comments.
The authors would like to thank Mankamana Mishra for this thorough
review and comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-bier-ospf-bier-extensions] [I-D.ietf-bier-ospf-bier-extensions]
Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., Psenak, P., Kumar, N., Wijnands, I., Dolganow, A.,
Przygienda, T., Zhang, Z., and S. Aldrin, "OSPFv2 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPFv2
Extensions for BIER", draft-ietf-bier-ospf-bier- Extensions for BIER", draft-ietf-bier-ospf-bier-
extensions-18 (work in progress), June 2018. extensions-18 (work in progress), June 2018.
 End of changes. 12 change blocks. 
17 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/