< draft-salam-trill-oam-framework-02.txt		draft-salam-trill-oam-framework-03.txt >
	TRILL Working Group Samer Salam		TRILL Working Group Samer Salam
	INTERNET-DRAFT Tissa Senevirathne		INTERNET-DRAFT Tissa Senevirathne
	Intended Status: Informational Cisco		Intended Status: Informational Cisco
	Sam Aldrin		Sam Aldrin
	Donald Eastlake		Donald Eastlake
	Huawei		Huawei
	Expires: March 4, 2013 August 31, 2012		Expires: April 22, 2013 October 19, 2012
	TRILL OAM Framework		TRILL OAM Framework
	draft-salam-trill-oam-framework-02		draft-salam-trill-oam-framework-03
	Abstract		Abstract
	This document specifies a reference framework for Operations,		This document specifies a reference framework for Operations,
	Administration and Maintenance (OAM) in TRILL networks. The focus of		Administration and Maintenance (OAM) in TRILL networks. The focus of
	the document is on the fault and performance management aspects of		the document is on the fault and performance management aspects of
	TRILL OAM.		TRILL OAM.
	Status of this Memo		Status of this Memo
	skipping to change at page 2, line 24		skipping to change at page 2, line 24
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5		1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2 Relationship to Other OAM Work . . . . . . . . . . . . . . . 5		1.2 Relationship to Other OAM Work . . . . . . . . . . . . . . . 5
	2. TRILL OAM Model . . . . . . . . . . . . . . . . . . . . . . . . 6		2. TRILL OAM Model . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1 OAM Layering . . . . . . . . . . . . . . . . . . . . . . . . 6		2.1 OAM Layering . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1.1 Relationship to CFM . . . . . . . . . . . . . . . . . . 7		2.1.1 Relationship to CFM . . . . . . . . . . . . . . . . . . 7
	2.1.2 Relationship to BFD and Link OAM . . . . . . . . . . . . 8		2.1.2 Relationship to BFD . . . . . . . . . . . . . . . . . . 8
	2.2 TRILL OAM in RBridge Port Model . . . . . . . . . . . . . . 8		2.1.3 Relationship to Link OAM . . . . . . . . . . . . . . . . 8
	2.3 Network, Service and Flow OAM . . . . . . . . . . . . . . . 9		2.2 TRILL OAM in the RBridge Port Model . . . . . . . . . . . . 9
	2.4 Maintenance Domains . . . . . . . . . . . . . . . . . . . . 10		2.3 Network, Service and Flow OAM . . . . . . . . . . . . . . . 10
	2.5 Maintenance Entity and Maintenance Entity Group . . . . . . 11		2.4 Maintenance Domains . . . . . . . . . . . . . . . . . . . . 11
	2.6 MEPs and MIPs . . . . . . . . . . . . . . . . . . . . . . . 11		2.5 Maintenance Entity and Maintenance Entity Group . . . . . . 12
	2.7 Maintenance Point Addressing . . . . . . . . . . . . . . . . 13		2.6 MEPs and MIPs . . . . . . . . . . . . . . . . . . . . . . . 12
	3. OAM Frame Format . . . . . . . . . . . . . . . . . . . . . . . 13		2.7 Maintenance Point Addressing . . . . . . . . . . . . . . . . 14
	3.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 13		3. OAM Frame Format . . . . . . . . . . . . . . . . . . . . . . . 14
	3.2 Determination of Flow Entropy . . . . . . . . . . . . . . . 15		3.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 14
	3.2.1 Address Learning and Flow Entropy . . . . . . . . . . . 15		3.2 Determination of Flow Entropy . . . . . . . . . . . . . . . 16
	3.3 OAM Message Channel . . . . . . . . . . . . . . . . . . . . 15		3.2.1 Address Learning and Flow Entropy . . . . . . . . . . . 16
	3.4 Identification of OAM Messages . . . . . . . . . . . . . . . 16		3.3 OAM Message Channel . . . . . . . . . . . . . . . . . . . . 16
	4. Fault Management . . . . . . . . . . . . . . . . . . . . . . . 16		3.4 Identification of OAM Messages . . . . . . . . . . . . . . . 17
	4.1 Proactive Fault Management Functions . . . . . . . . . . . . 16		4. Fault Management . . . . . . . . . . . . . . . . . . . . . . . 17
	4.1.1 Fault Detection (Continuity Check) . . . . . . . . . . . 16		4.1 Proactive Fault Management Functions . . . . . . . . . . . . 17
	4.1.2 Defect Indication . . . . . . . . . . . . . . . . . . . 17		4.1.1 Fault Detection (Continuity Check) . . . . . . . . . . . 17
	4.1.2.1 Forward Defect Indication . . . . . . . . . . . . . 17		4.1.2 Defect Indication . . . . . . . . . . . . . . . . . . . 18
	4.1.2.2 Reverse Defect Indication (RDI) . . . . . . . . . . 17		4.1.2.1 Forward Defect Indication . . . . . . . . . . . . . 18
	4.2 On-Demand Fault Management Functions . . . . . . . . . . . . 17		4.1.2.2 Reverse Defect Indication (RDI) . . . . . . . . . . 18
	4.2.1 Connectivity Verification . . . . . . . . . . . . . . . 18		4.2 On-Demand Fault Management Functions . . . . . . . . . . . . 19
	4.2.1.1 Unicast . . . . . . . . . . . . . . . . . . . . . . 18		4.2.1 Connectivity Verification . . . . . . . . . . . . . . . 19
	4.2.1.2 Multicast . . . . . . . . . . . . . . . . . . . . . 18		4.2.1.1 Unicast . . . . . . . . . . . . . . . . . . . . . . 19
	4.2.2 Fault Isolation . . . . . . . . . . . . . . . . . . . . 19		4.2.1.2 Multicast . . . . . . . . . . . . . . . . . . . . . 20
	5. Performance Management . . . . . . . . . . . . . . . . . . . . 19		4.2.2 Fault Isolation . . . . . . . . . . . . . . . . . . . . 20
	5.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . . 19		5. Performance Management . . . . . . . . . . . . . . . . . . . . 21
	5.2 Packet Delay . . . . . . . . . . . . . . . . . . . . . . . . 20		5.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . . 21
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 21		5.2 Packet Delay . . . . . . . . . . . . . . . . . . . . . . . . 21
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 22
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 22
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
	9.1 Normative References . . . . . . . . . . . . . . . . . . . 21		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	9.2 Informative References . . . . . . . . . . . . . . . . . . 22		9.1 Normative References . . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22		9.2 Informative References . . . . . . . . . . . . . . . . . . 23
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	This document specifies a reference framework for Operations,		This document specifies a reference framework for Operations,
	Administration and Maintenance (OAM, [RFC6291]) in TRILL (Transparent		Administration and Maintenance (OAM, [RFC6291]) in TRILL (Transparent
	Interconnection of Lots of Links) networks.		Interconnection of Lots of Links) networks.
	TRILL [RFC6325] specifies a protocol for shortest-path frame routing		TRILL [RFC6325] specifies a protocol for shortest-path frame routing
	in multi-hop networks with arbitrary topologies and link		in multi-hop networks with arbitrary topologies and link
	technologies, using the IS-IS routing protocol. TRILL capable devices		technologies, using the IS-IS routing protocol. TRILL capable devices
	are referred to as TRILL Switches or RBridges (Routing Bridges).		are referred to as TRILL Switches or RBridges (Routing Bridges).
	RBridges provide an optimized and transparent Layer 2 delivery		RBridges provide an optimized and transparent Layer 2 delivery
	service for Ethernet unicast and multicast traffic. Some		service for Ethernet unicast and multicast traffic. Some
	characteristics of a TRILL network that are different from Ethernet		characteristics of a TRILL network that are different from Ethernet
	bridging are the following:		bridging are the following:
			- TRILL networks support arbitrary link technology between TRILL
			switches. Hence, a TRILL switch port may not have a 48-bit MAC
			Address [802] but might, for example, have an IP address as an
			identifier [TRILL-IP] or no unique identifier (PPP [RFC6361]).
	- TRILL networks do not enforce congruency of unicast and multicast		- TRILL networks do not enforce congruency of unicast and multicast
	paths between a given pair of RBridges.		paths between a given pair of RBridges.
	- TRILL networks do not impose symmetry of the forward and reverse		- TRILL networks do not impose symmetry of the forward and reverse
	paths between a given pair of RBridges.		paths between a given pair of RBridges.
	- TRILL supports multipathing of unicast as well as multicast		- TRILL supports multipathing of unicast as well as multicast
	traffic.		traffic.
	In this document, we refer to the term OAM as defined in [RFC6291].		In this document, we refer to the term OAM as defined in [RFC6291].
	skipping to change at page 6, line 29		skipping to change at page 6, line 34
	TRILL over any transport layer capable of carrying TRILL frames such		TRILL over any transport layer capable of carrying TRILL frames such
	as Ethernet [RFC6325], PPP [RFC6361], or MPLS. Furthermore, TRILL		as Ethernet [RFC6325], PPP [RFC6361], or MPLS. Furthermore, TRILL
	provides a virtual Ethernet connectivity service that is transparent		provides a virtual Ethernet connectivity service that is transparent
	to higher layer entities (e.g. Layer 3 and above). This strict		to higher layer entities (e.g. Layer 3 and above). This strict
	layering is observed by TRILL OAM.		layering is observed by TRILL OAM.
	Of particular interest is the layering of TRILL OAM with respect to:		Of particular interest is the layering of TRILL OAM with respect to:
	- BFD, which is typically used for fast convergence		- BFD, which is typically used for fast convergence
	- Ethernet CFM [802.1Q], especially since TRILL switches are likely		- Ethernet CFM [802.1Q] on paths from an external device, over a
	to be deployed alongside existing 802.1 bridges in a network.		TRILL campus, to another external device, especially since TRILL
			switches are likely to be deployed where existing 802.1 bridges can
			be such external devices.
	- Link OAM, which is media specific.		- Link OAM, on links interior to a TRILL campus, which is link
			technology specific.
	Consider the example network depicted in Figure 1 below, where a		Consider the example network depicted in Figure 1 below, where a
	TRILL network is interconnected via Ethernet links:		TRILL network is interconnected via Ethernet links:
	LAN LAN		LAN LAN
	+---+ +---+ ====== +---+ ============= +---+		+---+ +---+ ====== +---+ ============= +---+
	+--+ | | | | | +--+ | | | | +--+ +--+ | | | +--+		+--+ | | | | | +--+ | | | | +--+ +--+ | | | +--+
	|B1|---|RB1|---|RB2|---|B2|---|RB3|---|B3|---|B4|---|RB4|---|B5|		|B1|---|RB1|---|RB2|---|B2|---|RB3|---|B3|---|B4|---|RB4|---|B5|
	+--+ | | | | | +--+ | | | | +--+ +--+ | | | +--+		+--+ | | | | | +--+ | | | | +--+ +--+ | | | +--+
	+---+ +---+ ====== +---+ ============= +---+		+---+ +---+ ====== +---+ ============= +---+
	a. Ethernet CFM (Client Layer)		a. Ethernet CFM (Client Layer) on path over the TRILL campus
	>---o------------------------------------------------o---<		>---o------------------------------------------------o---<
	b. TRILL OAM (Network Layer)		b. TRILL OAM (Network Layer)
	>------o-----------o---------------------<		>------o-----------o---------------------<
	c. Ethernet CFM (Transport Layer)		c. Ethernet CFM (Transport Layer) on interior Ethernet LANs
	>---o--o---< >---o--o---o--o---<		>---o--o---< >---o--o---o--o---<
	d. BFD (Media Independent Link Layer)		d. BFD (Media Independent Link Layer)
	#---# #----------# #-----------------#		#---# #----------# #-----------------#
	e. Link OAM (Media Dependent Link Layer)		e. Link OAM (Media Dependent Link Layer)
	*---* *---* *---* *---* *---* *---* *---* *---*		*---* *---* *---* *---* *---* *---* *---* *---*
	Legend: > MEP o MIP # BFD Endpoint * Link OAM Endpoint		Legend: > MEP o MIP # BFD Endpoint * Link OAM Endpoint
	Figure 1: OAM Layering in TRILL		Figure 1: OAM Layering in TRILL
	Where Bn and RBn (n= 1,2,3,4) denote IEEE 802.1Q bridges and TRILL		Where Bn and RBn (n= 1,2,3, ...) denote IEEE 802.1Q bridges and TRILL
	RBridges, respectively.		RBridges, respectively.
	2.1.1 Relationship to CFM		2.1.1 Relationship to CFM
	In the context of a TRILL network, CFM can be used as either a client		In the context of a TRILL network, CFM can be used as either a client
	layer OAM or a transport layer OAM mechanism.		layer OAM or a transport layer OAM mechanism.
	When acting as a client layer OAM (see Figure 1a), CFM provides fault		When acting as a client layer OAM (see Figure 1a), CFM provides fault
	management capabilities for the user VLAN or fine-grain label, on an		management capabilities for the user, on an end-to-end basis over the
	end-to-end basis over the TRILL network. Edge ports of the TRILL		TRILL network. Edge ports of the TRILL network may be visible to CFM
	network may be visible to CFM operations through the presence of a		operations through the optional presence of a CFM Maintenance
	CFM Maintenance Intermediate Point (MIP).		Intermediate Point (MIP) in the TRILL switches edge Ethernet ports.
	When acting as a transport layer OAM (see Figure 1c), CFM provides		When acting as a transport layer OAM (see Figure 1c), CFM provides
	fault management functions for the IEEE 802.1Q bridged networks that		fault management functions for the IEEE 802.1Q bridged LANs that may
	may interconnect RBridges. RBridges directly connected to the		interconnect RBridges. Such bridged LANs can be used as TRILL level
			links between RBridges. RBridges directly connected to the
	intervening 802.1Q bridges may host CFM Down Maintenance End Points		intervening 802.1Q bridges may host CFM Down Maintenance End Points
	(MEPs).		(MEPs).
	2.1.2 Relationship to BFD and Link OAM		2.1.2 Relationship to BFD
	One-hop BFD (see Figure 1d) runs between adjacent RBridges and		One-hop BFD (see Figure 1d) runs between adjacent RBridges and
	provides fast link as well as node failure detection capability. Note		provides fast link as well as node failure detection capability
	that BFD sits a layer above Link OAM, which is media specific. BFD		[TRILL-BFD]. Note that BFD sits a layer above Link OAM, which is
	provides fast convergence characteristics to TRILL networks. It is		media specific. BFD provides fast convergence characteristics to
	worth noting that the requirements for BFD are different from those		TRILL networks. It is worth noting that the requirements for BFD are
	of the TRILL OAM mechanisms that are the prime focus of this		different from those of the TRILL OAM mechanisms that are the prime
	document. Furthermore, BFD does not use the frame format described in		focus of this document. Furthermore, BFD does not use the frame
	section 3.1.		format described in section 3.1.
	Link OAM (see Figure 1e) depends on the nature of the physical medium		TRILL BFD differs from TRILL OAM in two significant ways:
	used in the links interconnecting RBridges. For e.g., for Ethernet
	links, [802.3] Clause 57 OAM may be used.
	2.2 TRILL OAM in RBridge Port Model		1. A TRILL BFD transmitter is bound to a specific TRILL output port
			as explained below.
			2. TRILL BFD messages can be transmitted by the originator out a port
			to a neighbor RBridge when the adjacency is in the Detect or Two-Way
			states as well as when the adjacency is in the Up state [RFC6327].
			In contrast, TRILL OAM messages are initially transmitted by
			appearing to have been received on a virtual TRILL input port (refer
			to Section 2.2 for details). The output ports on which TRILL OAM
			message are sent are determined by the TRILL routing function, which
			will only send on links that are in the Up state and have been
			incorporated into the local view of the campus topology.
			For example, assume there are five parallel equal cost links between
			RB1 and RB2 that have not been aggregated. (Links that are aggregated
			with [802.1AX] appear to TRILL to be a single link accessible through
			a single TRILL port.) However, RB1 is only capable of doing up to 4-
			way ECMP. TRILL OAM messages, as dispatched by the TRILL Routing
			function, will use 4 of the 5 links. But it is desirable to be able
			to monitor the fifth link to be sure it is available for failover.
			TRILL BFD messages sent by RB1 will use the output port to which
			their session is bound. RB1 can easily monitor all 5 links to RB2 by
			using a TRILL BFD session bound to each of the 5 output ports.
			2.1.3 Relationship to Link OAM
			Link OAM (see Figure 1e) depends on the nature of the technology used
			in the links interconnecting RBridges. For e.g., for Ethernet links,
			[802.3] Clause 57 OAM may be used.
			2.2 TRILL OAM in the RBridge Port Model
	TRILL OAM processing can be modeled as a shim situated between the		TRILL OAM processing can be modeled as a shim situated between the
	Extended Internal Sublayer Service (EISS) in [802.1Q] and the RBridge		Extended Internal Sublayer Service (EISS) in [802.1Q] and the RBridge
	Forwarding Engine function, on a virtual port with no physical layer		Forwarding Engine function, on a virtual port with no physical layer
	(Null PHY). TRILL OAM requires services of the RBridge forwarding		(Null PHY). TRILL OAM requires services of the RBridge forwarding
	engine and utilizes information from the IS-IS control plane. Figure		engine and utilizes information from the IS-IS control plane. Figure
	2 below depicts TRILL OAM processing in the context of the RBridge		2 below depicts TRILL OAM processing in the context of the RBridge
	port model defined in [RFC6325]. In this figure, double lines		port model defined in [RFC6325]. In this figure, double lines
	represent flow of both frames and information whereas single lines		represent flow of both frames and information whereas single lines
	represent flow of information only.		represent flow of information only.
	skipping to change at page 9, line 14		skipping to change at page 10, line 14
	+-----------------------------------------------+----		+-----------------------------------------------+----
	| (Flow of OAM Messages) RBridge		| (Flow of OAM Messages) RBridge
	| +----------------------+		| +----------------------+
	| |+-------------------+|| Forwarding Engine,		| |+-------------------+|| Forwarding Engine,
	| || || IS-IS, Etc.		| || || IS-IS, Etc.
	| || || Processing of native		| || || Processing of native
	| V V and TRILL frames		| V V and TRILL frames
	+---------------------------------------------+-----		+---------------------------------------------+-----
	|| || || ...other trunk ports		|| || || ...other trunk ports
	|| +------------+ +------------+ <- EISS		|| +------------+ +------------+
	|| | TRILL OAM | | 802.1Q |		|| | TRILL OAM | | |
	|| | Processing | | Port VLAN |		|| | Processing | | Port VLAN |
	|| +------------+ | Processing |		|| +------------+ | Processing |
	|| | |		|| | |
	|+-------------------------+ | |		|+-------------------------+ | |
	+-------------------------+| +------------+ <-- ISS		+-------------------------+| +------------+ <-- ISS
	|| |802.1/802.3 |		|| |802.1/802.3 |
	+-------------------------------+ || |Low Level |		+-------------------------------+ || |Low Level |
	| MAC Relay | || |Control |		| MAC Relay | || |Control |
	+----||------------------||-----+ || |Frame |		+----||------------------||-----+ || |Frame |
	+----||------+ ... +-----||-----+ || |Processing, |		+----||------+ ... +-----||-----+ || |Processing, |
	| 802.1Q | | 802.1Q | || |Port/Link |		| | | | || |Port/Link |
	| Port VLAN | | Port VLAN | || |Control |		| Port VLAN | | Port VLAN | || |Control |
	| Processing | | Processing | || |Logic |		| Processing | | Processing | || |Logic |
	+------------+ +------------+ || +------------+		+------------+ +------------+ || +------------+
	|802.1/802.3 | |802.1/802.3 | || | 802.3PHY |		|802.1/802.3 | |802.1/802.3 | || | 802.3PHY |
	|Low Level | |Low Level | || +------------+		|Low Level | |Low Level | || +------------+
	|Control | |Control | ||		|Control | |Control | ||
	|Frame | |Frame | ||		|Frame | |Frame | ||
	|Processing, | |Processing, | ||		|Processing, | |Processing, | ||
	|Port/Link | |Port/Link | ||		|Port/Link | |Port/Link | ||
	|Control | |Control | ||		|Control | |Control | ||
	skipping to change at page 10, line 10		skipping to change at page 11, line 10
	hosts the TRILL OAM shim. The rationale for this model is discussed		hosts the TRILL OAM shim. The rationale for this model is discussed
	in section 2.6 "MEPs and MIPs".		in section 2.6 "MEPs and MIPs".
	2.3 Network, Service and Flow OAM		2.3 Network, Service and Flow OAM
	OAM functions in a TRILL network can be conducted at different levels		OAM functions in a TRILL network can be conducted at different levels
	of granularity. This gives rise to 'Network', 'Service' and 'Flow'		of granularity. This gives rise to 'Network', 'Service' and 'Flow'
	OAM, listed in order of increasing granularity.		OAM, listed in order of increasing granularity.
	Network OAM mechanisms provide fault and performance management		Network OAM mechanisms provide fault and performance management
	functions in the context of a representative 'test' VLAN or fine		functions in the context of a representative 'test' VLAN or fine
	grain label. The test VLAN can be thought of as a management or		grained label [TRILL-FGL]. The test VLAN can be thought of as a
	diagnostics VLAN which extends to all RBridges in a TRILL network. In		management or diagnostics VLAN which extends to all RBridges in a
	order to account for multipathing, Network OAM functions also make		TRILL network. In order to account for multipathing, Network OAM
	use of test flows (both unicast and multicast) to provide coverage of		functions also make use of test flows (both unicast and multicast) to
	the various paths in the network.		provide coverage of the various paths in the network.
	Service OAM mechanisms provide fault and performance management		Service OAM mechanisms provide fault and performance management
	functions in the context of the actual VLAN or fine grain label set		functions in the context of the actual VLAN or fine grained label set
	for which end station service is enabled. Test flows are used here,		for which end station service is enabled. Test flows are used here,
	as well, to provide coverage in the case of multipathing.		as well, to provide coverage in the case of multipathing.
	Flow OAM mechanisms provide the most granular fault and performance		Flow OAM mechanisms provide the most granular fault and performance
	management capabilities, where OAM functions are performed in the		management capabilities, where OAM functions are performed in the
	context of end station service VLANs or fine grain labels and user		context of end station service VLANs or fine grained labels and user
	flows. While Flow OAM provides the most granular control, it clearly		flows. While Flow OAM provides the most granular control, it clearly
	poses scalability challenges if attempted on large numbers of flows.		poses scalability challenges if attempted on large numbers of flows.
	2.4 Maintenance Domains		2.4 Maintenance Domains
	The concept of Maintenance Domains, or OAM Domains, is well known in		The concept of Maintenance Domains, or OAM Domains, is well known in
	the industry. IEEE [802.1Q], [RFC6136], [RFC5654], etc... all define		the industry. IEEE [802.1Q], [RFC6136], [RFC5654], etc... all define
	the notion of a Maintenance Domain as a collection of devices (e.g.		the notion of a Maintenance Domain as a collection of devices (e.g.
	network elements) that are grouped for administrative and/or		network elements) that are grouped for administrative and/or
	management purposes. Maintenance domains usually delineate trust		management purposes. Maintenance domains usually delineate trust
	relationships, varying addressing schemes, network infrastructure		relationships, varying addressing schemes, network infrastructure
	capabilities, etc...		capabilities, etc...
	When mapped to TRILL, a Maintenance Domain is defined as a collection		When mapped to TRILL, a Maintenance Domain is defined as a collection
	of RBridges in a network for which faults in connectivity or		of RBridges in a network for which faults in connectivity or
	performance are to be managed by a single operator. All RBridges in a		performance are to be managed by a single operator. All RBridges in a
	given Maintenance Domain are, by definition, managed by a single		given Maintenance Domain are, by definition, managed by a single
	entity (e.g. an enterprise or a data center operator, etc...).		entity (e.g. an enterprise or a data center operator, etc...).
	RFC6325 defines the operation of TRILL in a single IS-IS area, with		[RFC6325] defines the operation of TRILL in a single IS-IS area, with
	the assumption that the network is managed by a single operator. In		the assumption that the network is managed by a single operator. In
	this context, a single (default) Maintenance Domain is sufficient for		this context, a single (default) Maintenance Domain is sufficient for
	TRILL OAM.		TRILL OAM.
	However, when considering scenarios where different TRILL networks		However, when considering scenarios where different TRILL networks
	need to be interconnected, for e.g. as discussed in [TRILLML], then		need to be interconnected, for e.g. as discussed in [TRILLML], then
	the introduction of multiple Maintenance Domains and Maintenance		the introduction of multiple Maintenance Domains and Maintenance
	Domain hierarchies becomes useful to map and contain administrative		Domain hierarchies becomes useful to map and contain administrative
	boundaries. When considering multi-domain scenarios, the following		boundaries. When considering multi-domain scenarios, the following
	rules must be followed: TRILL OAM domains MUST NOT overlap, but MUST		rules must be followed: TRILL OAM domains MUST NOT overlap, but MUST
	either be disjoint or nest to form a hierarchy (i.e. a higher		either be disjoint or nest to form a hierarchy (i.e. a higher
	Maintenance Domain MAY completely engulf a lower Domain). A		Maintenance Domain MAY completely engulf a lower Domain). A
	Maintenance Domain is typically identified by a Domain Name and a		Maintenance Domain is typically identified by a Domain Name and a
	Maintenance Level (a numeric identifier). The larger the Domain, the		Maintenance Level (a numeric identifier). The larger the Domain, the
	higher the Level.		higher the Level number.
	+-------------------+ +---------------+ +-------------------+		+-------------------+ +---------------+ +-------------------+
	| | | TRILL | | |		| | | TRILL | | |
	| Site 1 +----+Interconnect +----+ Site 2 |		| Site 1 +----+Interconnect +----+ Site 2 |
	| TRILL | RB | Network | RB | TRILL |		| TRILL | RB | Network | RB | TRILL |
	| (Level 1) +----+ (Level 2) +----+ (Level 1) |		| (Level 1) +----+ (Level 2) +----+ (Level 1) |
	| | | | | |		| | | | | |
	+-------------------+ +---------------+ +-------------------+		+-------------------+ +---------------+ +-------------------+
	<------------------------End-to-End Domain-------------------->		<------------------------End-to-End Domain-------------------->
	skipping to change at page 12, line 30		skipping to change at page 13, line 30
	+-----------------+ +------------------+ +-----------------+		+-----------------+ +------------------+ +-----------------+
	<E------------I--------------------I-------------E>		<E------------I--------------------I-------------E>
	<E------I----E><E----I-------I----E><E-----I-----E>		<E------I----E><E----I-------I----E><E-----I-----E>
	Legend E: MEP I: MIP		Legend E: MEP I: MIP
	Figure 4: MEPs and MIPs		Figure 4: MEPs and MIPs
	It is worth noting that a single RBridge port may host multiple MEPs		It is worth noting that a single RBridge may host multiple MEPs of
	of different technologies, e.g. TRILL OAM MEP(s) and [802.1Q] MEP(s).		different technologies, e.g. TRILL OAM MEP(s) and [802.1Q] MEP(s).
	This does not mean that the protocol operation is necessarily		This does not mean that the protocol operation is necessarily
	consolidated into a single functional entity on those ports. The		consolidated into a single functional entity on those ports. The
	protocol functions for each MEP remain independent and reside in		protocol functions for each MEP remain independent and reside in
	different shims in the RBridge Port model of figure 2: the TRILL OAM		different shims in the RBridge Port model of Figure 2: the TRILL OAM
	MEP resides in the "TRILL OAM Processing" block whereas a CFM MEP		MEP resides in the "TRILL OAM Processing" block whereas a CFM MEP
	resides in the "802.1Q Port VLAN Processing" block.		resides in the "802.1Q Port VLAN Processing" block.
	The model of section 2.2 implies that a single MEP and/or MIP per MEG		The model of Section 2.2 implies that a single MEP and/or MIP per MEG
	can be instantiated per RBridge. This simplifies implementations and		can be instantiated per RBridge. This simplifies implementations and
	enables TRILL OAM to perform management functions on sections, as		enables TRILL OAM to perform management functions on sections, as
	specified in [TRILL-OAM-REQ], while maintaining the simplicity of a		specified in [TRILL-OAM-REQ], while maintaining the simplicity of a
	single TRILL OAM Maintenance Domain. We do not distinguish between Up		single TRILL OAM Maintenance Domain. We do not distinguish between Up
	MPs and Down MPs (as defined in [802.1Q]) in this framework. Given		MPs and Down MPs (as defined in [802.1Q]) in this framework. Given
	that the MPs always reside on a special virtual port with no PHY		that the MPs always reside on a special virtual port with no PHY
	layer, MP directionality is irrelevant.		layer, MP directionality is irrelevant.
	2.7 Maintenance Point Addressing		2.7 Maintenance Point Addressing
	skipping to change at page 13, line 25		skipping to change at page 14, line 25
	TRILL OAM will support the Shared MP address model, where all MPs on		TRILL OAM will support the Shared MP address model, where all MPs on
	an RBridge share the same Individual MP address. In other words,		an RBridge share the same Individual MP address. In other words,
	TRILL OAM messages can be addressed to a specific RBridge but not to		TRILL OAM messages can be addressed to a specific RBridge but not to
	a specific port on an RBridge.		a specific port on an RBridge.
	One cannot discern, from observing the external behavior of an		One cannot discern, from observing the external behavior of an
	RBridge, whether TRILL OAM messages are actually delivered to a		RBridge, whether TRILL OAM messages are actually delivered to a
	certain MP or another entity within the RBridge. The Shared MP		certain MP or another entity within the RBridge. The Shared MP
	address model takes advantage of this fact by allowing MPs in		address model takes advantage of this fact by allowing MPs in
	different RBridge ports to share the same Individual MP address. The		different RBridge ports to share the same Individual MP address. The
	MPs may still reside on different RBridge ports and for the most		MPs may still be implemented as residing on different RBridge ports
	part, they have distinct identities.		and for the most part, they have distinct identities.
	The Group MP addresses enable the OAM mechanism to reach all the MPs		The Group MP addresses enable the OAM mechanism to reach all the MPs
	in a given MEG. Certain OAM functions, e.g. pruned tree verification,		in a given MEG. Certain OAM functions, e.g. pruned tree verification,
	require addressing a subset of the MPs in a MEG. Group MP addresses		require addressing a subset of the MPs in a MEG. Group MP addresses
	are not defined for such subsets. Rather, the OAM function in		are not defined for such subsets. Rather, the OAM function in
	question must use the Group MP addresses combined with an indication		question must use the Group MP addresses combined with an indication
	of the scope of the MP subset encoded in the OAM Message Channel.		of the scope of the MP subset encoded in the OAM Message Channel.
	This prevents the unwieldy proliferation of Group MP addresses.		This prevents the unwieldy response to Group MP addresses.
	3. OAM Frame Format		3. OAM Frame Format
	3.1 Motivation		3.1 Motivation
	In order for TRILL OAM messages to accurately test the data-path,		In order for TRILL OAM messages to accurately test the data-path,
	these messages must be transparent to transit RBridges. That is, a		these messages must be transparent to transit RBridges. That is, a
	TRILL OAM message must be indistinguishable from a TRILL data frame		TRILL OAM message must be indistinguishable from a TRILL data frame
	through normal transit RBridge processing. Only the target RBridge,		through normal transit RBridge processing. Only the target RBridge,
	which needs to process the message, should be able to identify and		which needs to process the message, should identify and trap the
	trap the packet as a control message through normal processing.		packet as a control message through normal processing. Additionally
	Additionally methods must be provided to prevent OAM packets from		methods must be provided to prevent OAM packets from being
	being transmitted out as native frames.		transmitted out as native frames.
	The TRILL OAM frame format proposed below provides the necessary		The TRILL OAM frame format proposed below provides the necessary
	flexibility to exercise the data path as closely as possible to		flexibility to exercise the data path as closely as possible to
	actual data packets.		actual data packets.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. Link Header . Variable		. Link Header . Variable
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ TRILL Header + 8 bytes		+ TRILL Header + 8 bytes
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. Flow Entropy . Fixed Size		. Flow Entropy . Fixed Size
	. .		. .
	| |		| |
	skipping to change at page 14, line 36		skipping to change at page 15, line 36
	| |		| |
	. Link Trailer . Variable		. Link Trailer . Variable
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: OAM Frame Format		Figure 5: OAM Frame Format
	The TRILL Header is as specified in [RFC6325] and the Link Header and		The TRILL Header is as specified in [RFC6325] and the Link Header and
	Trailer are as specified for the link technology. (Link types		Trailer are as specified for the link technology. (Link types
	standardized so far are [RFC6325] for Ethernet and [RFC6361] for		standardized so far are [RFC6325] for Ethernet and [RFC6361] for
	PPP). These fields need to be as close as practical to the Link		PPP). These fields need to be as similar as practical to the Link
	Header/Trailer and TRILL Header of the normal TRILL data frame		Header/Trailer and TRILL Header of the normal TRILL data frame
	corresponding to the traffic that OAM is testing.		corresponding to the traffic that OAM is testing.
	The OAM EtherType demarcates the boundary between the Flow Entropy		The OAM EtherType demarcates the boundary between the Flow Entropy
	and the OAM Message Channel. The OAM EtherType is expected at a		and the OAM Message Channel. The OAM EtherType is expected at a
	deterministic offset from the TRILL Header, thereby allowing		deterministic offset from the TRILL Header, thereby allowing
	applications to clearly identify the beginning of the OAM Message		applications to clearly identify the beginning of the OAM Message
	Channel. Additionally, it facilitates the use of the same OAM frame		Channel. Additionally, it facilitates the use of the same OAM frame
	structure by different Ethernet technologies.		structure by different Ethernet technologies.
	The Link Trailer is usually a checksum, such as the Ethernet Frame		The Link Trailer is usually a checksum, such as the Ethernet Frame
	Check Sequence, which is examined at a low level very early in the		Check Sequence, which is examined at a low level very early in the
	frame input process and automatically generated as part of the low		frame input process and automatically generated as part of the low
	level frame output process. If the checksum fails, the frame is		level frame output process. If the checksum fails, the frame is
	discarded with no higher level processing.		normally discarded with no higher level processing.
	3.2 Determination of Flow Entropy		3.2 Determination of Flow Entropy
	The Flow Entropy is a fixed 128-byte field that is populated with		The Flow Entropy is a fixed length field that is populated with
	either real packet data or synthetic data that mimics the intended		either real packet data or synthetic data that mimics the intended
	flow.		flow.
	For a Layer 2 flow (i.e. non-IP) the Flow Entropy must specify the		For a Layer 2 flow (i.e. non-IP) the Flow Entropy must specify the
	Ethernet header, including the MAC destination and source addresses		Ethernet header, including the MAC destination and source addresses
	as well as a VLAN tag or fine grain label.		as well as a VLAN tag or fine grain label.
	For a Layer 3 flow, the Flow Entropy must specify the Ethernet		For a Layer 3 flow, the Flow Entropy must specify the Ethernet
	header, the IP header and UDP or TCP header fields.		header, the IP header and UDP or TCP header fields.
	Not all fields in the Flow Entropy field need to be identical to the		Not all fields in the Flow Entropy field need to be identical to the
	data flow that the OAM message is mimicking. The only requirement is		data flow that the OAM message is mimicking. The only requirement is
	for the selected flow entropy to follow the same path as the data		for the selected flow entropy to follow the same path as the data
	flow that it is mimicking. In other words, the selected flow entropy		flow that it is mimicking. In other words, the selected flow entropy
	must result in the same ECMP selection or multicast pruning behavior		must result in the same ECMP selection or multicast pruning behavior
	or other applicable forwarding paradigm.		or other applicable forwarding paradigm.
	When performing diagnostics on user flows, the OAM mechanisms must		When performing diagnostics on user flows, the OAM mechanisms must
	allow the network operator to configure the flow entropy parameters		allow the network operator to configure the flow entropy parameters
	(e.g. Layer 2 or 3) on the RBridge from which the diagnostic		(e.g. Layer 2 and/or 3) on the RBridge from which the diagnostic
	operations are to be triggered.		operations are to be triggered.
	When running OAM functions over Test Flows, the TRILL OAM should		When running OAM functions over Test Flows, the TRILL OAM should
	provide a mechanism for discovering the flow entropy parameters by		provide a mechanism for discovering the flow entropy parameters by
	querying the RBridges dynamically.		querying the RBridges dynamically.
	3.2.1 Address Learning and Flow Entropy		3.2.1 Address Learning and Flow Entropy
	TRILL switches, like traditional 802.1 bridges, are required to learn		Edge TRILL switches, like traditional 802.1 bridges, are required to
	MAC address associations. Learning is accomplished either by snooping		learn MAC address associations. Learning is accomplished either by
	data packets or through other methods. The flow entropy field of		snooping data packets or through other methods. The flow entropy
	TRILL OAM messages mimics real packets and may impact the address		field of TRILL OAM messages mimics real packets and may impact the
	learning process of the TRILL data plane. TRILL OAM is required to		address learning process of the TRILL data plane. TRILL OAM is
	provide methods to prevent any learning of addresses from the flow		required to provide methods to prevent any learning of addresses from
	entropy field of OAM messages that would interfere with normal TRILL		the flow entropy field of OAM messages that would interfere with
	operation. This can be done, for e.g., by suppressing/preventing MAC		normal TRILL operation. This can be done, for e.g., by
	address learning from OAM messages.		suppressing/preventing MAC address learning from OAM messages.
	3.3 OAM Message Channel		3.3 OAM Message Channel
	OAM Message Channel provides methods to communicate OAM specific		The OAM Message Channel provides methods to communicate OAM specific
	details between RBridges. [802.1Q] CFM and [RFC4379] have implemented		details between RBridges. [802.1Q] CFM and [RFC4379] have implemented
	OAM message channels. It is desirable to select an appropriate		OAM message channels. It is desirable to select an appropriate
	technology and re-use it, instead of redesigning yet another OAM		technology and re-use it, instead of redesigning yet another OAM
	channel. TRILL is a transport layer that carries Ethernet frames, as		channel. TRILL is a transport layer that carries Ethernet frames, so
	such there are close links between TRILL and other 802.1		the TRILL OAM model specified earlier is based on the [802.1Q] CFM
	technologies. The TRILL OAM model specified earlier is based on		model. The use of [802.1Q] CFM encoding format for the OAM Message
	the[802.1Q] CFM model. The use of [802.1Q] CFM encoding format for		channel is one possible choice. [TRILL-OAM] presents a proposal on
	the OAM Message channel is one possible choice. [TRILL-OAM] presents		the use of [802.1Q] CFM payload as the OAM message channel.
	a proposal on the use of [802.1Q] CFM messaging as the OAM message
	channel.
	3.4 Identification of OAM Messages		3.4 Identification of OAM Messages
	RBridges must be able to identify OAM messages that are destined to		RBridges must be able to identify OAM messages that are destined to
	them, either individually or as a group, so as to properly process		them, either individually or as a group, so as to properly process
	those messages.		those messages.
	It may be possible to use a combination of one of the unused fields		It may be possible to use a combination of one of the unused fields
	in the TRILL Header and the OAM EtherType to identify TRILL OAM		or bits in the TRILL Header and the OAM EtherType to identify TRILL
	messages.		OAM messages.
	[RFC6325] does not specify any method of identifying OAM messages.		[RFC6325] does not specify any method of identifying OAM messages.
	Hence, for backwards compatibility reasons, TRILL OAM solutions must		Hence, for backwards compatibility reasons, TRILL OAM solutions must
	provide methods to identify OAM messages through the use of well-		provide methods to identify OAM messages through the use of well-
	known patterns in the Flow Entropy field; for e.g., by using a		known patterns in the Flow Entropy field; for e.g., by using a
	reserved MAC address as the inner MAC SA.		reserved MAC address as the inner MAC SA.
	4. Fault Management		4. Fault Management
			Section 4.1 below discusses proactive fault management and Section
			4.2 discusses on-demand fault management.
	4.1 Proactive Fault Management Functions		4.1 Proactive Fault Management Functions
	Proactive fault management functions are configured by the network		Proactive fault management functions are configured by the network
	operator to run periodically without a time bound, or are configured		operator to run periodically without a time bound, or are configured
	to trigger certain actions upon the occurrence of specific events.		to trigger certain actions upon the occurrence of specific events.
	4.1.1 Fault Detection (Continuity Check)		4.1.1 Fault Detection (Continuity Check)
	Proactive fault detection is performed by periodically monitoring the		Proactive fault detection is performed by periodically monitoring the
	reachability between service endpoints, i.e. MEPs in a given MEG,		reachability between service endpoints, i.e. MEPs in a given MEG,
	skipping to change at page 17, line 28		skipping to change at page 18, line 30
	4.1.2 Defect Indication		4.1.2 Defect Indication
	TRILL OAM MUST support event-driven defect indication upon the		TRILL OAM MUST support event-driven defect indication upon the
	detection of a connectivity defect. Defect indications can be		detection of a connectivity defect. Defect indications can be
	categorized into two types:		categorized into two types:
	4.1.2.1 Forward Defect Indication		4.1.2.1 Forward Defect Indication
	This is used to signal a failure that is detected by a lower layer		This is used to signal a failure that is detected by a lower layer
	OAM mechanism. Forward Defect indication is transmitted away from the		OAM mechanism. Forward Defect indication is transmitted away from the
	direction of the failure.		direction of the failure. For e.g., consider a simple network
			comprising of four RBridges connected in tandem: RB1, RB2, RB3 and
			RB4. Both RB1 and RB4 are hosting TRILL OAM MEPs, whereas RB2 and RB3
			have MIPs. If the link between RB2 and RB3 fails, then RB2 can send a
			forward defect indication towards RB1 while RB3 sends a forward
			defect indication towards RB4.
	Forward defect indication may be used for alarm suppression and/or		Forward defect indication may be used for alarm suppression and/or
	for purpose of inter-working with other layer OAM protocols. Alarm		for purpose of inter-working with other layer OAM protocols. Alarm
	suppression is useful when a transport/network level fault translates		suppression is useful when a transport/network level fault translates
	to multiple service or flow level faults. In such a scenario, it is		to multiple service or flow level faults. In such a scenario, it is
	enough to alert a network management station (NMS) of the single		enough to alert a network management station (NMS) of the single
	transport/network level fault in lieu of flooding that NMS with a		transport/network level fault in lieu of flooding that NMS with a
	multitude of Service or Flow granularity alarms.		multitude of Service or Flow granularity alarms.
	4.1.2.2 Reverse Defect Indication (RDI)		4.1.2.2 Reverse Defect Indication (RDI)
	RDI is used to signal that the advertising MEP has detected a loss of		RDI is used to signal that the advertising MEP has detected a loss of
	continuity (LoC) defect. RDI is transmitted in the direction of the		continuity (LoC) defect. RDI is transmitted in the direction of the
	failure.		failure. For e.g., consider the same tandem network of the previous
			section. If RB1 detects that is has lost connectivity to RB4 because
			it is no longer receiving Continuity Check messages from the MEP on
			RB4, then RB1 can transmit an RDI towards RB4 to inform the latter of
			the failure. If the failure is unidirectional (i.e. it is affecting
			the direction from RB4 to RB1), then the RDI enables RB4 to become
			aware of the unidirectional connectivity anomaly.
	RDI allows single-sided management, where the network operator can		RDI allows single-sided management, where the network operator can
	examine the state of a single MEP and deduce the overall health of a		examine the state of a single MEP and deduce the overall health of a
	monitored entity (network, flow or service).		monitored entity (network, flow or service).
	4.2 On-Demand Fault Management Functions		4.2 On-Demand Fault Management Functions
	On-demand fault management functions are initiated manually by the		On-demand fault management functions are initiated manually by the
	network operator and continue for a time bound period. These		network operator and continue for a time bound period. These
	functions enable the operator to run diagnostics to investigate a		functions enable the operator to run diagnostics to investigate a
	skipping to change at page 18, line 29		skipping to change at page 19, line 41
	4.2.1.1 Unicast		4.2.1.1 Unicast
	Unicast connectivity verification operation must be initiated from a		Unicast connectivity verification operation must be initiated from a
	MEP and may target either a MIP or another MEP. For unicast,		MEP and may target either a MIP or another MEP. For unicast,
	connectivity verification can be performed at either Network or Flow		connectivity verification can be performed at either Network or Flow
	granularity.		granularity.
	Connectivity verification at the Network granularity tests		Connectivity verification at the Network granularity tests
	connectivity between a MEP on a source RBridge and a MIP or MEP on a		connectivity between a MEP on a source RBridge and a MIP or MEP on a
	target RBridge over a representative test VLAN and for a test flow.		target RBridge over a representative test VLAN and for a test flow.
	The user must supply the source and target RBridges for the		The operator must supply the source and target RBridges for the
	operation, and the test VLAN/flow information uses pre-set values or		operation, and the test VLAN/flow information uses pre-set values or
	defaults.		defaults.
	Connectivity verification at the Flow granularity tests connectivity		Connectivity verification at the Flow granularity tests connectivity
	between a MEP on a source RBridge and a MIP or MEP on a target		between a MEP on a source RBridge and a MIP or MEP on a target
	RBridge over a user specified VLAN or fine grain label with user		RBridge over an operator specified VLAN or fine grain label with
	specified flow parameters.		operator specified flow parameters.
	The above functions must be supported on sections, as defined in		The above functions must be supported on sections, as defined in
	[TRILL-OAM-REQ]. When connectivity verification is triggered over a		[TRILL-OAM-REQ]. When connectivity verification is triggered over a
	section, and the initiating MEP does not coincide with the edge		section, and the initiating MEP does not coincide with the edge
	(ingress) RBridge, the MEP must use the edge RBridge nickname instead		(ingress) RBridge, the MEP must use the edge RBridge nickname instead
	of the local RBridge nickname on the associated connectivity		of the local RBridge nickname on the associated connectivity
	verification messages. The user must supply the edge RBridge nickname		verification messages. The operator must supply the edge RBridge
	as part of the operation parameters.		nickname as part of the operation parameters.
	4.2.1.2 Multicast		4.2.1.2 Multicast
	For multicast, the connectivity verification function tests all		For multicast, the connectivity verification function tests all
	branches and leaf nodes of a multicast distribution tree for		branches and leaf nodes of a multidestination distribution tree for
	reachability. This function should include mechanisms to prevent		reachability. This function should include mechanisms to prevent
	reply storms from overwhelming the initiating RBridge. This may be		reply storms from overwhelming the initiating RBridge. This may be
	done, for e.g., by staggering the replies. To further prevent reply		done, for e.g., by staggering the replies. To further prevent reply
	storms, connectivity verification operation is initiated from a MEP		storms, connectivity verification operation is initiated from a MEP
	and must target MEPs only. MIPs are transparent to multicast		and must target MEPs only. MIPs are transparent to multicast
	connectivity verification.		connectivity verification.
	Per [TRILL-OAM-REQ], multicast connectivity verification must provide		Per [TRILL-OAM-REQ], multicast connectivity verification must provide
	the following granularity of operation:		the following granularity of operation:
	A. Un-pruned Tree		A. Un-pruned Tree
	- Connectivity verification for un-pruned multicast distribution		- Connectivity verification for un-pruned multidestination
	tree. The user in this case supplies the tree identifier (egress		distribution tree. The operator in this case supplies the tree
	RBridge nickname).		identifier (root RBridge nickname) and campus wide diagnostic VLAN.
	B. Pruned Tree		B. Pruned Tree
	- Connectivity verification for a VLAN or fine-grain label in a given		- Connectivity verification for a VLAN or fine-grain label in a given
	multicast distribution tree. The user in this case supplies the tree		multidestination distribution tree. The operator in this case
	identifier and VLAN or fine grain label.		supplies the tree identifier and VLAN or fine grain label.
	- Connectivity verification for an IP multicast group in a given		- Connectivity verification for an IP multicast group in a given
	multicast distribution tree. The user in this case supplies: the tree		multidestination distribution tree. The operator in this case
	identifier, VLAN or fine grain label and IP (S,G) or (*,G).		supplies: the tree identifier, VLAN or fine grain label and IP (S,G)
			or (*,G).
	4.2.2 Fault Isolation		4.2.2 Fault Isolation
	TRILL OAM must support an on-demand connectivity fault localization		TRILL OAM must support an on-demand connectivity fault localization
	function. This is the capability to trace the path of a Flow on a		function. This is the capability to trace the path of a Flow on a
	hop-by-hop (i.e. RBridge by RBridge) basis to isolate failures. This		hop-by-hop (i.e. RBridge by RBridge) basis to isolate failures. This
	involves the capability to narrow down the locality of a fault to a		involves the capability to narrow down the locality of a fault to a
	particular port, link or node. The characteristic of forward/reverse		particular port, link or node. The characteristic of forward/reverse
	path asymmetry, in TRILL, renders fault isolation into a direction-		path asymmetry, in TRILL, renders fault isolation into a direction-
	sensitive operation. That is, given two RBridges A and B,		sensitive operation. That is, given two RBridges A and B,
	skipping to change at page 20, line 30		skipping to change at page 21, line 44
	MEP must use the edge RBridge nickname instead of the local RBridge		MEP must use the edge RBridge nickname instead of the local RBridge
	nickname on the associated loss measurement messages. The user must		nickname on the associated loss measurement messages. The user must
	supply the edge RBridge nickname as part of the operation parameters.		supply the edge RBridge nickname as part of the operation parameters.
	5.2 Packet Delay		5.2 Packet Delay
	Packet delay is measured by inserting time-stamps in TRILL OAM		Packet delay is measured by inserting time-stamps in TRILL OAM
	packets. In order to ensure high accuracy of measurement, TRILL OAM		packets. In order to ensure high accuracy of measurement, TRILL OAM
	must specify the time-stamp location at fixed offsets within the OAM		must specify the time-stamp location at fixed offsets within the OAM
	packet in order to facilitate hardware-based time-stamping. Hardware		packet in order to facilitate hardware-based time-stamping. Hardware
	implementation must implement the time-stamping function as close to		implementations must implement the time-stamping function as close to
	the wire as practical in order to maintain high accuracy.		the wire as practical in order to maintain high accuracy.
	6. Security Considerations		6. Security Considerations
	TRILL OAM must provide mechanisms for:		TRILL OAM must provide mechanisms for:
	- Preventing denial of service attacks caused by exploitation of the		- Preventing denial of service attacks caused by exploitation of
	OAM message channel.		the OAM message channel.
	- Optionally authenticate communicating endpoints (MEPs and MIPs)		- Optionally authenticate communicating endpoints (MEPs and MIPs)
	- Preventing TRILL OAM packets from leaking outside of the TRILL		- Preventing TRILL OAM packets from leaking outside of the TRILL
	network or outside their corresponding Maintenance Domain. This can		network or outside their corresponding Maintenance Domain. This can
	be done by having MEPs implement a filtering function based on the		be done by having MEPs implement a filtering function based on the
	Maintenance Level associated with received OAM packets.		Maintenance Level associated with received OAM packets.
	For general TRILL Security Considerations, see [RFC6325].		For general TRILL Security Considerations, see [RFC6325].
	7. IANA Considerations		7. IANA Considerations
	This document requires no IANA Actions. RFC Editor: Please delete		This document requires no IANA Actions. RFC Editor: Please delete
	this section before publication.		this section before publication.
	skipping to change at page 21, line 38		skipping to change at page 22, line 38
	We invite feedback and contributors.		We invite feedback and contributors.
	9. References		9. References
	9.1 Normative References		9.1 Normative References
	[TRILL-OAM-REQ] Senevirathne, "Requirements for Operations,		[TRILL-OAM-REQ] Senevirathne, "Requirements for Operations,
	Administration and Maintenance (OAM) in TRILL", draft-		Administration and Maintenance (OAM) in TRILL", draft-
	tissa-trill-oam-req, work in progress.		tissa-trill-oam-req, work in progress.
	[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate		[RFC6325] Perlman, et al., "Routing Bridges (RBridges): Base
			Protocol Specification", RFC 6325, July 2011.
			[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.
	[RFC6136] Sajassi, A., Ed., and D. Mohan, Ed., "Layer 2 Virtual		[RFC6136] Sajassi, A., Ed., and D. Mohan, Ed., "Layer 2 Virtual
	Private Network (L2VPN) Operations, Administration, and		Private Network (L2VPN) Operations, Administration, and
	Maintenance (OAM) Requirements and Framework", RFC 6136,		Maintenance (OAM) Requirements and Framework", RFC 6136,
	March 2011.		March 2011.
	[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for		[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
	Network Interconnect Devices", RFC 2544, March 1999.		Network Interconnect Devices", RFC 2544, March 1999.
	[RFC6291] Andersson et al., BCP 161 "Guidelines for the Use of the		[RFC6291] Andersson et al., BCP 161 "Guidelines for the Use of the
	"OAM" Acronym in the IETF", June 2011.		"OAM" Acronym in the IETF", June 2011.
			[RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and
			V. Manral, "Routing Bridges (RBridges): Adjacency", RFC
			6327, July 2011.
	[TRILL-FGL] D. Eastlake et al., "TRILL Fine-Grained Labeling", draft-		[TRILL-FGL] D. Eastlake et al., "TRILL Fine-Grained Labeling", draft-
	ietf-trill-fine-labeling, work in progress.		ietf-trill-fine-labeling, work in progress.
	[802.1Q] "IEEE Standard for Local and metropolitan area networks -		[802.1Q] "IEEE Standard for Local and metropolitan area networks -
	Media Access Control (MAC) Bridges and Virtual Bridge		Media Access Control (MAC) Bridges and Virtual Bridge
	Local Area Networks", 31 August 2011.		Local Area Networks", IEEE Std 802.1Q-2011, 31 August
			2011.
	[Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and
	mechanisms for Ethernet based networks", February 2008.
	[RFC6371] Busi & Allan, "Operations, Administration, and Maintenance		[RFC6371] Busi & Allan, "Operations, Administration, and Maintenance
	Framework for MPLS-Based Transport Networks", RFC 6371,		Framework for MPLS-Based Transport Networks", RFC 6371,
	September 2011.		September 2011.
			[802] "IEEE Standard for Local and Metropolitan Area Networks -
			Overview and Architecture", IEEE Std 802-2001, 8 Match
			2002.
	9.2 Informative References		9.2 Informative References
	[RFC6325] Perlman, et al., "Routing Bridges (RBridges): Base		[Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and
	Protocol Specification", RFC 6325, July 2011.		mechanisms for Ethernet based networks", February 2008.
	[ISO/IEC 7498-4] "Information processing systems -- Open Systems		[ISO/IEC 7498-4] "Information processing systems -- Open Systems
	Interconnection -- Basic Reference Model -- Part 4:		Interconnection -- Basic Reference Model -- Part 4:
	Management framework", ISO/IEC, 1989.		Management framework", ISO/IEC, 1989.
	[TRILL-BFD] V. Manral, et al., "TRILL (Transparent Interconnetion of		[TRILL-BFD] V. Manral, et al., "TRILL (Transparent Interconnetion of
	Lots of Links): Bidirectional Forwarding Detection (BFD)		Lots of Links): Bidirectional Forwarding Detection (BFD)
	Support", draft-ietf-trill-rbridge-bfd-06.txt, work in		Support", draft-ietf-trill-rbridge-bfd, work in progress,
	progress, June 2012.		June 2012.
			[TRILL-OAM] T. Senevirathne, et al., "Use of 802.1ag for TRILL OAM
			Messages", draft-tissa-trill-8021ag, work in progress,
			June 2012.
	Authors' Addresses		Authors' Addresses
	Samer Salam		Samer Salam
	Cisco		Cisco
	595 Burrard Street, Suite 2123		595 Burrard Street, Suite 2123
	Vancouver, BC V7X 1J1, Canada		Vancouver, BC V7X 1J1, Canada
	Email: ssalam@cisco.com		Email: ssalam@cisco.com
	Tissa Senevirathne		Tissa Senevirathne
End of changes. 58 change blocks.
	137 lines changed or deleted		202 lines changed or added
This html diff was produced by rfcdiff 1.39p1. The latest version is available from http://tools.ietf.org/tools/rfcdiff/