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/