< draft-hao-trill-address-flush-00.txt		draft-hao-trill-address-flush-01.txt >
	TRILL Working Group Weiguo Hao		TRILL Working Group Weiguo Hao
	INTERNET-DRAFT Donald Eastlake		INTERNET-DRAFT Donald Eastlake
	Intended status: Proposed Standard Huawei		Intended status: Proposed Standard Yizhou Li
	Expires: April 17, 2015 October 18, 2015		Huawei
			Expires: September 20, 2015 March 21, 2016
	TRILL: Address Flush Protocol		TRILL: Address Flush Message
	<draft-hao-trill-address-flush-00.txt>		<draft-hao-trill-address-flush-01.txt>
	Abstract		Abstract
	The TRILL (TRansparent Interconnection of Lots of Links) protocol, by		The TRILL (TRansparent Interconnection of Lots of Links) protocol, by
	default, learns end station addresses from observing the data plane.		default, learns end station addresses from observing the data plane.
	This document specifies an optional message by which an originating		This document specifies a message by which an originating TRILL
	TRILL switch can explicitly flush addresses learned by other TRILL		switch can explicitly request other TRILL switches to flush certain
	switches through the egress of data ingress by that originating TRILL		MAC reachability learned through the egress of TRILL Data packets.
	switch. This is a supplement to the TRILL automatic address		This is a supplement to the TRILL automatic address forgetting and
	forgetting and can assist in achieving more rapid convergence.		can assist in achieving more rapid convergence in case of topoogy or
			configuration change.
	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 to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Distribution of this document is unlimited. Comments should be sent		Distribution of this document is unlimited. Comments should be sent
	to the TRILL working group mailing list.		to the TRILL working group mailing list: trill@ietf.org.
	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), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft		http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
	Shadow Directories can be accessed at		Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	INTERNET-DRAFT Address Flush Protocol		INTERNET-DRAFT Address Flush Message
	Table of Contents		Table of Contents
	1. Introduction............................................3		1. Introduction............................................3
	1.1 Terminology and Acronyms...............................3		1.1 Terminology and Acronyms...............................3
	2. Address Flush Message Details...........................5		2. Address Flush Message Details...........................5
			2.1 VLAN Block Case........................................6
			2.2 Extensible Case........................................7
	3. IANA Considerations.....................................9		3. IANA Considerations....................................11
	4. Security Considerations.................................9		4. Security Considerations................................11
	Normative References......................................10		Normative References......................................12
	Informative References....................................10		Informative References....................................12
	Acknowledgements..........................................10		Acknowledgements..........................................12
	Authors' Addresses........................................11		Authors' Addresses........................................13
	INTERNET-DRAFT Address Flush Protocol		INTERNET-DRAFT Address Flush Message
	1. Introduction		1. Introduction
	Edge TRILL (Transparent Interconnection of Lots of Links [RFC6325])		Edge TRILL (Transparent Interconnection of Lots of Links) switches
	switches, also called RBridges, by default learn end station MAC		[RFC6325] [RFC7780], also called edge RBridges, by default learn end
	addresses from observing the data plane. On receipt of a native frame		station MAC address reachability from observing the data plane. On
	from an end station, they would learn the local MAC address		receipt of a native frame from an end station, they would learn the
	attachment of the source end station. And on egressing		local MAC address attachment of the source end station. And on
	(decapsulating) a remotely originated TRILL Data frame, they learn		egressing (decapsulating) a remotely originated TRILL Data packet,
	the remote MAC address and remote attachment TRILL switch. Such		they learn the remote MAC address and remote attachment TRILL switch.
	learning is all appropriately scoped by data label (VLAN or Fine		Such learning is all scoped by data label (VLAN or Fine Grained Label
	Grained Label [RFC7172]).		[RFC7172]).
	TRILL has mechanisms for timing out such learning and appropriately		TRILL has mechanisms for timing out such learning and appropriately
	clearing it based on some network connectivity changes; however,		clearing it based on some network connectivity and configuration
	there are circumstances under which it would be helpful for a TRILL		changes; however, there are circumstances under which it would be
	switch to be able to explicitly flush (clear) learned end station		helpful for a TRILL switch to be able to explicitly flush (purge)
	reachability information to achieve more rapid convergence (see, for		certain learned end station reachability information in remote
	example, Section 6.2 of [RFC4762]). Obivously a TRILL switch R1 can		RBridges to achieve more rapid convergence (see, for example,
	easily flush any locally learned addresses it wants. This document		[TCaware] and Section 6.2 of [RFC4762]).
	specifies an optional message to request flushing such learned
	address information at remote TRILL switches. This Address Flush		A TRILL switch R1 can easily flush any locally learned addresses it
	message makes use of the RBridge Channel facility [RFC7178], which		wants. This document specifies an RBridge Channel protocol [RFC7178]
	supports typed message transmission between RBridges.		message to request flushing address information learned from
			decapsulating at remote RBridges.
	1.1 Terminology and Acronyms		1.1 Terminology and Acronyms
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	This document uses the terms and acronyms defined in [RFC6325] and		This document uses the terms and acronyms defined in [RFC6325] and
	[RFCchannel] as well as the following:		[ChannelTunnel] as well as the following:
	AFN - Address Family Number ([RFC4760] where it is called Address		Data Label - VLAN or FGL.
	Family Identifier (AFI)).
			Edge TRILL switch - A TRILL switch attached to one or more links
			that provide end station service.
	FGL - Fine Grained Label [RFC7172].		FGL - Fine Grained Label [RFC7172].
	Management VLAN - A VLAN in which all TRILL switches in a campus		Management VLAN - A VLAN in which all TRILL switches in a campus
	indicate interest so that multi-destinaiton TRILL Data packets,		indicate interest so that multi-destinaiton TRILL Data packets,
	including RBridge Channel messages [RFCchannel], sent with that		including RBridge Channel messages [ChannelTunnel], sent with
	VLAN as the Inner.VLAN will be delivered to all TRILL switches		that VLAN as the Inner.VLAN will be delivered to all TRILL
	in the campus. Usually no end station service is offered in the		switches in the campus. Usually no end station service is
	Management VLAN.		offered in the Management VLAN.
			INTERNET-DRAFT Address Flush Message
	RBridge - A alterntive name for a TRILL switch.		RBridge - A alterntive name for a TRILL switch.
	TRILL switch - A device implementing the TRILL protocol.		TRILL switch - A device implementing the TRILL protocol.
	INTERNET-DRAFT Address Flush Protocol		INTERNET-DRAFT Address Flush Message
	Edge TRILL switch - A TRILL switch attached to one or more links
	that provide end station service.
	INTERNET-DRAFT Address Flush Protocol
	2. Address Flush Message Details		2. Address Flush Message Details
	The Address Flush message makes use of the RBridge Channel protocol		The Address Flush message is an RBridge Channel protocol message
	[RFC7178].		[RFC7178].
	Although initial use is expected to be to flush 48-bit MAC addresses
	[RFC7042], the protocol accommodates flushing other types of end
	station addresses; there have been suggestion for TRILL switches to
	learn IP addresses from the data plane [INFOCOM], TRILL might be
	extended to accommodate 64-bit MAC addresses, or similar future
	extensions might benefit from the ability to flush other types of
	learned addresses.
	The general structure of an RBridge Channel packet on a link between		The general structure of an RBridge Channel packet on a link between
	TRILL switches is shown in Figure 1 below. The type of RBridge		TRILL switches is shown in Figure 1 below. The type of RBridge
	Channel packet is given by a Protocol field in the RBridge Channel		Channel packet is given by the Protocol field in the RBridge Channel
	Header that indicates how to interpret the Channel Protocol Specific		Header that indicates how to interpret the Channel Protocol Specific
	Payload [RFC7178l].		Payload [RFC7178].
	+-----------------------------------+		+----------------------------------+
	| Link Header |		| Link Header |
	+-----------------------------------+		+----------------------------------+
	| TRILL Header |		| TRILL Header |
	+--------------------------------+ |		+----------------------------------+
	| Inner Ethernet Addresses | |		| Inner Ethernet Addresses |
	+--------------------------------+ |		+----------------------------------+
	| Data Label (VLAN or FGL) | |		| Data Label (VLAN or FGL) |
	+--------------------------------+--+		+----------------------------------+
	| RBridge Channel Header |		| RBridge Channel Header |
	+-----------------------------------+		+----------------------------------+
	| Channel Protocol Specific Payload |		| Channel Protocol Specific Payload|
	+-----------------------------------+		+----------------------------------+
	| Link Trailer (FCS if Ethernet) |		| Link Trailer (FCS if Ethernet)|
	+-----------------------------------+		+----------------------------------+
	Figure 1. RBridge Channel Packet Structure		Figure 1. RBridge Channel Protocol Message Structure
	An Address Flush RBridge Channel message normally applies to		An Address Flush RBridge Channel message by default applies to
	addresses within the VLAN or FGL [RFC7178] Data Label in the TRILL		addresses within the Data Label in the TRILL Header. Address Flush
	Header. Address Flush protocol messages are usually sent as multi-		protocol messages are usually sent as multi-destination packets
	destination packets (TRILL Header M bit equal to one) so as to reach		(TRILL Header M bit equal to one) so as to reach all TRILL switches
	all TRILL switches offering end station service in the VLAN or FGL		offering end station service in the VLAN or FGL specified by the Data
	specified by the Data Label. However, and address flush protocol		Label. Such messages SHOULD be sent at priority 6 since they are
	message can be sent unicast, if it is desired to clear addresses at		important control messages but lower priority than control messages
	one TRILL switch only. And there are provisions for indicating the		that establish or maintain adjacency.
	Data Label with the address(es) to be flushed for cases where the
	address flush protocol message is sent over a Managagement VLAN or
	the like.
	Figure 2 below expands the RBridge Channel Header and Channel		Nevertheless:
			- There are provisions for optionally indicating the Data Label(s)
			to be flushed for cases where the Address Flush message is sent
			over a Managagement VLAN or the like.
			- An Address Flush message can be sent unicast, if it is desired to
			clear addresses at one TRILL switch only.
	INTERNET-DRAFT Address Flush Protocol		INTERNET-DRAFT Address Flush Message
	Protocol Specific Payload from Figure 1 for the case of the Address		2.1 VLAN Block Case
	Flush message.
			Figure 2 below expands the RBridge Channel Header and Channel
			Protocol Specific Payload from Figure 1 for the case of the VLAN
			based Address Flush message. This form of the Address Flush message
			is optimized for flushing MAC addressed based on nickname and blocks
			of VLANs.
	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
	RBridge Channel Header:		RBridge Channel Header:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RBridge-Channel (0x8946) | 0x0 | Ch. Protocol # (TBD) |		| RBridge-Channel (0x8946) | 0x0 | Channel Protocol = TBD |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags | ERR |		| Flags | ERR |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Address Flush Protocol Specific:		Address Flush Protocol Specific:
	+-+-+-----------+---------------+		+-+-+-+-+-+-+-+-+
	| SF| RESV | K |		| K-nicks |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ADDRESSES RECORD 1 |		| Nickname 1 | Nickname 2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ADDRESSES RECORD 2 |		| Nickname ... | Nickname K-nicks |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ...		| K-VBs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ADDRESSES RECORD K |		| RESV | Start.VLAN 1 | RESV | End.VLAN 1 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| RESV | Start.VLAN 2 | RESV | End.VLAN 2 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| RESV | Start.VLAN ... | RESV | End.VLAN ... |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| RESV | Start.VLAN K-VBs | RESV | End.VLAN K-VBs |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2. Address Flush Channel Message Structure		Figure 2. Address Flush Message - VLAN Case
	The fields in Figure 2 related to the Address Flush message are as		The fields in Figure 2 related to the Address Flush message are as
	follows:		follows:
	Channel Protocol: The RBridge Channel Protocol value allocated		Channel Protocol: The RBridge Channel Protocol value allocated
	for Address Flush (see Section 3).		for Address Flush (see Section 3).
	SF: The 2-bit SF ("super flush") field values have the following		K-nicks: K-nicks is the number of nicknames present as an unsigned
	meanings:		integer. If this is zero, the ingress nickname in the TRILL
			Header is considerted to be the only nickname to which the
			message applies. If non-zero, it given the number of nicknames
			present to which the message applies. The messages flushes
			address learning due to egressing TRILL Data packets that had a
			ingress nicknam to which the message applies.
	0: No special effect.		INTERNET-DRAFT Address Flush Message
	1: All addresses learned at the receiving TRILL switch due to		Nickname: A listed nickname to which it is intended that the
	egressing TRILL Data packets fror the TRILL switch		Address Flush message apply. If an unknown or reserved
	originating this Address Flush message are flushed for the		nickname occurs in the list, it is ignored but the address
	data label in the TRILL Header. Any ADDRESS RECORDs in the		flush operation is still executed with the other nicknames. If
	rest of the message for that data label can be ignored but		an incorrect nickname occurs in the list, so some address
	there may be ADDRESS RECORDs present that apply to other		learning is flushed that should not have been flush, the
	data labels.		network will strill operate correctly but will be less
			efficient as the incorrectly flushed learning is re-learned.
	2: All addresses learned at the receiving TRILL switch due to		K-VBs: K-VBs is the number of VLAN blocks present as an unsigned
	egressing TRILL Data packets from the TRILL switch		integer. If this byte is zero, the message is the more general
	originating this Address Flush message are flushed across		format specified in Section 2.2. If it is non-zero, it gives
	all data labels. The remainder of the Address Flush message,		the number of blocks of VLANs present.
	including the value of K, are ignored.
	INTERNET-DRAFT Address Flush Protocol		RESV: 4 reserved bits. MUST be sent as zero and ignored on
			receipt.
	3: Reserved. Ignored on receipt.		Start.VLAN, End.VLAN: These 12-bit fields give the beginning and
			ending VLAN IDs of a block of VLANs. The block includes both
			the starting and endiing values so a block of size one is
			indicated by setting End.VLAN equal to Start.VLAN. If
			Start.VLAN is 0x000, it is treated as if it was 0x001. If
			End.VLAN is 0xFFF, it is treated as if it was 0xFFE. If
			End.VLAN is smaller than Start.VLAN, considering both as
			unsigned integers, that VLAN block is ignored but the address
			flush operation is still executed with any other VLAN blocks in
			the message.
	RESV: 4 reserved flag bits. Must be sent as zero and ignored on		This message flushes all addresses learned from egressing TRILL Data
	recipet.		packets with an applicable nickname and a VLAN in any of the blocks
			given. To flush addresses for all VLANs, it is easy to specify a
			block covering all valid VLAN IDs, this is, from 0x001 to 0xFFE.
	K: The number of ADDRESS RECORDs present. See below.		2.2 Extensible Case
	The structure of the ADDRESSES RECORD is as follows:		A more general form of the Address Flush message is provided to
			support flushing by FGL and more efficient encodings of VLANs and
			FGLs where using a set of contiguous blocks if cumbersome. This form
			is also extensible to handle future requirements.
			It is indicated by a zero in the byte shown in Figure 2 as "K-VBs".
			INTERNET-DRAFT Address Flush Message
	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
			RBridge Channel Header:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|L|N|R| Size | Count | AFN |		| RBridge-Channel (0x8946) | 0x0 | Channel Protocol = TBD |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Data Label (Optional)		| Flags | ERR |
	+-+-+-+-+-+-+-+-+-+-+-+-+-...		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Address 1 ...		Address Flush Protocol Specific:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+
	| Address 2 ...		| K-nicks |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
	| ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
	| Address K ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Nickname 1 | Nickname 2 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Nickname ... | Nickname K-nicks |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| 0 | Type | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type Dependent Information
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
	Figure 3. Structure of ADDRESSES RECORD		Figure 3. Address Flush Message - Extensible Case
	L: Label present. If this bit is a one, the optional Data Label		Channel Protocol, K-nicks, Nickname: These fields are as specified
	shown in present. If it is zero, there is no data label and		in Section 2.1.
	the addresses listed are withing the data labe given in the
	TRILL Header.
	N: No Specific Addresses. If this bit is one and Count is		Type: If the byte immediately before the Type field, which is the
	zero and L is one, then flush all addresses learned at the		byte labeled "K-VBs" in Figure 2, is zero, the the Type byte
	receiving TRILL switch due to egressing TRILL Data packets		indicates the type of extended Address Flush message as
	from the TRILL switch originating this Address Flush message		follows:
	are flushed for the Data Label given in the ADDRESS RECORD.
	If this bit is zero or Count is non-zero or L is zero, they
	this special flush action is not performed.
	R: A reserved bit that MUST be sent as zero and is ignored on		Type Description
	receipt.		------ ------------
			0 Reserved
			1 Bit Map of VLANs
			2 Blocks of FGLs
			3 List of FGLs
			4 Bit Map of FGLs
			5-254 Unassigned
			255 Reserved
	Size: The size of each Address in bytes. The presence of this		Length: The length of the remaining information in the Address
	field makes it possible for a receiving TRILL switch to skip		Flush message.
	an ADDRESS RECORD even if it does not understand the value
	in the AFN field. Size MUST NOT be zero; a zero size field
	indicates a corrupt Addresses Flush message and the entire
	message is ignored. MUST be the correct size for an Address
	INTERNET-DRAFT Address Flush Protocol		Type Dependent Information: Depends on the value of the type field
			as further specified below in this section.
	of the type indicated by the AFN field, for example 6 for		INTERNET-DRAFT Address Flush Message
	48-bit MAC addresses. If these conditions are violated, the
	Address Flush message is discarded.
	Count: The number of occurrences of an Address to flush in this		Type 1
	ADDRESS RECORD. May be zero. All Addresses MUST fit within		Bit Map of VLANs: The Type Dependent Information consists of two
	the RBridge Channel Message. If they do not, the message is		bytes with the 12-bit starting VLAN ID N right justified (the top
	discarded.		4 bits are as specified above for RESV). This is followed by bytes
			with one bit per VLAN ID. The high order bit of the first byte is
			for VLAN N, the next to the highest order bit is for VLAN N+1, the
			low order bit of the first byte is for VLAN N+7, the high order
			bit of the second byte, if there is a second byte, is for VLAN
			N+8, and so on. If that bit is a one, the the Address Flush
			message applies to that VLAN. If that bit is a zero, then
			addresses that have been learned in that VLAN are not flushed.
			Note that Length MUST be at least 3. If Length is 0, 1, or 2 for a
			Type 1 extended Address Flush message, the message is corrupt and
			MUST be discarded. VLAN IDs do not wrap around. If there are
			enough bytes so that some bits correspond to VLAN ID 0xFFF or
			nigher, those bits are ignored but the message is still processed
			for bits corresponding to valid VLAN IDs.
	AFN: The Address Family Number for the type of addresses		Type 2
	present as assigned by IANA. (The AFN for 48-bit MAC		Blocks of FGLs: The Type Dependent Information consists of sets of
	addresses is 0x4005.)		Start.FGL and End.FGL numbers. The Address Flush information
			applies to the FGLs in that range, incluse. A single FGL is
			indicated by have both Start.FGL and End.FGL to the same value. If
			End.FGL is less than Start.FGL, considering them as unsigned
			integers, that block is ignored but the Address Flush message is
			still processed for any other blocks present. For this Type,
			Length MUST be a multiple of 6; if it is not, the message is
			considered corrup and MUST be discarded.
	Data Label: An optional Data Label (VLAN or FGL) in the same		Type 3
	format as Data Labels that appear in the TRILL Header.		List of FGLs: The Type Dependent Information consists of FGL numbers
	Included in an ADDRESS RECORD only if the L bit is a one.		each in 3 bytes. The Address Flush message applies to those FGLs.
			For this Type, Length MUST be a multiple of 3; if it is not, the
			message is considered corrup and MUST be discarded.
	Address: An instance of an address to be flushed.		Type 4
			Bit Map of FGLs: The Type Dependent Information consists of three
			bytes with the 24-bit starting FGL N. This is followed by bytes
			with one bit per FGL. The high order bit of the first byte is for
			FGL N, the next to the highest order bit is for FGL N+1, the low
			order bit of the first byte is for FGL N+7, the high order bit of
			the second byte, if there is a second byte, is for FGL N+8, and so
			on. If that bit is a one, the the Address Flush message applies to
			that FGL. If that bit is a zero, then addresses that have been
			learned in that FGL are not flushed. Note that Length MUST be at
			least 4. If Length is 0, 1, 2, or 3 for a Type 1 extended Address
			Flush message, the message is corrupt and MUST be discarded. FGLs
			do not wrap around. If there are enough bytes so that some bits
			correspond to an FGL higher than 0xFFFFFF, those bits are ignored
			but the message is still processed for bits corresponding to valid
	INTERNET-DRAFT Address Flush Protocol		INTERNET-DRAFT Address Flush Message
			FGLs.
			There is no provision for a list of VLAN IDs as there are few enough
			of them that an arbitrary subset of VLAN IDs can always be
			represented as a bit map.
			INTERNET-DRAFT Address Flush Message
	3. IANA Considerations		3. IANA Considerations
	IANA has allocated tbd1 for the Address Flush RBridge Channel		IANA is requested to assign TBD as the Address Flush RBridge Channel
	Protocol number from the range of RBridge Channel protocols allocated		Protocol number from the range of RBridge Channel protocols allocated
	by Standards Action [RFC7178].		by Standards Action [RFC7178].
			The added RBridge Channel protocols registry entry on the TRILL
			Parameters web page is as follows:
			Protocol Description Reference
			-------- -------------- ------------------
			TBD Address Flush [this document]
	4. Security Considerations		4. Security Considerations
	The Address Flush RBridge Channel Protocol provides no security		The Address Flush RBridge Channel Protocol provides no security
	assurances or features. However, use of the Address Flush protocol		assurances or features. However, use of the Address Flush protocol
	can be nested inside the RBridge Channel Tunnel Protocol [RFCtunnel]		can be nested inside the RBridge Channel Tunnel Protocol
	using the RBridge Channel message payload type. The Channel Tunnel		[ChannelTunnel] using the RBridge Channel message payload type. The
	protocol can provide some security services.		Channel Tunnel protocol can provide security services.
	See [RFC7178] for general RBridge Channel Security Considerations.		See [RFC7178] for general RBridge Channel Security Considerations.
	See [RFC6325] for general TRILL Security Considerations.		See [RFC6325] for general TRILL Security Considerations.
	INTERNET-DRAFT Address Flush Protocol		INTERNET-DRAFT Address Flush Message
	Normative References		Normative References
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4760] - Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
	"Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
	[RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A.		[RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A.
	Ghanwani, "RBridges: Base Protocol Specification", RFC 6325,		Ghanwani, "RBridges: Base Protocol Specification", RFC 6325,
	July 2011.		July 2011.
	[RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R.,		[RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R.,
	and D. Dutt, "Transparent Interconnection of Lots of Links		and D. Dutt, "Transparent Interconnection of Lots of Links
	(TRILL): Fine-Grained Labeling", RFC 7172, DOI		(TRILL): Fine-Grained Labeling", RFC 7172, DOI
	10.17487/RFC7172, May 2014, <http://www.rfc-		10.17487/RFC7172, May 2014, <http://www.rfc-
	editor.org/info/rfc7172>.		editor.org/info/rfc7172>.
	[RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.		[RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
	Ward, "Transparent Interconnection of Lots of Links (TRILL):		Ward, "Transparent Interconnection of Lots of Links (TRILL):
	RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May		RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May
	2014, <http://www.rfc-editor.org/info/rfc7178>.		2014, <http://www.rfc-editor.org/info/rfc7178>.
	Informative References		[RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
			Ghanwani, A., and S. Gupta, "Transparent Interconnection of
			Lots of Links (TRILL): Clarifications, Corrections, and
			Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
			<http://www.rfc-editor.org/info/rfc7780>.
	[INFOCOM] - Perlman, R., "RBridges: Transparent Routing", Proc.		Informative References
	Infocom 2005, March 2004.
	[RFC4762] - Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private		[RFC4762] - Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private
	LAN Service (VPLS) Using Label Distribution Protocol (LDP)		LAN Service (VPLS) Using Label Distribution Protocol (LDP)
	Signaling", RFC 4762, January 2007.		Signaling", RFC 4762, January 2007.
	[RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and		[ChannelTunnel] - Eastlake, D., M. Umair, Y. Li, "TRILL: RBridge
	IETF Protocol and Documentation Usage for IEEE 802 Parameters",		Channel Tunnel Protocol", draft-ietf-trill-channel-tunnel, work
	BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013,		in progress.
	<http://www.rfc-editor.org/info/rfc7042>.
	[RFCtunnel] - Eastlake, D., ... "TRILL: Channel Tunnel", draft-		[TCaware] - Y. Li, et al., "Aware Spanning Tree Topology Change on
	eastlake-trill-channel-tunnel, work in progress.		RBridges" draft-yizhou-trill-tc-awareness, work-in-progress.
	Acknowledgements		Acknowledgements
	The document was prepared in raw nroff. All macros used were defined		The document was prepared in raw nroff. All macros used were defined
	within the source file.		within the source file.
	INTERNET-DRAFT Address Flush Protocol		INTERNET-DRAFT Address Flush Message
	Authors' Addresses		Authors' Addresses
	Weiguo Hao		Weiguo Hao
	Huawei Technologies		Huawei Technologies
	101 Software Avenue,		101 Software Avenue,
	Nanjing 210012, China		Nanjing 210012, China
	Phone: +86-25-56623144		Phone: +86-25-56623144
	Email: haoweiguo@huawei.com		Email: haoweiguo@huawei.com
	Donald E. Eastlake, 3rd		Donald E. Eastlake, 3rd
	Huawei Technologies		Huawei Technologies
	155 Beaver Street		155 Beaver Street
	Milford, MA 01757 USA		Milford, MA 01757 USA
	Phone: +1-508-333-2270		Phone: +1-508-333-2270
	EMail: d3e3e3@gmail.com		EMail: d3e3e3@gmail.com
	INTERNET-DRAFT Address Flush Protocol		Yizhou Li
			Huawei Technologies
			101 Software Avenue,
			Nanjing 210012
			China
			Phone: +86-25-56624629
			Email: liyizhou@huawei.com
			INTERNET-DRAFT Address Flush Message
	Copyright, Disclaimer, and Additional IPR Provisions		Copyright, Disclaimer, and Additional IPR Provisions
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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
End of changes. 70 change blocks.
	187 lines changed or deleted		281 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/