< draft-ietf-bier-path-mtu-discovery-09.txt		draft-ietf-bier-path-mtu-discovery-10.txt >
	BIER Working Group G. Mirsky		BIER Working Group G. Mirsky
	Internet-Draft ZTE Corp.		Internet-Draft ZTE Corp.
	Intended status: Standards Track T. Przygienda		Intended status: Standards Track T. Przygienda
	Expires: May 23, 2021 Juniper Networks		Expires: 1 October 2021 Juniper Networks
	A. Dolganow		A. Dolganow
	Individual contributor		Individual contributor
	November 19, 2020		30 March 2021
	Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit		Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit
	Replication (BIER) Layer		Replication (BIER) Layer
	draft-ietf-bier-path-mtu-discovery-09		draft-ietf-bier-path-mtu-discovery-10
	Abstract		Abstract
	This document describes Path Maximum Transmission Unit Discovery		This document describes Path Maximum Transmission Unit Discovery
	(PMTUD) in Bit Indexed Explicit Replication (BIER) layer.		(PMTUD) in Bit Indexed Explicit Replication (BIER) layer.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 May 23, 2021.		This Internet-Draft will expire on 1 October 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions used in this document . . . . . . . . . . . . 3		1.1. Conventions used in this document . . . . . . . . . . . . 3
	1.1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . 3		1.1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . 3
	1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3		1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3
	2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3		2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
	3. PMTUD Mechanism for BIER . . . . . . . . . . . . . . . . . . 4		3. PMTUD Mechanism for BIER . . . . . . . . . . . . . . . . . . 4
	3.1. Data TLV for BIER Ping . . . . . . . . . . . . . . . . . 6		3.1. Data TLV for BIER Ping . . . . . . . . . . . . . . . . . 6
	skipping to change at page 5, line 24 ¶		skipping to change at page 5, line 24 ¶
	determined as minimal MTU value of BFIR's links to BIER domain. As		determined as minimal MTU value of BFIR's links to BIER domain. As
	has been assumed in Section 2, MTUs of all links but the link (B, D)		has been assumed in Section 2, MTUs of all links but the link (B, D)
	are the same. Thus BFERs E, F, and G would receive BIER Echo Request		are the same. Thus BFERs E, F, and G would receive BIER Echo Request
	and will send their respective replies to BFIR A. BFR B may pass the		and will send their respective replies to BFIR A. BFR B may pass the
	packet which is too large to forward over egress link (B, D) to the		packet which is too large to forward over egress link (B, D) to the
	appropriate network layer for error processing where it would be		appropriate network layer for error processing where it would be
	recognized as a BIER Echo Request packet. BFR B MUST send BIER Echo		recognized as a BIER Echo Request packet. BFR B MUST send BIER Echo
	Reply to BFIR A and MUST include Downstream Mapping TLV, defined in		Reply to BFIR A and MUST include Downstream Mapping TLV, defined in
	[I-D.ietf-bier-ping] setting its fields in the following fashion:		[I-D.ietf-bier-ping] setting its fields in the following fashion:
	o MTU SHOULD be set to the minimal MTU value among all egress BIER		* MTU SHOULD be set to the minimal MTU value among all egress BIER
	links, logical links between this and downstream BFRs, that could		links, logical links between this and downstream BFRs, that could
	be used to reach B's downstream BFERs;		be used to reach B's downstream BFERs;
	o Address Type MUST be set to 0 [Ed.note: we need to define 0 as		* Address Type MUST be set to 0 [Ed.note: we need to define 0 as
	valid value for the Address Type field with the specific semantics		valid value for the Address Type field with the specific semantics
	to "Ignore" it.]		to "Ignore" it.]
	o I flag MUST be cleared;		* I flag MUST be cleared;
	o Downstream Interface Address field (4 octets) MUST be zeroed and		* Downstream Interface Address field (4 octets) MUST be zeroed and
	MUST include in the Egress Bitstring sub-TLV the list of all BFERs		MUST include in the Egress Bitstring sub-TLV the list of all BFERs
	that cannot be reached because the attempted MTU turned out to be		that cannot be reached because the attempted MTU turned out to be
	too small.		too small.
	The BFIR will receive either of the two types of packets:		The BFIR will receive either of the two types of packets:
	o a positive Echo Reply from one of BFERs to which the probe has		* a positive Echo Reply from one of BFERs to which the probe has
	been sent. In this case, the bit corresponding to the BFER MUST		been sent. In this case, the bit corresponding to the BFER MUST
	be cleared from the BMS;		be cleared from the BMS;
	o a negative Echo Reply with bit string listing unreached BFERs and		* a negative Echo Reply with bit string listing unreached BFERs and
	recommended MTU value MTU'. The BFIR MUST add the bit string to		recommended MTU value MTU'. The BFIR MUST add the bit string to
	its BMS and set the size of the next probe as min(MTU, MTU')		its BMS and set the size of the next probe as min(MTU, MTU')
	If upon expiration of the Echo Request timer BFIR didn't receive any		If upon expiration of the Echo Request timer BFIR didn't receive any
	Echo Replies, then the size of the probe SHOULD be decreased. There		Echo Replies, then the size of the probe SHOULD be decreased. There
	are scenarios when an implementation of the PMTUD would not decrease		are scenarios when an implementation of the PMTUD would not decrease
	the size of the probe. For example, suppose upon expiration of the		the size of the probe. For example, suppose upon expiration of the
	Echo Request timer BFIR didn't receive any Echo Reply. In that case,		Echo Request timer BFIR didn't receive any Echo Reply. In that case,
	BFIR MAY continue to retransmit the probe using the initial size and		BFIR MAY continue to retransmit the probe using the initial size and
	MAY apply probe delay retransmission procedures. The algorithm used		MAY apply probe delay retransmission procedures. The algorithm used
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 19 ¶
	defined retransmission procedures until either the bit string is		defined retransmission procedures until either the bit string is
	clear, i.e., contains no set bits, or until the BFIR retransmission		clear, i.e., contains no set bits, or until the BFIR retransmission
	procedure terminates and PMTU discovery is declared unsuccessful. In		procedure terminates and PMTU discovery is declared unsuccessful. In
	the case of convergence of the procedure, the size of the last probe		the case of convergence of the procedure, the size of the last probe
	indicates the PMTU size that can be used for all BFERs in the initial		indicates the PMTU size that can be used for all BFERs in the initial
	BMS without incurring fragmentation.		BMS without incurring fragmentation.
	Thus we conclude that in order to comply with the requirement in		Thus we conclude that in order to comply with the requirement in
	[I-D.ietf-bier-oam-requirements]:		[I-D.ietf-bier-oam-requirements]:
	o a BFR SHOULD support PMTUD;		* a BFR SHOULD support PMTUD;
	o a BFR MAY use defined per BIER sub-domain MTU value as initial MTU		* a BFR MAY use defined per BIER sub-domain MTU value as initial MTU
	value for discovery or use it as MTU for this BIER sub-domain to		value for discovery or use it as MTU for this BIER sub-domain to
	reach BFERs;		reach BFERs;
	o a BFIR MUST have a locally defined PMTUD probe retransmission		* a BFIR MUST have a locally defined PMTUD probe retransmission
	procedure.		procedure.
	3.1. Data TLV for BIER Ping		3.1. Data TLV for BIER Ping
	There needs to be a control for probe size in order to support the		There needs to be a control for probe size in order to support the
	BIER PMTUD. Data TLV format is presented in Figure 2.		BIER PMTUD. Data TLV format is presented in Figure 2.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type (TBA1) | Length |		| Type (TBA1) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Data |		| Data |
	~ ~		~ ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Data TLV format		Figure 2: Data TLV format
	o Type: indicates Data TLV, to be allocated by IANA Section 4.		* Type: indicates Data TLV, to be allocated by IANA Section 4.
	o Length: the length of the Data field in octets.		* Length: the length of the Data field in octets.
	o Data: n octets (n = Length) of arbitrary data. The receiver		* Data: n octets (n = Length) of arbitrary data. The receiver
	SHOULD ignore it.		SHOULD ignore it.
	4. IANA Considerations		4. IANA Considerations
	IANA is requested to assign a new Type value for Data TLV Type from		IANA is requested to assign a new Type value for Data TLV Type from
	its registry of TLV and sub-TLV Types of BIER Ping as follows:		its registry of TLV and sub-TLV Types of BIER Ping as follows:
	+-------+-------------+---------------+		+=======+=============+===============+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+-------------+---------------+		+=======+=============+===============+
	| TBA1 | Data | This document |		| TBA1 | Data | This document |
	+-------+-------------+---------------+		+-------+-------------+---------------+
	Table 1: Data TLV Type		Table 1: Data TLV Type
	5. Security Considerations		5. Security Considerations
	Routers that support PMTUD based on this document are subject to the		Routers that support PMTUD based on this document are subject to the
	same security considerations as defined in [I-D.ietf-bier-ping]		same security considerations as defined in [I-D.ietf-bier-ping]
	6. Acknowledgment		6. Acknowledgment
	Authors greatly appreciate thorough review and the most detailed		Authors greatly appreciate thorough review and the most detailed
	comments by Eric Gray.		comments by Eric Gray.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-bier-ping]		[I-D.ietf-bier-ping]
	Nainar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M.,		Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M.,
	and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier-		and G. Mirsky, "BIER Ping and Trace", Work in Progress,
	ping-07 (work in progress), May 2020.		Internet-Draft, draft-ietf-bier-ping-07, 11 May 2020,
			<https://tools.ietf.org/html/draft-ietf-bier-ping-07>.
	[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,		[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	DOI 10.17487/RFC1191, November 1990,		DOI 10.17487/RFC1191, November 1990,
	<https://www.rfc-editor.org/info/rfc1191>.		<https://www.rfc-editor.org/info/rfc1191>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 8, line 13 ¶		skipping to change at page 8, line 17 ¶
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,		[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
	"Path MTU Discovery for IP version 6", STD 87, RFC 8201,		"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
	DOI 10.17487/RFC8201, July 2017,		DOI 10.17487/RFC8201, July 2017,
	<https://www.rfc-editor.org/info/rfc8201>.		<https://www.rfc-editor.org/info/rfc8201>.
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-bier-oam-requirements]		[I-D.ietf-bier-oam-requirements]
	Mirsky, G., Nainar, N., Chen, M., and S. Pallagatti,		Mirsky, G., Kumar, N., Chen, M., and S. Pallagatti,
	"Operations, Administration and Maintenance (OAM)		"Operations, Administration and Maintenance (OAM)
	Requirements for Bit Index Explicit Replication (BIER)		Requirements for Bit Index Explicit Replication (BIER)
	Layer", draft-ietf-bier-oam-requirements-11 (work in		Layer", Work in Progress, Internet-Draft, draft-ietf-bier-
	progress), November 2020.		oam-requirements-11, 15 November 2020,
			<https://tools.ietf.org/html/draft-ietf-bier-oam-
			requirements-11>.
	[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,		[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
	Przygienda, T., and S. Aldrin, "Multicast Using Bit Index		Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
	Explicit Replication (BIER)", RFC 8279,		Explicit Replication (BIER)", RFC 8279,
	DOI 10.17487/RFC8279, November 2017,		DOI 10.17487/RFC8279, November 2017,
	<https://www.rfc-editor.org/info/rfc8279>.		<https://www.rfc-editor.org/info/rfc8279>.
	Authors' Addresses		Authors' Addresses
	Greg Mirsky		Greg Mirsky
	ZTE Corp.		ZTE Corp.
	Email: gregimirsky@gmail.com		Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com
	Tony Przygienda		Tony Przygienda
	Juniper Networks		Juniper Networks
	Email: prz@juniper.net		Email: prz@juniper.net
	Andrew Dolganow		Andrew Dolganow
	Individual contributor		Individual contributor
	Email: adolgano@gmail.com		Email: adolgano@gmail.com
End of changes. 26 change blocks.
	36 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/