draft-ietf-trill-mtu-negotiation-08v3.original		draft-ietf-trill-mtu-negotiation-08v3.txt
	INTERNET-DRAFT M. Zhang		Network Working Group M. Zhang
	Intended Status: Standards Track X. Zhang		Internet-Draft X. Zhang
	Updates: 6325, 7177, 7780 D. Eastlake		Updates: 7780 (if approved) D. Eastlake
	Huawei		Intended status: Standards Track Huawei
	R. Perlman		Expires: February 3, 2018 R. Perlman
	EMC		EMC
	S. Chatterjee		S. Chatterjee
	Cisco		Cisco
	Expires: February 3, 2018 August 2, 2017		August 2, 2017
	Transparent Interconnection of Lots of Links (TRILL):		Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation
	MTU Negotiation
	draft-ietf-trill-mtu-negotiation-08.txt		draft-ietf-trill-mtu-negotiation-08.txt
	Abstract		Abstract
	The base IETF TRILL protocol has a TRILL campus-wide MTU feature,		The base IETF TRILL protocol has a TRILL campus-wide MTU feature,
	specified in RFC 6325 and RFC 7177, that assures that link state		specified in RFC 6325 and RFC 7177, that assures that link state
	changes can be successfully flooded throughout the campus while being		changes can be successfully flooded throughout the campus while being
	able to take advantage of a campus-wide capability to support jumbo		able to take advantage of a campus-wide capability to support jumbo
	packets. This document specifies recommended updates to that MTU		packets. This document specifies recommended updates to that MTU
	feature to take advantage, for appropriate link-local packets, of		feature to take advantage, for appropriate link-local packets, of
	link-local MTUs that exceed the TRILL campus MTU. In addition, it		link-local MTUs that exceed the TRILL campus MTU. In addition, it
	specifies an efficient algorithm for local MTU testing. This document		specifies an efficient algorithm for local MTU testing. This
	updates RFC 6325, updates RFC 7177, and updates RFC 7780.		document updates RFC 6325, updates RFC 7177, and updates RFC 7780.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted to IETF 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.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as		working documents as Internet-Drafts. The list of current Internet-
	Internet-Drafts.		Drafts is at http://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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on February 3, 2018.
	http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html
	Copyright and License Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions used in this document . . . . . . . . . . . . . 3		1.1. Conventions used in this document . . . . . . . . . . . . 3
	2. Link-Wide TRILL MTU Size . . . . . . . . . . . . . . . . . . . 3		2. Link-Wide TRILL MTU Size . . . . . . . . . . . . . . . . . . 3
	2.1. Operations . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Link MTU Size Testing . . . . . . . . . . . . . . . . . . . . . 6		3. Link MTU Size Testing . . . . . . . . . . . . . . . . . . . . 5
	4. Refreshing Sz . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Refreshing Sz . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Relationship between Port MTU, Lz and Sz . . . . . . . . . . . 9		5. Relationship between Port MTU, Lz and Sz . . . . . . . . . . 9
	6. LSP Synchronization . . . . . . . . . . . . . . . . . . . . . . 9		6. LSP Synchronization . . . . . . . . . . . . . . . . . . . . . 9
	7. Recommendations for Traffic Link MTU Size Testing . . . . . . . 9		7. Recommendations for Traffic Link MTU Size Testing . . . . . . 9
	8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . . 10		8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 10
	9. Security Considerations . . . . . . . . . . . . . . . . . . . . 10		9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	10. Additions to Configuration . . . . . . . . . . . . . . . . . . 11		10. Additions to Configuration . . . . . . . . . . . . . . . . . 11
	10.1. Per RBridge Configuration . . . . . . . . . . . . . . . . 11		10.1. Per RBridge Configuration . . . . . . . . . . . . . . . 11
	10.2. Per RBridge Port Configuration . . . . . . . . . . . . . . 11		10.2. Per RBridge Port Configuration . . . . . . . . . . . . . 11
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 12		13.1. Normative References . . . . . . . . . . . . . . . . . . 11
	13.2. Informative References . . . . . . . . . . . . . . . . . . 12		13.2. Informative References . . . . . . . . . . . . . . . . . 12
	Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	[RFC6325] describes the way RBridges agree on the campus-wide minimum		[RFC6325] describes the way RBridges agree on the campus-wide minimum
	acceptable inter-RBridge MTU (Maximum Transmission Unit) size (called		acceptable inter-RBridge MTU (Maximum Transmission Unit) size (called
	"Sz") to ensure that link state flooding operates properly and all		"Sz") to ensure that link state flooding operates properly and all
	RBridges converge to the same link state. For the proper operation of		RBridges converge to the same link state. For the proper operation
	TRILL IS-IS, all RBridges format their LSPs to fit in Sz.		of TRILL IS-IS, all RBridges format their LSPs to fit in Sz.
	[RFC7177] diagrams the state transitions of an adjacency. If MTU		[RFC7177] diagrams the state transitions of an adjacency. If MTU
	testing is enabled, "Link MTU size is successfully tested" is part of		testing is enabled, "Link MTU size is successfully tested" is part of
	an event (event A6) causing the transition from "2-way" state to		an event (event A6) causing the transition from "2-way" state to
	"Report" state for an adjacency. This means the link MTU testing of		"Report" state for an adjacency. This means the link MTU testing of
	size X succeeds, and X is greater than or equal to Sz [RFC6325]. If		size X succeeds, and X is greater than or equal to Sz [RFC6325]. If
	this link cannot support an MTU of Sz, it will not be reported as		this link cannot support an MTU of Sz, it will not be reported as
	part of the campus topology.		part of the campus topology.
	In this document, a new RECOMMENDED link-wide minimum inter-RBridge		In this document, a new RECOMMENDED link-wide minimum inter-RBridge
	MTU size, Lz, is specified. As further discussed in Section 2, by		MTU size, Lz, is specified. As further discussed in Section 2, by
	calculating and using Lz as specified herein, link-scoped PDUs can be		calculating and using Lz as specified herein, link-scoped PDUs can be
	formatted greater than Sz, up to the link-wide minimum acceptable		formatted greater than Sz, up to the link-wide minimum acceptable
	inter-RBridge MTU size potentially improving the efficiency of link		inter-RBridge MTU size potentially improving the efficiency of link
	utilization and speeding link state convergence.		utilization and speeding link state convergence.
	An optional TRILL MTU size-testing algorithm is specified in Section		An optional TRILL MTU size-testing algorithm is specified in
	3 as an efficient method to update the old MTU testing method		Section 3 as an efficient method to update the old MTU testing method
	described in Section 4.3.2 of [RFC6325] and in [RFC7177]. The new MTU		described in Section 4.3.2 of [RFC6325] and in [RFC7177]. The new
	size testing method specified in this document is backward compatible		MTU size testing method specified in this document is backward
	with the old one. Multicasting the MTU-probes is recommended when		compatible with the old one. Multicasting the MTU-probes is
	there are multiple RBridges on a link responding to the probing with		recommended when there are multiple RBridges on a link responding to
	MTU-ack [RFC7177]. The testing method and rules of this document are		the probing with MTU-ack [RFC7177]. The testing method and rules of
	devised in a way to minimize the number of MTU probes for testing,		this document are devised in a way to minimize the number of MTU
	which therefore reduces the number of multicast packets for MTU		probes for testing, which therefore reduces the number of multicast
	testing.		packets for MTU testing.
	This document updates [RFC7780] as specified in Section 4.		This document updates [RFC7780] as specified in Section 4.
	1.1. Conventions used in this document		1.1. Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Link-Wide TRILL MTU Size		2. Link-Wide TRILL MTU Size
	This document specifies a new value "Lz" for the minimum acceptable		This document specifies a new value "Lz" for the minimum acceptable
	inter-RBridge link MTU size on a local link. Link-wide Lz is the		inter-RBridge link MTU size on a local link. Link-wide Lz is the
	minimum Lz supported and agreed amongst all RBridges on a specific		minimum Lz supported and agreed amongst all RBridges on a specific
	link. If the link is usable, Lz will be greater than or equal to Sz.		link. If the link is usable, Lz will be greater than or equal to Sz.
	Some TRILL IS-IS PDUs are exchanged only between neighbors instead of		Some TRILL IS-IS PDUs are exchanged only between neighbors instead of
	the whole campus. They are confined by the link-wide Lz instead of		the whole campus. They are confined by the link-wide Lz instead of
	Sz. CSNPs and PSNPs are examples of such PDUs. These PDUs are		Sz. CSNPs and PSNPs are examples of such PDUs. These PDUs are
	exchanged only on the local link. (While TRILL IS-IS Hellos are also		exchanged only on the local link. (While TRILL IS-IS Hellos are also
	link local, they are always limited to 1470 bytes for robustness.)		link local, they are always limited to 1470 bytes for robustness.)
	[RFC7356] defines the PDUs which support flooding scopes in addition		[RFC7356] defines the PDUs which support flooding scopes in addition
	to area-wide scope and domain-wide scope. As specified in [RFC8139],		to area-wide scope and domain-wide scope. As specified in [RFC8139],
	RBridges support the Extended L1 Circuit Scoped (E-L1CS) flooding		RBridges support the Extended L1 Circuit Scoped (E-L1CS) flooding
	scope LSP (FS-LSP) [RFC7780]. The originatingSNPBufferSize for a port		scope LSP (FS-LSP) [RFC7780]. The originatingSNPBufferSize for a
	is the minimum of the following two quantities, but not less than		port is the minimum of the following two quantities, but not less
	1470 bytes: (1) the maximum MTU of the port and (2) the maximum LSP		than 1470 bytes: (1) the maximum MTU of the port and (2) the maximum
	size that the TRILL IS-IS implementation can handle. They use that		LSP size that the TRILL IS-IS implementation can handle. They use
	flooding to exchange their maximum supported value of "Lz". The		that flooding to exchange their maximum supported value of "Lz". The
	smallest value of the Lz advertised by the RBridges on a link, but		smallest value of the Lz advertised by the RBridges on a link, but
	not less than Sz, is the link-wide Lz. An RBridge on a local link		not less than Sz, is the link-wide Lz. An RBridge on a local link
	will be able to tell which other RBridges on that link support E-L1CS		will be able to tell which other RBridges on that link support E-L1CS
	FS-LSPs because, as required by [RFC7780], all RBridges include the		FS-LSPs because, as required by [RFC7780], all RBridges include the
	Scoped Flooding Support TLV [RFC7356] in their TRILL Hellos.		Scoped Flooding Support TLV [RFC7356] in their TRILL Hellos.
	The maximum sized level 1 link-local PDU, such as PSNP or CSNP, which		The maximum sized level 1 link-local PDU, such as PSNP or CSNP, which
	may be generated by a system is controlled by the value of the		may be generated by a system is controlled by the value of the
	management parameter originatingL1SNPBufferSize. This value		management parameter originatingL1SNPBufferSize. This value
	determines Lz. The TRILL APPsub-TLV shown in Figure 2.1 SHOULD be		determines Lz. The TRILL APPsub-TLV shown in Figure 2.1 SHOULD be
	included in a TRILL GENINFO TLV [RFC7357] in an E-L1CS FS-LSP		included in a TRILL GENINFO TLV [RFC7357] in an E-L1CS FS-LSP
	fragment zero. If it is missing from a fragment zero E-L1CS FS-LSP or		fragment zero. If it is missing from a fragment zero E-L1CS FS-LSP
	there is no fragment zero E-L1CS FS-LSP, it is assumed that its		or there is no fragment zero E-L1CS FS-LSP, it is assumed that its
	originating IS is implicitly advertising its originatingSNPBufferSize		originating IS is implicitly advertising its originatingSNPBufferSize
	value as Sz octets.		value as Sz octets.
	E-L1CS FS-LSPs are link-local and can also be sent up to Lz in size		E-L1CS FS-LSPs are link-local and can also be sent up to Lz in size
	but, for robustness, E-L1CS FS-LSP fragment zero MUST NOT exceed 1470		but, for robustness, E-L1CS FS-LSP fragment zero MUST NOT exceed 1470
	bytes.		bytes.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = tbd | (2 byte)		| Type = tbd | (2 byte)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length = 2 | (2 byte)		| Length = 2 | (2 byte)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| originatingSNPBufferSize | (2 byte)		| originatingSNPBufferSize | (2 byte)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2.1: The originatingSNPBufferSize TLV.		Figure 1: The originatingSNPBufferSize TLV.
	Type: set to originatingSNPBufferSize APPsubTLV (TRILL APPsub-TLV		Type: set to originatingSNPBufferSize APPsubTLV (TRILL APPsub-TLV
	type tbd). Two bytes because this APPsub-TLV appears in an Extended		type tbd). Two bytes because this APPsub-TLV appears in an Extended
	TLV [RFC7356].		TLV [RFC7356].
	Length: set to 2.		Length: set to 2.
	originatingSNPBufferSize: the local value of		originatingSNPBufferSize: the local value of
	originatingL1SNPBufferSize as an unsigned integer, limited in the		originatingL1SNPBufferSize as an unsigned integer, limited in the
	range from 1470 to 65,535 bytes. (A value less than 1470 will be		range from 1470 to 65,535 bytes. (A value less than 1470 will be
	ignored.)		ignored.)
	2.1. Operations		2.1. Operations
	Lz MAY be reported using an originatingSNPBufferSize TLV that occurs		Lz MAY be reported using an originatingSNPBufferSize TLV that occurs
	in fragment zero of the RBridge's E-L1CS FS-LSP. An		in fragment zero of the RBridge's E-L1CS FS-LSP. An
	originatingSNPBufferSize APPsub-TLV occurring in any other fragment		originatingSNPBufferSize APPsub-TLV occurring in any other fragment
	is ignored. If more than one originatingSNPBufferSize APPsub-TLV		is ignored. If more than one originatingSNPBufferSize APPsub-TLV
	occurs in fragment zero, the one advertising the smallest value for		occurs in fragment zero, the one advertising the smallest value for
	originatingSNPBufferSize, but not less than 1470 bytes, is used.		originatingSNPBufferSize, but not less than 1470 bytes, is used.
	Lz:1800 Lz:1800		Lz:1800 Lz:1800
	+---+ | +---+		+---+ | +---+
	|RB1|(2000)---|---(2000)|RB2|		|RB1|(2000)---|---(2000)|RB2|
	+---+ | +---+		+---+ | +---+
	|		|
	Lz:1800 |		Lz:1800 |
	+---+ +--+		+---+ +--+
	|RB3|(2000)---(1700)|B1|		|RB3|(2000)---(1700)|B1|
	+---+ +--+		+---+ +--+
	|		|
	Figure 2.2: Link-wide Lz = 1800 v.s. tested link MTU size = 1700		Figure 2: Link-wide Lz = 1800 v.s. tested link MTU size = 1700
	Even if all RBridges on a specific link have reached consensus on the		Even if all RBridges on a specific link have reached consensus on the
	value of link-wide Lz based on advertised originatingSNPBufferSize,		value of link-wide Lz based on advertised originatingSNPBufferSize,
	it does not mean that these RBridges can safely exchange PDUs between		it does not mean that these RBridges can safely exchange PDUs between
	each other. Figure 2.2 shows such a corner case. RB1, RB2 and RB3 are		each other. Figure 2.2 shows such a corner case. RB1, RB2 and RB3
	three RBridges on the same link and their Lz is 1800, so the link-		are three RBridges on the same link and their Lz is 1800, so the
	wide Lz of this link is 1800. There is an intermediate bridge (say		link- wide Lz of this link is 1800. There is an intermediate bridge
	B1) between RB2 and RB3 whose port MTU size is 1700. If RB2 sends		(say B1) between RB2 and RB3 whose port MTU size is 1700. If RB2
	PDUs formatted in chunks of size 1800, it will be discarded by B1.		sends PDUs formatted in chunks of size 1800, it will be discarded by
			B1.
	Therefore the link MTU size SHOULD be tested. After the link MTU size		Therefore the link MTU size SHOULD be tested. After the link MTU
	of an adjacency is successfully tested, those link-local PDUs such as		size of an adjacency is successfully tested, those link-local PDUs
	CSNPs, PSNPs and E-L1CS FS-LSPs will be formatted no greater than the		such as CSNPs, PSNPs and E-L1CS FS-LSPs will be formatted no greater
	tested link MTU size and will be safely transmitted on this link.		than the tested link MTU size and will be safely transmitted on this
			link.
	As for Sz, RBridges continue to propagate their		As for Sz, RBridges continue to propagate their
	originatingL1LSPBufferSize across the campus through the		originatingL1LSPBufferSize across the campus through the
	advertisement of LSPs as defined in Section 4.3.2 of [RFC6325]. The		advertisement of LSPs as defined in Section 4.3.2 of [RFC6325]. The
	smallest value of Sz advertised by any RBridge, but not less than		smallest value of Sz advertised by any RBridge, but not less than
	1470, will be deemed as Sz. Each RBridge formats their "campus-wide"		1470, will be deemed as Sz. Each RBridge formats their "campus-wide"
	PDUs, for example LSPs, not greater than what they determine as Sz.		PDUs, for example LSPs, not greater than what they determine as Sz.
	3. Link MTU Size Testing		3. Link MTU Size Testing
	[RFC7177] defines the event A6 as including "MTU test is successful"		[RFC7177] defines the event A6 as including "MTU test is successful"
	if the MTU testing is enabled. As described in Section 4.3.2 of		if the MTU testing is enabled. As described in Section 4.3.2 of
	[RFC6325], this is a combination of the following event and		[RFC6325], this is a combination of the following event and
	condition.		condition.
	Event: The link MTU size has been tested.		Event: The link MTU size has been tested.
	Condition: The link can support Sz.		Condition: The link can support Sz.
	This condition can be efficiently tested by the following "Binary		This condition can be efficiently tested by the following "Binary
	Search Algorithm" and rules. This updates [RFC7177] and [RFC6325].		Search Algorithm" and rules. This updates [RFC7177] and [RFC6325].
	x, lowerBound, and upperBound are local integer variables. The MTU-		x, lowerBound, and upperBound are local integer variables. The MTU-
	probe and MTU-ack PDUs are specified in Section 3 of [RFC7176].		probe and MTU-ack PDUs are specified in Section 3 of [RFC7176].
	Step 0: RB1 sends an MTU-probe padded to the size of link-wide Lz.		Step 0: RB1 sends an MTU-probe padded to the size of link-wide Lz.
	1) If RB1 successfully receives the MTU-ack from RB2 to the probe of		1) If RB1 successfully receives the MTU-ack from RB2 to the probe of
	the value of link-wide Lz within k tries (where k is a		the value of link-wide Lz within k tries (where k is a
	configurable parameter whose default is 3. One Round Trip Time		configurable parameter whose default is 3. One Round Trip Time
	(RTT) between the two adjacent RBridges is RECOMMENDED to be used		(RTT) between the two adjacent RBridges is RECOMMENDED to be used
	as the minimum interval between two successive probes. Note that		as the minimum interval between two successive probes. Note that
	RTT estimation is out of the scope for this document. If operators		RTT estimation is out of the scope for this document. If
	cannot not estimate the RTT, the default value 5-millisecond		operators cannot not estimate the RTT, the default value
	should be assumed.), link MTU size is set to the size of link-wide		5-millisecond should be assumed.), link MTU size is set to the
	Lz and stop.		size of link-wide Lz and stop.
	2) RB1 tries to send an MTU-probe padded to the size 1470.		2) RB1 tries to send an MTU-probe padded to the size 1470.
	a) If RB1 fails to receive an MTU-ack from RB2 after k tries (An		a) If RB1 fails to receive an MTU-ack from RB2 after k tries (An
	MTU-ack should be considered to have failed two RTT after the		MTU-ack should be considered to have failed two RTT after the
	probe is sent out.), RB1 sets the "failed minimum MTU test"		probe is sent out.), RB1 sets the "failed minimum MTU test" flag
	flag for RB2 in RB1's Hello and stop.		for RB2 in RB1's Hello and stop.
	b) Link MTU size is set to 1470, lowerBound is set to 1470,		b) Link MTU size is set to 1470, lowerBound is set to 1470,
	upperBound is set to the link-wide Lz, x is set to [(lowerBound		upperBound is set to the link-wide Lz, x is set to [(lowerBound
	+ upperBound)/2], rounded down to the nearest integer.		+ upperBound)/2], rounded down to the nearest integer.
	Step 1: RB1 tries to send an MTU-probe padded to the size x.		Step 1: RB1 tries to send an MTU-probe padded to the size x.
	1) If RB1 fails to receive an MTU-ack from RB2 after k tries:		1) If RB1 fails to receive an MTU-ack from RB2 after k tries:
	upperBound is set to x-1 and x is set to [(lowerBound +		upperBound is set to x-1 and x is set to [(lowerBound +
	upperBound)/2], rounded down to the nearest integer.		upperBound)/2], rounded down to the nearest integer.
	2) If RB1 receives an MTU-ack to a probe of size x from RB2:		2) If RB1 receives an MTU-ack to a probe of size x from RB2:
	link MTU size is set to x, lowerBound is set to x and x is set		link MTU size is set to x, lowerBound is set to x and x is set
	to [(lowerBound + upperBound)/2], rounded down to the nearest		to [(lowerBound + upperBound)/2], rounded down to the nearest
	integer. If lowerBound equals upperBound-1 then x is set to		integer. If lowerBound equals upperBound-1 then x is set to
	upperBound.		upperBound.
	3) If lowerBound >= upperBound or Step 1 has been repeated n times		3) If lowerBound >= upperBound or Step 1 has been repeated n times
	(where n is a configurable parameter whose default value is 5),		(where n is a configurable parameter whose default value is 5),
	stop.		stop.
	4) Repeat Step 1.		4) Repeat Step 1.
	After the testing, the two connected RBridges agree on the value of		After the testing, the two connected RBridges agree on the value of
	the link MTU size. MTU testing is only done in the Designated VLAN		the link MTU size. MTU testing is only done in the Designated VLAN
	[RFC7177]. Since the execution of the above algorithm can be resource		[RFC7177]. Since the execution of the above algorithm can be
	consuming, it is RECOMMENDED that the Designated RBRidge (DRB		resource consuming, it is RECOMMENDED that the Designated RBRidge
	[RFC7177]) take the responsibility to do the testing. Multicast MTU-		(DRB [RFC7177]) take the responsibility to do the testing. Multicast
	probes are used instead of unicast when multiple RBridges are desired		MTU- probes are used instead of unicast when multiple RBridges are
	to respond with an MTU-ack on the link. The Binary Search Algorithm		desired to respond with an MTU-ack on the link. The Binary Search
	given here is a way to minimize the probing attempts; it reduces the		Algorithm given here is a way to minimize the probing attempts; it
	number of multicast packets for MTU-probing.		reduces the number of multicast packets for MTU-probing.
	The following rules are designed to determine whether the		The following rules are designed to determine whether the
	aforementioned "Condition" holds.		aforementioned "Condition" holds.
	RBridges have figured out the upper bound and lower bound for the		RBridges have figured out the upper bound and lower bound for the
	link MTU size from the execution of the above algorithm. If Sz is		link MTU size from the execution of the above algorithm. If Sz is
	smaller than the lower bound or greater than the upper bound,		smaller than the lower bound or greater than the upper bound,
	RBridges can directly judge whether the link supports Sz without MTU-		RBridges can directly judge whether the link supports Sz without MTU-
	probing.		probing.
	(a) If "lowerBound" >= Sz. This link can support Sz.		(a) If "lowerBound" >= Sz. This link can support Sz.
	(b) Else if "upperBound" <= Sz. This link cannot support Sz.		(b) Else if "upperBound" <= Sz. This link cannot support Sz.
	Otherwise, RBridges SHOULD test whether the link can support Sz as in		Otherwise, RBridges SHOULD test whether the link can support Sz as in
	item (c) below. If they do not, the only safe assumption will be that		item (c) below. If they do not, the only safe assumption will be
	the link cannot support Sz. This assumption, without testing, might		that the link cannot support Sz. This assumption, without testing,
	rule out the use of a link that can, in fact, handle packets up to		might rule out the use of a link that can, in fact, handle packets up
	Sz. In the worst case, this might result in unnecessary network		to Sz. In the worst case, this might result in unnecessary network
	partition.		partition.
	(c) "lowerBound" < Sz < "upperBound". RBridges probe the link with		(c) "lowerBound" < Sz < "upperBound". RBridges probe the link with
	MTU-probe messages padded to Sz. If an MTU-ack is received within		MTU-probe messages padded to Sz. If an MTU-ack is received
	k tries, this link can support Sz. Otherwise, this link cannot		within k tries, this link can support Sz. Otherwise, this link
	support Sz. Through this test, the lower bound and upper bound of		cannot support Sz. Through this test, the lower bound and upper
	link MTU size can be updated accordingly.		bound of link MTU size can be updated accordingly.
	4. Refreshing Sz		4. Refreshing Sz
	RBridges may join or leave the campus, which may change Sz.		RBridges may join or leave the campus, which may change Sz.
	1) Joining		1) Joining
	a) When a new RBridge joins the campus and its		a) When a new RBridge joins the campus and its
	originatingL1LSPBufferSize is smaller than current Sz,		originatingL1LSPBufferSize is smaller than current Sz, reporting
	reporting its originatingL1LSPBufferSize in its LSPs will cause		its originatingL1LSPBufferSize in its LSPs will cause other
	other RBridges decrease their Sz. Then any LSP greater than the		RBridges decrease their Sz. Then any LSP greater than the reduced
	reduced Sz MUST be split and/or the LSP contents in the campus		Sz MUST be split and/or the LSP contents in the campus MUST be
	MUST be otherwise redistributed so that no LSP is greater than		otherwise redistributed so that no LSP is greater than the new Sz.
	the new Sz.
	b) If the joining RBridge's originatingL1LSPBufferSize is equal to		b) If the joining RBridge's originatingL1LSPBufferSize is equal to
	or bigger than current Sz, reporting its		or bigger than current Sz, reporting its
	originatingL1LSPBufferSize will not change Sz.		originatingL1LSPBufferSize will not change Sz.
	2) Leaving		2) Leaving
	a) From the specification of the Joining process, we know it's		a) From the specification of the Joining process, we know it's
	non-applicable that an RBridge leaves the campus while its		non-applicable that an RBridge leaves the campus while its
	originatingL1LSPBufferSize is smaller than Sz.		originatingL1LSPBufferSize is smaller than Sz.
	b) When an RBridge leaves the campus and its		b) When an RBridge leaves the campus and its
	originatingL1LSPBufferSize equals to Sz, its LSPs are purged		originatingL1LSPBufferSize equals to Sz, its LSPs are purged
	from the remaining campus after reaching MaxAge [IS-IS]. Sz MAY		from the remaining campus after reaching MaxAge [IS-IS]. Sz
	be recalculated and MAY increase. In other words, while in most		MAY be recalculated and MAY increase. In other words, while in
	cases RB1 ignores link state information for IS-IS unreachable		most cases RB1 ignores link state information for IS-IS
	RBridge RB2 [RFC7780], originatingL1LSPBufferSize is		unreachable RBridge RB2 [RFC7780], originatingL1LSPBufferSize
	meaningful. Its value, even from IS-IS unreachable RBridges, is		is meaningful. Its value, even from IS-IS unreachable
	used in determining Sz. This updates [RFC7780].		RBridges, is used in determining Sz. This updates [RFC7780].
	c) When an RBrige leaves the campus and its		c) When an RBrige leaves the campus and its
	originatingL1LSPBufferSize is greater than Sz, this will not		originatingL1LSPBufferSize is greater than Sz, this will not
	update Sz since Sz is determined by another RBridge with		update Sz since Sz is determined by another RBridge with
	smaller originatingL1LSPBufferSize.		smaller originatingL1LSPBufferSize.
	Frequent LSP "re-sizing" is harmful to the stability of the TRILL		Frequent LSP "re-sizing" is harmful to the stability of the TRILL
	campus, so, to avoid this, upward resizing SHOULD be dampened. When		campus, so, to avoid this, upward resizing SHOULD be dampened. When
	an upward resizing event is noticed by an RBridge, it is RECOMMENDED		an upward resizing event is noticed by an RBridge, it is RECOMMENDED
	that a timer be set at that RBridge. This is a configurable		that a timer be set at that RBridge. This is a configurable
	parameter, LSPresizeTime, whose default value is 300 seconds. Before		parameter, LSPresizeTime, whose default value is 300 seconds. Before
	this timer expires, all subsequent upward resizing will be dampened		this timer expires, all subsequent upward resizing will be dampened
	(ignored). Of course, in a well-configured campus with all RBridges		(ignored). Of course, in a well-configured campus with all RBridges
	configured to have the same originatingL1LSPBufferSize, no resizing		configured to have the same originatingL1LSPBufferSize, no resizing
	will be necessary. It does not matter if different RBridges have		will be necessary. It does not matter if different RBridges have
	different dampening timers or some RBridges re-size upward more		different dampening timers or some RBridges re-size upward more
	quickly than others.		quickly than others.
	If the refreshed Sz is smaller than the lower bound or greater than		If the refreshed Sz is smaller than the lower bound or greater than
	the upper bound of the tested link MTU size, the resource consuming		the upper bound of the tested link MTU size, the resource consuming
	link MTU size testing can be avoided according to rule (a) or (b)		link MTU size testing can be avoided according to rule (a) or (b)
	specified in Section 3. Otherwise, RBridges test the link MTU size		specified in Section 3. Otherwise, RBridges test the link MTU size
	according to rule (c).		according to rule (c).
	5. Relationship between Port MTU, Lz and Sz		5. Relationship between Port MTU, Lz and Sz
	When the port MTU of an RBridge is smaller than the local		When the port MTU of an RBridge is smaller than the local
	originatingL1SNPBufferSize of an RBridge (an inconsistent		originatingL1SNPBufferSize of an RBridge (an inconsistent
	configuration), that port SHOULD be disabled since, in any case, an		configuration), that port SHOULD be disabled since, in any case, an
	adjacency cannot be formed through such a port. On the other hand,		adjacency cannot be formed through such a port. On the other hand,
	when an RBridge receives an LSP or E-L1CS FS-LSP with size greater		when an RBridge receives an LSP or E-L1CS FS-LSP with size greater
	than the link-wide Lz or Sz but not greater than its port MTU size,		than the link-wide Lz or Sz but not greater than its port MTU size,
	this LSP is processed normally. If the size of an LSP is greater than		this LSP is processed normally. If the size of an LSP is greater
	the MTU size of a port over which it is to be propagated, this LSP		than the MTU size of a port over which it is to be propagated, this
	MUST NOT be sent over the port and an LSPTooLargeToPropagate alarm		LSP MUST NOT be sent over the port and an LSPTooLargeToPropagate
	shall be generated [IS-IS].		alarm shall be generated [IS-IS].
	6. LSP Synchronization		6. LSP Synchronization
	An RBridge participates in LSP synchronization on a link as soon as		An RBridge participates in LSP synchronization on a link as soon as
	it has at least one adjacency on that link that has advanced to at		it has at least one adjacency on that link that has advanced to at
	least the 2-Way state [RFC7177]. On a LAN link, CSNP and PSNP PDUs		least the 2-Way state [RFC7177]. On a LAN link, CSNP and PSNP PDUs
	are used for synchronization. On a point-to-point link, only PSNP are		are used for synchronization. On a point-to-point link, only PSNP
	used.		are used.
	The CSNPs and PSNPs can be formatted in chunks of size at most the		The CSNPs and PSNPs can be formatted in chunks of size at most the
	link-wide Lz but are processed normally if received larger than that		link-wide Lz but are processed normally if received larger than that
	size. Since the link MTU size may not have been tested in the 2-Way		size. Since the link MTU size may not have been tested in the 2-Way
	state, link-wide Lz may be greater than the supported link MTU size.		state, link-wide Lz may be greater than the supported link MTU size.
	In that case, a CSNP or PSNP may be discarded. After the link MTU		In that case, a CSNP or PSNP may be discarded. After the link MTU
	size is successfully tested, RBridges will begin to format these PDUs		size is successfully tested, RBridges will begin to format these PDUs
	in the size no greater than that MTU, therefore these PDUs will		in the size no greater than that MTU, therefore these PDUs will
	eventually get through.		eventually get through.
	Note that the link MTU size is frequently greater than Sz. Link-local		Note that the link MTU size is frequently greater than Sz. Link-
	PDUs are limited in the size by the link MTU size rather than Sz,		local PDUs are limited in the size by the link MTU size rather than
	which, when Lz is greater than Sz, promises a reduction in the number		Sz, which, when Lz is greater than Sz, promises a reduction in the
	of PDUs and a faster LSP synchronization process.		number of PDUs and a faster LSP synchronization process.
	7. Recommendations for Traffic Link MTU Size Testing		7. Recommendations for Traffic Link MTU Size Testing
	Sz and link-wide Lz are used to limit the size of most TRILL IS-IS		Sz and link-wide Lz are used to limit the size of most TRILL IS-IS
	PDUs. They are different from the MTU size restricting the size of		PDUs. They are different from the MTU size restricting the size of
	TRILL Data packets. The size of a TRILL Data packet is restricted by		TRILL Data packets. The size of a TRILL Data packet is restricted by
	the physical MTU of the ports and links the packet traverses. It is		the physical MTU of the ports and links the packet traverses. It is
	possible that a TRILL Data packet successfully gets through the		possible that a TRILL Data packet successfully gets through the
	campus but its size is greater than Sz or link-wide Lz values.		campus but its size is greater than Sz or link-wide Lz values.
	The algorithm defined for link MTU size testing can also be used in		The algorithm defined for link MTU size testing can also be used in
	TRILL traffic MTU size testing; in that case the link-wide Lz used in		TRILL traffic MTU size testing; in that case the link-wide Lz used in
	that algorithm is replaced by the port MTU of the RBridge sending MTU		that algorithm is replaced by the port MTU of the RBridge sending MTU
	probes. The successfully tested size X MAY be advertised as an		probes. The successfully tested size X MAY be advertised as an
	attribute of this link using MTU sub-TLV defined in [RFC7176].		attribute of this link using MTU sub-TLV defined in [RFC7176].
	Unlike RBridges, end stations do not participate in the exchange of		Unlike RBridges, end stations do not participate in the exchange of
	TRILL IS-IS PDUs; therefore, they cannot grasp the traffic link MTU		TRILL IS-IS PDUs; therefore, they cannot grasp the traffic link MTU
	size from a TRILL campus automatically. An operator may collect these		size from a TRILL campus automatically. An operator may collect
	values using network management tools such as TRILL ping or		these values using network management tools such as TRILL ping or
	TraceRoute. Then, the path MTU can be set as the smallest tested link		TraceRoute. Then, the path MTU can be set as the smallest tested
	MTU on this path; and end stations should not generate frames that,		link MTU on this path; and end stations should not generate frames
	when encapsulated as TRILL Data packets, exceed this path MTU.		that, when encapsulated as TRILL Data packets, exceed this path MTU.
	8. Backwards Compatibility		8. Backwards Compatibility
	There can be a mixture of Lz-ignorant and Lz-aware RBridges on a		There can be a mixture of Lz-ignorant and Lz-aware RBridges on a
	link. This will act properly although, it may not be as efficient as		link. This will act properly although, it may not be as efficient as
	it would be if all RBridges on the link are Lz-aware.		it would be if all RBridges on the link are Lz-aware.
	For an Lz-ignorant RBridge, TRILL IS-IS PDUs are always formatted not		For an Lz-ignorant RBridge, TRILL IS-IS PDUs are always formatted not
	greater than Sz. Lz-aware RBridges as receivers can handle these PDUs		greater than Sz. Lz-aware RBridges as receivers can handle these
	since they cannot be greater than the link-wide Lz.		PDUs since they cannot be greater than the link-wide Lz.
	For an Lz-aware RBridge, in the case that link-wide Lz is greater		For an Lz-aware RBridge, in the case that link-wide Lz is greater
	than Sz, larger link-local TRILL IS-IS PDUs can be sent out to gain		than Sz, larger link-local TRILL IS-IS PDUs can be sent out to gain
	efficiencies. Lz-ignorant RBridges as receivers will have no problem		efficiencies. Lz-ignorant RBridges as receivers will have no problem
	handling them since the originatingL1LSPBufferSize value of these		handling them since the originatingL1LSPBufferSize value of these
	RBridges had been tested and the link-wide Lz is not greater than		RBridges had been tested and the link-wide Lz is not greater than
	that value.		that value.
	An Lz-ignorant RBridge might not support the link MTU testing		An Lz-ignorant RBridge might not support the link MTU testing
	algorithm defined in Section 3 but could be using some algorithm just		algorithm defined in Section 3 but could be using some algorithm just
	to test for Sz MTU on the link. In any case, if an RBridge per		to test for Sz MTU on the link. In any case, if an RBridge per
	[RFC6325] receives an MTU-probe, it MUST respond with an MTU-ack		[RFC6325] receives an MTU-probe, it MUST respond with an MTU-ack
	padded to the same size as the MTU-probe.		padded to the same size as the MTU-probe.
	9. Security Considerations		9. Security Considerations
	This document raises no significant new security issues for TRILL. In		This document raises no significant new security issues for TRILL.
	TRILL, RBridges are generally considered to be trusted devices.		In TRILL, RBridges are generally considered to be trusted devices.
	Protection against forged TRILL IS-IS PDUs, including forged Hellos		Protection against forged TRILL IS-IS PDUs, including forged Hellos
	containing originatingSNPBufferSize APP-subTLVs, can be obtained		containing originatingSNPBufferSize APP-subTLVs, can be obtained
	through IS-IS PDU cryptographic authentication [RFC5310]. The worst		through IS-IS PDU cryptographic authentication [RFC5310]. The worst
	that an RBridge can do by reporting an erroneous		that an RBridge can do by reporting an erroneous
	originatingSNPBufferSize is reduce Lz to Sz and thus make unavailable		originatingSNPBufferSize is reduce Lz to Sz and thus make unavailable
	the optimization of being able to use link MTUs that exceed the		the optimization of being able to use link MTUs that exceed the
	campus wide MTU for link local TRILL IS-IS PDUs.		campus wide MTU for link local TRILL IS-IS PDUs.
	For general and adjacency related TRILL security considerations, see		For general and adjacency related TRILL security considerations, see
	[RFC6325] and [RFC7177].		[RFC6325] and [RFC7177].
	10. Additions to Configuration		10. Additions to Configuration
	Implementation of the features specified in this document adds two		Implementation of the features specified in this document adds two
	RBridge configuration parameters as follows:		RBridge configuration parameters as follows:
	10.1. Per RBridge Configuration		10.1. Per RBridge Configuration
	Each RBridge implementing the RECOMMENDED LSP re-sizing damping		Each RBridge implementing the RECOMMENDED LSP re-sizing damping
	strategy specified in Section 4 has an LSPresizeTime parameter that		strategy specified in Section 4 has an LSPresizeTime parameter that
	is an integer in the range of 0-65,535 which defaults to 300. It is		is an integer in the range of 0-65,535 which defaults to 300. It is
	the number of seconds for which an RBridge determines that Sz has		the number of seconds for which an RBridge determines that Sz has
	increased before it will create any LSP or E-L1FS FS-LSP fragments.		increased before it will create any LSP or E-L1FS FS-LSP fragments.
	10.2. Per RBridge Port Configuration		10.2. Per RBridge Port Configuration
	Each RBridge port on which the calculation and use of Lz is		Each RBridge port on which the calculation and use of Lz is
	implemented has an originatingL1SNPBufferSize parameter that is an		implemented has an originatingL1SNPBufferSize parameter that is an
	integer in the range of 1,470-65,535. This parameter defaults to the		integer in the range of 1,470-65,535. This parameter defaults to the
	minimum of the size that the port can accommodate and the size link-		minimum of the size that the port can accommodate and the size link-
	local IS-IS PDU that the TRILL implementation can accommodate.		local IS-IS PDU that the TRILL implementation can accommodate.
	11. IANA Considerations		11. IANA Considerations
	IANA is requested to assign a new APPsub-TLV number from the range		IANA is requested to assign a new APPsub-TLV number from the range
	less than 256 in the "TRILL APPsub-TLV Types under IS-IS TLV 251		less than 256 in the "TRILL APPsub-TLV Types under IS-IS TLV 251
	Application Identifier 1" registry for the TRILL		Application Identifier 1" registry for the TRILL
	originatingSNPBufferSize sub-TLV defined in Section 2 of this		originatingSNPBufferSize sub-TLV defined in Section 2 of this
	document. The entry is as follows:		document. The entry is as follows:
	Type Name Reference		Type Name Reference
	---- ------------------------ ---------------		---- ------------------------ ---------------
	tbd originatingSNPBufferSize [this document]		tbd originatingSNPBufferSize [this document]
	12. Acknowledgements		12. Acknowledgements
	Authors would like to thank the comments and suggestions from Vishwas		Authors would like to thank the comments and suggestions from Vishwas
	Manral.		Manral.
	13. References		13. References
	13.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		13.1. Normative References
	Requirement Levels", BCP 14, RFC 2119, DOI
	10.17487/RFC2119, March 1997, <http://www.rfc-
	editor.org/info/rfc2119>.
	[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	and M. Fanto, "IS-IS Generic Cryptographic Authentication",		Requirement Levels", BCP 14, RFC 2119,
	RFC 5310, DOI 10.17487/RFC5310, February 2009,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc5310>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.		[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
	Ghanwani, "Routing Bridges (RBridges): Base Protocol		and M. Fanto, "IS-IS Generic Cryptographic
	Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,		Authentication", RFC 5310, DOI 10.17487/RFC5310, February
	<http://www.rfc-editor.org/info/rfc6325>.		2009, <http://www.rfc-editor.org/info/rfc5310>.
	[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and		[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
	V. Manral, "Transparent Interconnection of Lots of Links		Ghanwani, "Routing Bridges (RBridges): Base Protocol
	(TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May		Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
	2014, <http://www.rfc-editor.org/info/rfc7177>.		<http://www.rfc-editor.org/info/rfc6325>.
	[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D.,		[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
	and A. Banerjee, "Transparent Interconnection of Lots of		V. Manral, "Transparent Interconnection of Lots of Links
	Links (TRILL) Use of IS-IS", RFC 7176, DOI		(TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May
	10.17487/RFC7176, May 2014, <http://www.rfc-		2014, <http://www.rfc-editor.org/info/rfc7177>.
	editor.org/info/rfc7176>.
	[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding		[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
	Scope Link State PDUs (LSPs)", RFC 7356, DOI		D., and A. Banerjee, "Transparent Interconnection of Lots
	10.17487/RFC7356, September 2014, <http://www.rfc-		of Links (TRILL) Use of IS-IS", RFC 7176,
	editor.org/info/rfc7356>.		DOI 10.17487/RFC7176, May 2014,
			<http://www.rfc-editor.org/info/rfc7176>.
	[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,		[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
	Ghanwani, A., and S. Gupta, "Transparent Interconnection of		Scope Link State PDUs (LSPs)", RFC 7356,
	Lots of Links (TRILL): Clarifications, Corrections, and		DOI 10.17487/RFC7356, September 2014,
	Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,		<http://www.rfc-editor.org/info/rfc7356>.
	<http://www.rfc-editor.org/info/rfc7780>.
	[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.		[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
	Stokes, "Transparent Interconnection of Lots of Links		Ghanwani, A., and S. Gupta, "Transparent Interconnection
	(TRILL): End Station Address Distribution Information		of Lots of Links (TRILL): Clarifications, Corrections, and
	(ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357,		Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
	September 2014, <http://www.rfc-editor.org/info/rfc7357>.		<http://www.rfc-editor.org/info/rfc7780>.
	13.2. Informative References		[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
			Stokes, "Transparent Interconnection of Lots of Links
			(TRILL): End Station Address Distribution Information
			(ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357,
			September 2014, <http://www.rfc-editor.org/info/rfc7357>.
	[IS-IS] International Organization for Standardization,		13.2. Informative References
	"Information technology -- Telecommunications and
	information exchange between systems -- Intermediate System
	to Intermediate System intra-domain routeing information
	exchange protocol for use in conjunction with the protocol
	for providing the connectionless-mode network service (ISO
	8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
	[RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F.		[RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F.
	Hu, "Transparent Interconnection of Lots of Links (TRILL):		Hu, "Transparent Interconnection of Lots of Links (TRILL):
	Appointed Forwarders", RFC 8139, DOI 10.17487/RFC8139, June		Appointed Forwarders", RFC 8139, DOI 10.17487/RFC8139,
	2017, <http://www.rfc-editor.org/info/rfc8139>.		June 2017, <http://www.rfc-editor.org/info/rfc8139>.
	Author's Addresses		Authors' Addresses
	Mingui Zhang		Mingui Zhang
	Huawei Technologies		Huawei Technologies
	No. 156 Beiqing Rd. Haidian District		No. 156 Beiqing Rd. Haidian District
	Beijing 100095		Beijing 100095
	China		China
	Phone: +86-13810702575		Phone: +86-13810702575
	Email: zhangmingui@huawei.com		Email: zhangmingui@huawei.com
	skipping to change at page 14, line 31		skipping to change at page 13, line 36
	Email: zhangxudong@huawei.com		Email: zhangxudong@huawei.com
	Donald E. Eastlake, 3rd		Donald E. Eastlake, 3rd
	Huawei Technologies		Huawei Technologies
	155 Beaver Street		155 Beaver Street
	Milford, MA 01757		Milford, MA 01757
	United States		United States
	Phone: +1-508-333-2270		Phone: +1-508-333-2270
	EMail: d3e3e3@gmail.com		Email: d3e3e3@gmail.com
	Radia Perlman		Radia Perlman
	EMC		EMC
	2010 256th Avenue NE, #200		2010 256th Avenue NE, #200
	Bellevue, WA 98007		Bellevue, WA 98007
	United States		United States
	Email: radia@alum.mit.edu		Email: radia@alum.mit.edu
	Somnath Chatterjee		Somnath Chatterjee
	Cisco Systems		Cisco Systems
	SEZ Unit, Cessna Business Park		SEZ Unit, Cessna Business Park
	Outer Ring Road		Outer Ring Road
	Bangalore - 560087		Bangalore - 560087
	India		India
	Email: somnath.chatterjee01@gmail.com		Email: somnath.chatterjee01@gmail.com
End of changes. 111 change blocks.
	253 lines changed or deleted		242 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/