< draft-ietf-bfd-multipoint-active-tail-09.txt		draft-ietf-bfd-multipoint-active-tail-10.txt >
	Internet Engineering Task Force D. Katz		Internet Engineering Task Force D. Katz
	Internet-Draft Juniper Networks		Internet-Draft Juniper Networks
	Updates: XXXX (RFC BFD for Multi-point D. Ward		Updates: XXXX (RFC BFD for Multi-point D. Ward
	Networks) (if approved) Cisco Systems		Networks) (if approved) Cisco Systems
	Intended status: Standards Track S. Pallagatti, Ed.		Intended status: Standards Track S. Pallagatti, Ed.
	Expires: December 20, 2018 Individual Contributor		Expires: January 4, 2019 Rtbrick
	G. Mirsky, Ed.		G. Mirsky, Ed.
	ZTE Corp.		ZTE Corp.
	June 18, 2018		July 3, 2018
	BFD Multipoint Active Tails.		BFD Multipoint Active Tails.
	draft-ietf-bfd-multipoint-active-tail-09		draft-ietf-bfd-multipoint-active-tail-10
	Abstract		Abstract
	This document describes active tail extensions to and updates the		This document describes active tail extensions to and updates the
	Bidirectional Forwarding Detection (BFD) protocol for multipoint		Bidirectional Forwarding Detection (BFD) protocol for multipoint
	networks.		networks.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 20, 2018.		This Internet-Draft will expire on January 4, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	4. Overview		4. Overview
	A head may wish to be alerted to the tails' connectivity (or lack		A head may wish to be alerted to the tails' connectivity (or lack
	thereof), there are a number of options. First, if all that is		thereof), and there are a number of options to achieve that. First,
	needed is a best-effort failure notification, as discussed in		if all that is needed is a best-effort failure notification, as
	Section 5.2.1, the tails can send unsolicited unicast BFD Control		discussed in Section 5.2.1, the tails can send unsolicited unicast
	packets to the head when the path fails, as described in Section 6.4.		BFD Control packets to the head when the path fails, as described in
			Section 6.4.
	If the head wishes to know of the active tails on the multipoint		If the head wishes to know of the active tails on the multipoint
	path, it may send a multipoint BFD Control packet with the Poll (P)		path, it may send a multipoint BFD Control packet with the Poll (P)
	bit set, which will induce the tails to return a unicast BFD Control		bit set, which will induce the tails to return a unicast BFD Control
	packet with the Final (F) bit set (detailed description in		packet with the Final (F) bit set (detailed description in
	Section 5.2.2). The head can then create BFD session state for each		Section 5.2.2). The head can then create BFD session state for each
	of the tails that have multipoint connectivity. If the head sends		of the tails that have multipoint connectivity. If the head sends
	such a packet on occasion, it can keep track of which tails answer,		such a packet on occasion, it can keep track of which tails answer,
	thus providing a more deterministic mechanism for detecting which		thus providing a more deterministic mechanism for detecting which
	tails fail to respond (implying a loss of multipoint connectivity).		tails fail to respond (implying a loss of multipoint connectivity).
	skipping to change at page 5, line 15 ¶		skipping to change at page 5, line 16 ¶
	For the different modes described below the setting of new state		For the different modes described below the setting of new state
	variables are given even if these are only introduced later in the		variables are given even if these are only introduced later in the
	document (see Section 6.3).		document (see Section 6.3).
	5.1. No Head Notification		5.1. No Head Notification
	In this scenario, only the multipoint path is used and none of the		In this scenario, only the multipoint path is used and none of the
	others matter. A failure in the multipoint path will result in the		others matter. A failure in the multipoint path will result in the
	tail noticing the failure within a detection time, and the head will		tail noticing the failure within a detection time, and the head will
	remain ignorant of the tail state. This mode emulates the behavior		remain ignorant of the tail state. This mode emulates the behavior
	described in [I-D.ietf-bfd-multipoint]. In this mode for		described in [I-D.ietf-bfd-multipoint]. In this mode,
	bfd.SessionType is MultipointTail, variable bfd.SilentTail (see		bfd.SessionType is MultipointTail and the variable bfd.SilentTail
	Section 6.3.1) MUST be set to 1. If bfd.SessionType is		(see Section 6.3.1) MUST be set to 1. If bfd.SessionType is
	MultipointHead or MultipointClient bfd.ReportTailDown MUST be set to		MultipointHead or MultipointClient bfd.ReportTailDown MUST be set to
	0. The head MAY set bfd.RequiredMinRxInterval to zero and thus		0. The head MAY set bfd.RequiredMinRxInterval to zero and thus
	suppress tails sending any BFD control packets.		suppress tails sending any BFD control packets.
	5.2. Head Notification		5.2. Head Notification
	In these scenarios, the tail sends unsolicited or solicited BFD		In these scenarios, the tail sends unsolicited or solicited BFD
	packets in response to the detection of a multipoint path failure.		packets in response to the detection of a multipoint path failure.
	All these scenarios have common settings:		All these scenarios have common settings:
	o if bfd.SessionType is MultipointTail, variable bfd.SilentTail (see		o if bfd.SessionType is MultipointTail, the variable bfd.SilentTail
	Section 6.3.1) MUST be set to 0;		(see Section 6.3.1) MUST be set to 0;
	o if bfd.SessionType is MultipointHead or MultipointClient		o if bfd.SessionType is MultipointHead or MultipointClient
	bfd.ReportTailDown MUST be set to 1;		bfd.ReportTailDown MUST be set to 1;
	o the head MUST set bfd.RequiredMinRxInterval to non-zero and thus		o the head MUST set bfd.RequiredMinRxInterval to non-zero and thus
	allow tails sending BFD control packets.		allow tails sending BFD control packets.
	5.2.1. Head Notification Without Polling		5.2.1. Head Notification Without Polling
	In this scenario, the tail sends unsolicited BFD packets in response		In this scenario, the tail sends unsolicited BFD packets in response
	skipping to change at page 8, line 6 ¶		skipping to change at page 8, line 6 ¶
	If the head is keeping track of some or all of the tails, it has a		If the head is keeping track of some or all of the tails, it has a
	session of type MultipointClient per tail that it cares about. All		session of type MultipointClient per tail that it cares about. All
	of the MultipointClient sessions for tails on a particular multipoint		of the MultipointClient sessions for tails on a particular multipoint
	path are associated with the MultipointHead session to which the		path are associated with the MultipointHead session to which the
	clients are listening. A BFD Poll Sequence may be sent over a		clients are listening. A BFD Poll Sequence may be sent over a
	MultipointClient session to a tail if the head wishes to verify		MultipointClient session to a tail if the head wishes to verify
	connectivity. These sessions receive any BFD Control packets sent by		connectivity. These sessions receive any BFD Control packets sent by
	the tails, and MUST NOT transmit periodic BFD Control packets other		the tails, and MUST NOT transmit periodic BFD Control packets other
	than Poll Sequences (since periodic transmission is always done by		than Poll Sequences (since periodic transmission is always done by
	the MultipointHead session).		the MultipointHead session). Note that the settings of all BFD
			variables in a MultipointClient session for a particular tail
			override the corresponding settings in the MultipointHead session.
	6.2. Multipoint Client Session Failure		6.2. Multipoint Client Session Failure
	If a MultipointClient session receives a BFD Control packet from the		If a MultipointClient session receives a BFD Control packet from the
	tail with state Down or AdminDown, the head reliably knows that the		tail with state Down or AdminDown, the head reliably knows that the
	tail has lost multipoint connectivity. If the Detection Time expires		tail has lost multipoint connectivity. If the Detection Time expires
	on a MultipointClient session, it is ambiguous as to whether the		on a MultipointClient session, it is ambiguous as to whether the
	multipoint connectivity failed or whether there was a unicast path		multipoint connectivity failed or whether there was a unicast path
	problem in one direction or the other, so the head does not reliably		problem in one direction or the other, so the head does not reliably
	know the tail's state.		know the tail's state.
	6.3. State Variables		6.3. State Variables
	BFD Multipoint active tail introduces new state variables and		BFD Multipoint active tail introduces new state variables and
	modifies the usage of a few existing ones defined in section 4.4 of		modifies the usage of a few existing ones defined in section 4.4 of
	[I-D.ietf-bfd-multipoint].		[I-D.ietf-bfd-multipoint].
	6.3.1. New State Variables		6.3.1. New State Variables
	Few state variables are added in support of Multipoint BFD active		A few state variables are added in support of Multipoint BFD active
	tail.		tail.
	bfd.SilentTail		bfd.SilentTail
	If 0, a tail may send packets to the head according to other		If 0, a tail may send packets to the head according to other
	parts of this specification. Setting this to 1 allows tails to		parts of this specification. Setting this to 1 allows tails to
	be provisioned to always be silent, even when the head is		be provisioned to always be silent, even when the head is
	soliciting traffic from the tails. This can be useful, for		soliciting traffic from the tails. This can be useful, for
	example, in deployments of a large number of tails when the		example, in deployments of a large number of tails when the
	head wishes to track the state of a subset of them. This		head wishes to track the state of a subset of them. This
	skipping to change at page 9, line 10 ¶		skipping to change at page 9, line 12 ¶
	fail. If 0, the tail will never send periodic BFD Control		fail. If 0, the tail will never send periodic BFD Control
	packets, and the head will not be notified of session failures		packets, and the head will not be notified of session failures
	by the tails. This variable MUST be initialized based on		by the tails. This variable MUST be initialized based on
	configuration.		configuration.
	This variable is only pertinent when bfd.SessionType is		This variable is only pertinent when bfd.SessionType is
	MultipointHead or MultipointClient.		MultipointHead or MultipointClient.
	bfd.UnicastRcvd		bfd.UnicastRcvd
	Set to 1 if a tail receives a unicast BFD Control packet from		Set to 1 if a tail has received a unicast BFD Control packet
	the head. This variable MUST be set to zero if the session		from the head while being in Up state. This variable MUST be
	transitions from Up state to some other state.		set to zero if the session transitions from Up state to some
			other state.
	This variable MUST be initialized to zero.		This variable MUST be initialized to zero.
	This variable is only pertinent when bfd.SessionType is		This variable is only pertinent when bfd.SessionType is
	MultipointTail.		MultipointTail.
	6.3.2. New State Variable Value		6.3.2. New State Variable Value
	A new state variable value being added to:		A new state variable value being added to:
	skipping to change at page 12, line 41 ¶		skipping to change at page 12, line 41 ¶
	single tail).		single tail).
	Any tail may be provisioned to never send *any* BFD Control packets		Any tail may be provisioned to never send *any* BFD Control packets
	to the head by setting bfd.SilentTail to 1. This provides a		to the head by setting bfd.SilentTail to 1. This provides a
	mechanism by which only a subset of tails reports their session		mechanism by which only a subset of tails reports their session
	status to the head.		status to the head.
	6.9. Soliciting the Tails		6.9. Soliciting the Tails
	If the head wishes to know of the active tails, the MultipointHead		If the head wishes to know of the active tails, the MultipointHead
	session MAY send a BFD Control packet as specified in Section 6.13.3,		session can send a BFD Control packet as specified in Section 6.13.3,
	with the Poll (P) bit set to 1. This will cause all of the tails to		with the Poll (P) bit set to 1. This will cause all of the tails to
	reply with a unicast BFD Control Packet, randomized across one packet		reply with a unicast BFD Control Packet, randomized across one packet
	interval.		interval.
	The decision as to when to send a multipoint Poll is outside the		The decision as to when to send a multipoint Poll is outside the
	scope of this specification. However, it must never be sent more		scope of this specification. However, it must never be sent more
	often than the regular multipoint BFD Control packet. Since the tail		often than the regular multipoint BFD Control packet. Since the tail
	will treat a multipoint Poll like any other multipoint BFD Control		will treat a multipoint Poll like any other multipoint BFD Control
	packet, Polls may be sent in lieu of non-Poll packets.		packet, Polls may be sent in lieu of non-Poll packets.
	skipping to change at page 13, line 18 ¶		skipping to change at page 13, line 18 ¶
	Note that for this mechanism to work properly, the Detection Time		Note that for this mechanism to work properly, the Detection Time
	(which is equal to bfd.DesiredMinTxInterval) MUST be greater than the		(which is equal to bfd.DesiredMinTxInterval) MUST be greater than the
	round trip time of BFD Control packets from the head to the tail (via		round trip time of BFD Control packets from the head to the tail (via
	the multipoint path) and back (via a unicast path). See Section 6.11		the multipoint path) and back (via a unicast path). See Section 6.11
	for more details.		for more details.
	6.10. Verifying Connectivity to Specific Tails		6.10. Verifying Connectivity to Specific Tails
	If the head wishes to verify connectivity to a specific tail, the		If the head wishes to verify connectivity to a specific tail, the
	corresponding MultipointClient session MAY send a BFD Poll Sequence		corresponding MultipointClient session can send a BFD Poll Sequence
	to said tail. This might be done in reaction to the expiration of		to said tail. This might be done in reaction to the expiration of
	the Detection Timer (the tail didn't respond to a multipoint Poll),		the Detection Timer (the tail didn't respond to a multipoint Poll),
	or it might be done on a proactive basis.		or it might be done on a proactive basis.
	The interval between transmitted packets in the Poll Sequence MUST be		The interval between transmitted packets in the Poll Sequence MUST be
	calculated as specified in the base BFD specification [RFC5880] (the		calculated as specified in the base BFD specification [RFC5880] (the
	greater of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval).		greater of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval).
	The value transmitted in Required Min RX Interval will be used by the		The value transmitted in Required Min RX Interval will be used by the
	tail (rather than the value received in any multipoint packet) when		tail (rather than the value received in any multipoint packet) when
	skipping to change at page 15, line 14 ¶		skipping to change at page 15, line 14 ¶
	6.13.1. Reception of BFD Control Packets		6.13.1. Reception of BFD Control Packets
	The following procedure updates parts of Section 5.13.1 of		The following procedure updates parts of Section 5.13.1 of
	[I-D.ietf-bfd-multipoint].		[I-D.ietf-bfd-multipoint].
	When a BFD Control packet is received, the procedure defined in		When a BFD Control packet is received, the procedure defined in
	Section 5.13.1 of [I-D.ietf-bfd-multipoint] MUST be followed, in the		Section 5.13.1 of [I-D.ietf-bfd-multipoint] MUST be followed, in the
	order specified. If the packet is discarded according to these		order specified. If the packet is discarded according to these
	rules, processing of the packet MUST cease at that point. In		rules, processing of the packet MUST cease at that point. In
	addition to that, if tail tracking is desired by the head, below		addition to that, if tail tracking is desired by the head, the
	procedure MUST be applied.		following procedure MUST be applied.
	If bfd.SessionType is MultipointTail		If bfd.SessionType is MultipointTail
	If bfd.UnicastRcvd is 0 or the M bit is clear, set		If bfd.UnicastRcvd is 0 or the M bit is clear, set
	bfd.RemoteMinRxInterval to the value of Required Min RX		bfd.RemoteMinRxInterval to the value of Required Min RX
	Interval.		Interval.
	If the M bit is clear, set bfd.UnicastRcvd to 1.		If the M bit is clear, set bfd.UnicastRcvd to 1.
	Else (not MultipointTail)		Else (not MultipointTail)
	skipping to change at page 16, line 17 ¶		skipping to change at page 16, line 17 ¶
	If bfd.SessionType is not MultipointClient, the packet		If bfd.SessionType is not MultipointClient, the packet
	MUST be discarded.		MUST be discarded.
	6.13.3. Transmitting BFD Control Packets		6.13.3. Transmitting BFD Control Packets
	A system MUST NOT periodically transmit BFD Control packets if		A system MUST NOT periodically transmit BFD Control packets if
	bfd.SessionType is MultipointClient and a Poll Sequence is not being		bfd.SessionType is MultipointClient and a Poll Sequence is not being
	transmitted.		transmitted.
	If bfd.SessionType value is MultipointTail and periodic the		If bfd.SessionType value is MultipointTail and the periodic
	transmission of BFD Control packets is just starting (due to Demand		transmission of BFD Control packets is just starting (due to Demand
	mode not being active on the remote system), the first packet to be		mode not being active on the remote system), the first packet to be
	transmitted MUST be delayed by a random amount of time between zero		transmitted MUST be delayed by a random amount of time between zero
	and (0.9 * bfd.RemoteMinRxInterval).		and (0.9 * bfd.RemoteMinRxInterval).
	If a BFD Control packet is received with the Poll (P) bit set to 1,		If a BFD Control packet is received with the Poll (P) bit set to 1,
	the receiving system MUST transmit a BFD Control packet with the Poll		the receiving system MUST transmit a BFD Control packet with the Poll
	(P) bit clear and the Final (F) bit, without respect to the		(P) bit clear and the Final (F) bit, without respect to the
	transmission timer or any other transmission limitations, without		transmission timer or any other transmission limitations, without
	respect to the session state, and without respect to whether Demand		respect to the session state, and without respect to whether Demand
	skipping to change at page 16, line 41 ¶		skipping to change at page 16, line 41 ¶
	or equal to the interval between transmitted packets imposed by the		or equal to the interval between transmitted packets imposed by the
	rate limiting function. If the Multipoint (M) bit is set in the		rate limiting function. If the Multipoint (M) bit is set in the
	received packet, the packet transmission MUST be delayed by a random		received packet, the packet transmission MUST be delayed by a random
	amount of time between zero and (0.9 * bfd.RemoteMinRxInterval).		amount of time between zero and (0.9 * bfd.RemoteMinRxInterval).
	Otherwise, the packet MUST be transmitted as soon as practicable.		Otherwise, the packet MUST be transmitted as soon as practicable.
	A system MUST NOT set the Demand (D) bit if bfd.SessionType is		A system MUST NOT set the Demand (D) bit if bfd.SessionType is
	MultipointClient unless bfd.DemandMode is 1, bfd.SessionState is Up,		MultipointClient unless bfd.DemandMode is 1, bfd.SessionState is Up,
	and bfd.RemoteSessionState is Up.		and bfd.RemoteSessionState is Up.
	Contents of transmitted packet MUST be as explained in section 5.13.3		Content of the transmitted packet MUST be as explained in section
	of [I-D.ietf-bfd-multipoint].		5.13.3 of [I-D.ietf-bfd-multipoint].
	7. Assumptions		7. Assumptions
	If head notification is to be used, it is assumed that a multipoint		If head notification is to be used, it is assumed that a multipoint
	BFD packet encapsulation contains enough information so that a tail		BFD packet encapsulation contains enough information so that a tail
	can address a unicast BFD packet to the head.		can address a unicast BFD packet to the head.
	If head notification is to be used, it is assumed that is that there		If head notification is to be used, it is assumed that is that there
	is bidirectional unicast communication available (at the same		is bidirectional unicast communication available (at the same
	protocol layer within which BFD is being run) between the tail and		protocol layer within which BFD is being run) between the tail and
	skipping to change at page 17, line 29 ¶		skipping to change at page 17, line 29 ¶
	This document has no actions for IANA.		This document has no actions for IANA.
	9. Security Considerations		9. Security Considerations
	The same security considerations as those described in [RFC5880] and		The same security considerations as those described in [RFC5880] and
	[I-D.ietf-bfd-multipoint] apply to this document.		[I-D.ietf-bfd-multipoint] apply to this document.
	Additionally, implementations that create MultpointClient sessions		Additionally, implementations that create MultpointClient sessions
	dynamically upon receipt of BFD Control packet from a tail MUST		dynamically upon receipt of BFD Control packet from a tail MUST
	implement protective measures to prevent an infinite number of		implement protective measures to prevent a number of MultipointClient
	MultipointClient sessions being created. Below are listed some		sessions being created growing out of control. Below are listed some
	points to be considered in such implementations.		points to be considered in such implementations.
	When the number of MultipointClient sessions exceeds the number of		When the number of MultipointClient sessions exceeds the number of
	expected tails, then the implementation should generate an alarm		expected tails, then the implementation should generate an alarm
	to users to indicate the anomaly.		to users to indicate the anomaly.
	The implementation should have a reasonable upper bound on the		The implementation should have a reasonable upper bound on the
	number of MultipointClient sessions that can be created, with the		number of MultipointClient sessions that can be created, with the
	upper bound potentially being computed based on the number of		upper bound potentially being computed based on the number of
	multicast streams that the system is expecting.		multicast streams that the system is expecting.
	skipping to change at page 18, line 15 ¶		skipping to change at page 18, line 15 ¶
	11. Acknowledgments		11. Acknowledgments
	Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan,		Authors would also like to thank Nobo Akiya, Vengada Prasad Govindan,
	Jeff Haas, Wim Henderickx and Mingui Zhang who have greatly		Jeff Haas, Wim Henderickx and Mingui Zhang who have greatly
	contributed to this document.		contributed to this document.
	12. Normative References		12. Normative References
	[I-D.ietf-bfd-multipoint]		[I-D.ietf-bfd-multipoint]
	Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD for		Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD for
	Multipoint Networks", draft-ietf-bfd-multipoint-17 (work		Multipoint Networks", draft-ietf-bfd-multipoint-18 (work
	in progress), June 2018.		in progress), June 2018.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection		[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
	(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,		(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
	<https://www.rfc-editor.org/info/rfc5880>.		<https://www.rfc-editor.org/info/rfc5880>.
	skipping to change at page 19, line 13 ¶		skipping to change at page 19, line 13 ¶
	Email: dkatz@juniper.net		Email: dkatz@juniper.net
	Dave Ward		Dave Ward
	Cisco Systems		Cisco Systems
	170 West Tasman Dr.		170 West Tasman Dr.
	San Jose, California 95134		San Jose, California 95134
	USA		USA
	Email: wardd@cisco.com		Email: wardd@cisco.com
	Santosh Pallagatti (editor)		Santosh Pallagatti (editor)
	Individual Contributor		Rtbrick
	Embassy Business Park
	Bangalore, KA 560093
	India
	Email: santosh.pallagatti@gmail.com		Email: santosh.pallagatti@gmail.com
	Greg Mirsky (editor)		Greg Mirsky (editor)
	ZTE Corp.		ZTE Corp.
	Email: gregimirsky@gmail.com		Email: gregimirsky@gmail.com
End of changes. 18 change blocks.
	32 lines changed or deleted		33 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/