< draft-ooamdt-rtgwg-ooam-requirement-00.txt		draft-ooamdt-rtgwg-ooam-requirement-01c.txt >
	rtgwg N. Kumar		rtgwg N. Kumar
	Internet-Draft C. Pignataro		Internet-Draft C. Pignataro
	Intended status: Informational D. Kumar		Intended status: Informational D. Kumar
	Expires: September 22, 2016 Cisco Systems, Inc.		Expires: January 7, 2017 Cisco Systems, Inc.
	G. Mirsky		G. Mirsky
	Ericsson		Ericsson
	M. Chen		M. Chen
	Huawei Technologies		Huawei Technologies
	E. Nordmark		E. Nordmark
	Arista Networks		Arista Networks
	S. Pallagatti		S. Pallagatti
	Juniper Networks		Juniper Networks
	D. Mozes		D. Mozes
	Mellanox Technologies Ltd		Mellanox Technologies Ltd
	March 21, 2016		July 6, 2016
	Overlay OAM Requirements		Overlay OAM Requirements
	draft-ooamdt-rtgwg-ooam-requirement-00		draft-ooamdt-rtgwg-ooam-requirement-01
	Abstract		Abstract
	This document describes a list of functional requirements for		This document describes a list of functional requirements for
	Operations Administration and Maintenance (OAM) in various Overlay		Operations Administration and Maintenance (OAM) in various Overlay
	and Service networks like Service Function Chaining (SFC), Bit Index		and Service networks like Service Function Chaining (SFC), Bit Index
	Explicit Replication (BIER), Network Virtualization over Layer 3		Explicit Replication (BIER), Network Virtualization over Layer 3
	(NVO3).		(NVO3).
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 22, 2016.		This Internet-Draft will expire on January 7, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3		2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Detailed Requirement List . . . . . . . . . . . . . . . . . . 4		4. Detailed Requirement List . . . . . . . . . . . . . . . . . . 4
	4.1. Fault Management . . . . . . . . . . . . . . . . . . . . 5		4.1. Fault Management . . . . . . . . . . . . . . . . . . . . 5
	4.1.1. Pro-active Fault Management . . . . . . . . . . . . . 5		4.1.1. Pro-active Fault Management . . . . . . . . . . . . . 5
	4.1.2. On-demand Fault Management . . . . . . . . . . . . . 5		4.1.2. On-demand Fault Management . . . . . . . . . . . . . 5
	4.2. Performance Management . . . . . . . . . . . . . . . . . 5		4.2. Performance Management . . . . . . . . . . . . . . . . . 6
	4.3. Alarm Indication Suppression . . . . . . . . . . . . . . 6		4.3. Alarm Indication Suppression . . . . . . . . . . . . . . 7
	4.4. Overlay Network Resiliency . . . . . . . . . . . . . . . 6		4.4. Overlay Network Resiliency . . . . . . . . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7		7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	We have witnessed and participated in design of new paradigms in the		We have witnessed and participated in design of new paradigms in the
	networking that are aimed to address network virtualization, service		networking that are aimed to address network virtualization, service
	function chaining, and multicast services. New paradigms require new		function chaining, and multicast services. New paradigms require new
	architectural concepts, principles and components. [RFC7365] defines		architectural concepts, principles and components. [RFC7365] defines
	a framework for Data Center Network Virtualization over Layer 3		a framework for Data Center Network Virtualization over Layer 3
	(NVO3). [RFC7665] describes the architecture for creating and		(NVO3). [RFC7665] describes the architecture for creating and
	maintaining Service Function Chains (SFCs) in a network.		maintaining Service Function Chains (SFCs) in a network.
	skipping to change at page 3, line 48 ¶		skipping to change at page 3, line 48 ¶
	2. Requirements notation		2. Requirements notation
	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].
	3. Terminology		3. Terminology
	ECMP: Equal Cost Multipath		ECMP: Equal Cost Multipath
	UCMP: Unequal Cost Multipath
	SFC: Service Function Chaining		SFC: Service Function Chaining
	BIER: Bit Index Explicit Replication
			BIER: Bit Index Explicit Replication
	NVO3: Network Virtualization over L3		NVO3: Network Virtualization over L3
	OAM: Operations, Administration and Maintenance		OAM: Operations, Administration and Maintenance
	MPLS: Multiprotocol Label Switching		MPLS: Multiprotocol Label Switching
	VxLAN: Virtual Extensible Local Area Network		VxLAN: Virtual Extensible Local Area Network
	NVGRE: Network Virtualization Using Generic Routing Encapsulation		NVGRE: Network Virtualization Using Generic Routing Encapsulation
			Centralized Controller: An external standalone or virtual entity with
			topology awareness and with an ability to interact with network
			devices for OAM functionality.
			Overlay nodes: Network nodes participating in the Overlay network.
			Underlay Network or Underlay Layer: The network that provides
			connectivity between the Overlay nodes. MPLS network providing LSP
			connectivity between BIER nodes is an example for underlay layer.
			Overlay Network or Overlay Layer: A network layer that is built on
			top another network layer. VxLAN-GPE over IP network is an example
			for Overlay layer.
	4. Detailed Requirement List		4. Detailed Requirement List
	This section list the OAM requirement for different Overlay networks.		This section lists the OAM requirement for different Overlay
	The below listed requirement MUST be supported with any underlay		networks. The below listed requirement MUST be supported with any
	transport network:		underlay transport network:
	REQ#1: The listed requirements MUST be supported with any type of		REQ#1: The listed requirements MUST be supported with any type of
	transport layer over which the overlay network can be		transport layer over which the overlay network can be
	realized		realized
	REQ#2: It MUST be possible to initialize Overlay OAM session from		REQ#2: It MUST be possible to initialize Overlay OAM between any
	any node in the overlay network.		node towards any node(s) in the overlay network.
	REQ#3: It SHOULD be possible to initialize an Overlay OAM session		REQ#3: It SHOULD be possible to initialize an Overlay OAM from a
	from a centralized controller.		centralized controller.
	REQ#4: Overlay OAM MUST support proactive and on-demand OAM		REQ#4: Overlay OAM MUST support proactive and on-demand OAM
	monitoring and measurement methods.		monitoring and measurement methods.
	REQ#5: Overlay OAM MUST support unidirectional OAM methods, both		REQ#5: Overlay OAM MUST support unidirectional OAM methods for
	continuity check and performance measurement.		continuity check, connectivity verification and performance
			measurement.
	REQ#6: Overlay OAM packets SHOULD be fate sharing with data traffic,		REQ#6: Overlay OAM packets SHOULD be fate sharing with data traffic,
	i.e. in-band with the monitored traffic, i.e. follow exactly		i.e. in-band with the monitored traffic, i.e. follow exactly
	the same path as data plane traffic, in forward direction,		the same overlay and transport path as data plane traffic,
	i.e. from ingress toward egress end point(s) of the OAM test		in forward direction, i.e. from ingress toward egress end
	session.		point(s) of the OAM test.
	REQ#7: Overlay OAM MUST support bi-directional OAM methods. Such		REQ#7: Overlay OAM MUST support bi-directional OAM methods. Such
	OAM methods MAY combine in-band monitoring or measurement in		OAM methods MAY combine in-band monitoring or measurement in
	forward direction and out-of-band notification in the		forward direction and out-of-band notification in the
	reverse direction, i.e. from egress to ingress end point of		reverse direction, i.e. from egress to ingress end point of
	the OAM test session.		the OAM test.
			REQ#8: Overlay OAM MUST support Path Maximum Transmission Unit (MTU)
			Discovery from the overlay layer over any transport layer.
	4.1. Fault Management		4.1. Fault Management
	4.1.1. Pro-active Fault Management		4.1.1. Pro-active Fault Management
	Availability, not as performance metric, is understood as ability to		Availability, not as performance metric, is understood as ability to
	reach the node, i.e. the fact that path between ingress and egress		reach the node, i.e. the fact that path between ingress and egress
	does exist. Such OAM mechanism also referred as Continuity Check.		does exist. Such OAM mechanism also referred as Continuity Check.
	REQ#8: Overlay OAM MUST support pro-active monitoring of any virtual		REQ#9: Overlay OAM MUST support pro-active monitoring of any virtual
	node availability in the given overlay network.		node availability in the given overlay network.
	REQ#9: Overlay OAM MUST support Reverse Defect Indication (RDI)		REQ#10: Overlay OAM MUST support Remote Defect Indication (RDI)
	notification by egress to the ingress, i.e. source of		notification by egress to the ingress, i.e. source of
	continuity checking.		continuity checking.
	REQ#10: Overlay OAM MUST support connectivity verification.		REQ#11: Overlay OAM MUST support connectivity verification.
	Definition of mis-connectivity defect entry and exit		Definition of mis-connectivity defect entry and exit
	criteria are outside the scope of this document.		criteria are outside the scope of this document.
	4.1.2. On-demand Fault Management		4.1.2. On-demand Fault Management
	REQ#11: Overlay OAM MUST support fault localization of Loss of		REQ#12: Overlay OAM MUST support fault localization of Loss of
	Continuity check.		Continuity check at Overlay layer.
	REQ#12: Overlay OAM MUST support tracing path in overlay network		REQ#13: Overlay OAM MAY support fault localization of Loss of
			Continuity check at transport layer.
			REQ#14: Overlay OAM MUST support tracing path in overlay network
	through the virtual nodes.		through the virtual nodes.
	REQ#13: Overlay OAM MAY support verification of the mapping between		REQ#15: Overlay OAM MAY support tracing path in underlay network
			connecting overlay border nodes.
			REQ#16: Overlay OAM MAY support verification of the mapping between
	its data plane state and client layer services.		its data plane state and client layer services.
	REQ#14: Overlay OAM MUST have the ability to discover and exercise		REQ#17: Overlay OAM MUST have the ability to discover and exercise
	equal cost multipath (ECMP) paths in its transport network.		equal cost multipath (ECMP) paths in its transport network.
	REQ#15: Overlay OAM MUST be able to trigger on-demand FM with		REQ#18: Overlay OAM MUST be able to trigger on-demand FM with
	responses being directed towards initiator of such proxy		responses being directed towards initiator of such proxy
	request.		request.
	4.2. Performance Management		4.2. Performance Management
	REQ#16: Overlay OAM MUST support active one-way packet delay		This section lists both active and passive mode of performance
			measurement. Section 3.4 and Section 3.5 of [RFC7799] defines the
			definition for Active and Passive mode of Performance Measurement.
			REQ#19: Overlay OAM MUST support active one-way packet delay
	measurement.		measurement.
	REQ#17: Overlay OAM MUST support passive one-way packet delay		REQ#20: Overlay OAM MUST support passive one-way packet delay
	measurement.		measurement.
	REQ#18: Overlay OAM MUST support active two-way packet delay		REQ#21: Overlay OAM MUST support active two-way packet delay
	measurement.		measurement.
	REQ#19: Overlay OAM MUST support packet delay variation measurement.		REQ#22: Overlay OAM MUST support packet delay variation measurement.
	REQ#20: Overlay OAM MUST support active end to end packet loss		REQ#23: Overlay OAM MUST support active end to end packet loss
	measurement.		measurement.
	REQ#21: Overlay OAM MUST support passive end to end packet loss		REQ#24: Overlay OAM MUST support passive end to end packet loss
	measurement.		measurement.
	REQ#22: Overlay OAM SHOULD support active per-segment packet delay		REQ#25: Overlay OAM SHOULD support active per-segment packet delay
	measurement.		measurement.
	REQ#23: Overlay OAM SHOULD support passive per-segment packet delay		REQ#26: Overlay OAM SHOULD support passive per-segment packet delay
	measurement.		measurement.
	REQ#24: Overlay OAM SHOULD support active per-segment packet loss		REQ#27: Overlay OAM SHOULD support active per-segment packet loss
	measurement.		measurement.
	REQ#25: Overlay OAM SHOULD support passive per-segment packet loss		REQ#28: Overlay OAM SHOULD support passive per-segment packet loss
	measurement.		measurement.
	REQ#26: Overlay OAM MUST support delivered packet throughput		REQ#29: Overlay OAM MUST support delivered packet throughput
	measurement.		measurement.
	4.3. Alarm Indication Suppression		4.3. Alarm Indication Suppression
	REQ#27: Overlay OAM MUST support defect notification mechanism, like		REQ#30: Overlay OAM MUST support defect notification mechanism, like
	Alarm Indication Signal.		Alarm Indication Signal.
	REQ#28: Any virtual node in the given overlay network MAY originate a		REQ#31: Any virtual node in the given overlay network MAY originate a
	defect notification addressed to any node in that network.		defect notification addressed to any node in that network.
	4.4. Overlay Network Resiliency		4.4. Overlay Network Resiliency
	REQ#29: Overlay OAM MUST support methods to enable survivability of		REQ#32: Overlay OAM MUST support methods to enable survivability of
	an overlay network. These recovery methods MAY use		an overlay network. These recovery methods MAY use
	protection switching and restoration.		protection switching and restoration.
	5. IANA Considerations		5. IANA Considerations
	This document does not propose any IANA consideration.		This document does not propose any IANA consideration.
	6. Security Considerations		6. Security Considerations
	This document list the OAM requirement for various Overlay network		This document list the OAM requirement for various Overlay
	and does not raise any security considerations.		encapsulations and may have security implications. For example, if
			proactive FM is required, the security implication is that a passive
			eavesdropper can know when the session is down. Or, proactive FM may
			be used either to launch DoS or to highjack session and impact state,
			e.g. cause protection switchover. These security implications are
			natural results of the requirements, and do not depend on the
			particular implementation. Whether existing security mechanisms of
			existing protocols proposed to be re-used in OAM for overlay networks
			are adequate or require enhancements is for further study. New OAM
			protocols for overlay networks must consider their security mechanism
			to on per-solution basis.
	7. Acknowledgement		7. Acknowledgement
	TBD		The Authors would like to thank Ron Bonico, Tal Mizrahi, Alia Atlas
			and Saumya Dikshit for their review and comments.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-bier-architecture]		[I-D.ietf-bier-architecture]
	Wijnands, I., Rosen, E., Dolganow, A., P, T., and S.		Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
	Aldrin, "Multicast using Bit Index Explicit Replication",		S. Aldrin, "Multicast using Bit Index Explicit
	draft-ietf-bier-architecture-03 (work in progress),		Replication", draft-ietf-bier-architecture-03 (work in
	January 2016.		progress), January 2016.
	[I-D.ietf-bier-mpls-encapsulation]		[I-D.ietf-bier-mpls-encapsulation]
	Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and		Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and
	S. Aldrin, "Encapsulation for Bit Index Explicit		S. Aldrin, "Encapsulation for Bit Index Explicit
	Replication in MPLS Networks", draft-ietf-bier-mpls-		Replication in MPLS Networks", draft-ietf-bier-mpls-
	encapsulation-03 (work in progress), February 2016.		encapsulation-04 (work in progress), April 2016.
	[I-D.ietf-nvo3-vxlan-gpe]		[I-D.ietf-nvo3-vxlan-gpe]
	Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F.,		Kreeger, L. and U. Elzur, "Generic Protocol Extension for
	Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg,		VXLAN", draft-ietf-nvo3-vxlan-gpe-02 (work in progress),
	P., and D. Melman, "Generic Protocol Extension for VXLAN",		April 2016.
	draft-ietf-nvo3-vxlan-gpe-01 (work in progress), November
	2015.
	[I-D.ietf-sfc-nsh]		[I-D.ietf-sfc-nsh]
	Quinn, P. and U. Elzur, "Network Service Header", draft-		Quinn, P. and U. Elzur, "Network Service Header", draft-
	ietf-sfc-nsh-02 (work in progress), January 2016.		ietf-sfc-nsh-05 (work in progress), May 2016.
	[I-D.ietf-sfc-oam-framework]		[I-D.ietf-sfc-oam-framework]
	Aldrin, S., Krishnan, R., Akiya, N., Pignataro, C., and A.		Aldrin, S., Krishnan, R., Akiya, N., Pignataro, C., and A.
	Ghanwani, "Service Function Chaining Operation,		Ghanwani, "Service Function Chaining Operation,
	Administration and Maintenance Framework", draft-ietf-sfc-		Administration and Maintenance Framework", draft-ietf-sfc-
	oam-framework-01 (work in progress), February 2016.		oam-framework-01 (work in progress), February 2016.
	[I-D.kumarzheng-bier-ping]		[I-D.kumarzheng-bier-ping]
	Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M.,		Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M.,
	and G. Mirsky, "BIER Ping and Trace", draft-kumarzheng-		and G. Mirsky, "BIER Ping and Trace", draft-kumarzheng-
	bier-ping-02 (work in progress), December 2015.		bier-ping-03 (work in progress), July 2016.
	[I-D.nordmark-nvo3-transcending-traceroute]		[I-D.nordmark-nvo3-transcending-traceroute]
	Nordmark, E., Appanna, C., and A. Lo, "Layer-Transcending		Nordmark, E., Appanna, C., and A. Lo, "Layer-Transcending
	Traceroute for Overlay Networks like VXLAN", draft-		Traceroute for Overlay Networks like VXLAN", draft-
	nordmark-nvo3-transcending-traceroute-01 (work in		nordmark-nvo3-transcending-traceroute-02 (work in
	progress), October 2015.		progress), March 2016.
	[I-D.xu-bier-encapsulation]		[I-D.xu-bier-encapsulation]
	Xu, X., Somasundaram, S., Jacquenet, C., and R. Raszuk,		Xu, X., somasundaram.s@alcatel-lucent.com, s., Jacquenet,
	"BIER Encapsulation", draft-xu-bier-encapsulation-03 (work		C., and R. Raszuk, "A Transport-Independent Bit Index
	in progress), October 2015.		Explicit Replication (BIER) Encapsulation Header", draft-
			xu-bier-encapsulation-05 (work in progress), June 2016.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,		[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
	L., Sridhar, T., Bursell, M., and C. Wright, "Virtual		L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
	eXtensible Local Area Network (VXLAN): A Framework for		eXtensible Local Area Network (VXLAN): A Framework for
	Overlaying Virtualized Layer 2 Networks over Layer 3		Overlaying Virtualized Layer 2 Networks over Layer 3
	skipping to change at page 8, line 37 ¶		skipping to change at page 9, line 27 ¶
	[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network		[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
	Virtualization Using Generic Routing Encapsulation",		Virtualization Using Generic Routing Encapsulation",
	RFC 7637, DOI 10.17487/RFC7637, September 2015,		RFC 7637, DOI 10.17487/RFC7637, September 2015,
	<http://www.rfc-editor.org/info/rfc7637>.		<http://www.rfc-editor.org/info/rfc7637>.
	[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function		[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
	Chaining (SFC) Architecture", RFC 7665,		Chaining (SFC) Architecture", RFC 7665,
	DOI 10.17487/RFC7665, October 2015,		DOI 10.17487/RFC7665, October 2015,
	<http://www.rfc-editor.org/info/rfc7665>.		<http://www.rfc-editor.org/info/rfc7665>.
			[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
			Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
			May 2016, <http://www.rfc-editor.org/info/rfc7799>.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-bier-oam-requirements]		[I-D.ietf-bier-oam-requirements]
	Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N.,		Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N.,
	Aldrin, S., Zheng, L., Chen, M., Akiya, N., and J.		Aldrin, S., Zheng, L., Chen, M., Akiya, N., and S.
	Networks, "Operations, Administration and Maintenance		Pallagatti, "Operations, Administration and Maintenance
	(OAM) Requirements for Bit Index Explicit Replication		(OAM) Requirements for Bit Index Explicit Replication
	(BIER) Layer", draft-ietf-bier-oam-requirements-00 (work		(BIER) Layer", draft-ietf-bier-oam-requirements-01 (work
	in progress), September 2015.		in progress), March 2016.
	Authors' Addresses		Authors' Addresses
	Nagendra Kumar		Nagendra Kumar
	Cisco Systems, Inc.		Cisco Systems, Inc.
	7200 Kit Creek Road		7200 Kit Creek Road
	Research Triangle Park, NC 27709		Research Triangle Park, NC 27709
	US		US
	Email: naikumar@cisco.com		Email: naikumar@cisco.com
	Carlos Pignataro		Carlos Pignataro
	Cisco Systems, Inc.		Cisco Systems, Inc.
	7200 Kit Creek Road		7200 Kit Creek Road
	Research Triangle Park, NC 27709-4987		Research Triangle Park, NC 27709-4987
	US		US
	Email: cpignata@cisco.com		Email: cpignata@cisco.com
	Deepak Kumar		Deepak Kumar
	Cisco Systems, Inc.		Cisco Systems, Inc.
End of changes. 52 change blocks.
	75 lines changed or deleted		115 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/