< draft-ietf-spring-bfd-00.txt		draft-ietf-spring-bfd-01.txt >
	SPRING Working Group G. Mirsky		SPRING Working Group G. Mirsky
	Internet-Draft ZTE Corp.		Internet-Draft ZTE Corp.
	Intended status: Standards Track J. Tantsura		Intended status: Standards Track J. Tantsura
	Expires: March 26, 2021 Apstra, Inc.		Expires: 23 September 2021 Juniper Networks
	I. Varlashkin		I. Varlashkin
	Google		Google
	M. Chen		M. Chen
	Huawei		Huawei
	J. Wenying		J. Wenying
	CMCC		CMCC
	September 22, 2020		22 March 2021
	Bidirectional Forwarding Detection (BFD) in Segment Routing Networks		Bidirectional Forwarding Detection (BFD) in Segment Routing Networks
	Using MPLS Dataplane		Using MPLS Dataplane
	draft-ietf-spring-bfd-00		draft-ietf-spring-bfd-01
	Abstract		Abstract
	Segment Routing (SR) architecture leverages the paradigm of source		Segment Routing (SR) architecture leverages the paradigm of source
	routing. It can be realized in the Multiprotocol Label Switching		routing. It can be realized in the Multiprotocol Label Switching
	(MPLS) network without any change to the data plane. A segment is		(MPLS) network without any change to the data plane. A segment is
	encoded as an MPLS label, and an ordered list of segments is encoded		encoded as an MPLS label, and an ordered list of segments is encoded
	as a stack of labels. Bidirectional Forwarding Detection (BFD) is		as a stack of labels. Bidirectional Forwarding Detection (BFD) is
	expected to monitor any existing path between systems. This document		expected to monitor any existing path between systems. This document
	defines how to use Label Switched Path Ping to bootstrap a BFD		defines how to use Label Switched Path Ping to bootstrap a BFD
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	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 March 26, 2021.		This Internet-Draft will expire on 23 September 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3		1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
	1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3		1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4
	2. Bootstrapping BFD Session over Segment Routed Tunnel with		2. Bootstrapping BFD Session over Segment Routed Tunnel with MPLS
	MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . . . 4		Data Plane . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Use BFD Reverse Path TLV over Segment Routed MPLS Tunnel . . 5		3. Use BFD Reverse Path TLV over Segment Routed MPLS Tunnel . . 5
	4. Use Non-FEC Path TLV . . . . . . . . . . . . . . . . . . . . 5		4. Use Non-FEC Path TLV . . . . . . . . . . . . . . . . . . . . 5
	5. BFD Reverse Path TLV over Segment Routed MPLS Tunnel with		5. BFD Reverse Path TLV over Segment Routed MPLS Tunnel with
	Dynamic Control Plane . . . . . . . . . . . . . . . . . . . . 7		Dynamic Control Plane . . . . . . . . . . . . . . . . . . 7
	6. Applicability of BFD Demand Mode in SR-MPLS Domain . . . . . 7		6. Applicability of BFD Demand Mode in SR-MPLS Domain . . . . . 7
	7. Using BFD to Monitor Point-to-Multipoint SR Policy . . . . . 7		7. Using BFD to Monitor Point-to-Multipoint SR Policy . . . . . 8
	8. Use of Echo BFD in SR-MPLS . . . . . . . . . . . . . . . . . 8		8. Use of Echo BFD in SR-MPLS . . . . . . . . . . . . . . . . . 8
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	9.1. Non-FEC Path TLV . . . . . . . . . . . . . . . . . . . . 8		9.1. Non-FEC Path TLV . . . . . . . . . . . . . . . . . . . . 9
	9.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 9		9.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 10
	10. Implementation Status . . . . . . . . . . . . . . . . . . . . 10		10. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 10		11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11		12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	14.1. Normative References . . . . . . . . . . . . . . . . . . 11		14.1. Normative References . . . . . . . . . . . . . . . . . . 12
	14.2. Informative References . . . . . . . . . . . . . . . . . 13		14.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	[RFC5880], [RFC5881], and [RFC5883] defined the operation of		[RFC5880], [RFC5881], and [RFC5883] defined the operation of
	Bidirectional Forwarding Detection (BFD) protocol between the two		Bidirectional Forwarding Detection (BFD) protocol between the two
	systems over IP networks. [RFC5884] and [RFC7726] set rules for		systems over IP networks. [RFC5884] and [RFC7726] set rules for
	using BFD Asynchronous mode over point-to-point (p2p) Multiprotocol		using BFD Asynchronous mode over point-to-point (p2p) Multiprotocol
	Label Switching (MPLS) Label Switched Path (LSP). These latter		Label Switching (MPLS) Label Switched Path (LSP). These latter
	standards implicitly assume that the remote BFD system, which is at		standards implicitly assume that the remote BFD system, which is at
	the egress Label Edge Router (LER), will use the shortest path route		the egress Label Edge Router (LER), will use the shortest path route
	skipping to change at page 7, line 21 ¶		skipping to change at page 7, line 44 ¶
	tunnel computation BFD Reverse Path TLV MAY use Target FEC sub-TLVs		tunnel computation BFD Reverse Path TLV MAY use Target FEC sub-TLVs
	defined in [RFC8287].		defined in [RFC8287].
	6. Applicability of BFD Demand Mode in SR-MPLS Domain		6. Applicability of BFD Demand Mode in SR-MPLS Domain
	[I-D.mirsky-bfd-mpls-demand] defines how Demand mode of BFD,		[I-D.mirsky-bfd-mpls-demand] defines how Demand mode of BFD,
	specified in sections 6.6 and 6.18.4 of [RFC5880], can be used to		specified in sections 6.6 and 6.18.4 of [RFC5880], can be used to
	monitor uni-directional MPLS LSP. Similar procedures can be		monitor uni-directional MPLS LSP. Similar procedures can be
	following in SR-MPLS to monitor uni-directional SR tunnels:		following in SR-MPLS to monitor uni-directional SR tunnels:
	o an ingress SR node bootstraps BFD session over SR-MPLS in Async		* an ingress SR node bootstraps BFD session over SR-MPLS in Async
	BFD mode;		BFD mode;
	o once BFD session is Up, the ingress SR node switches the egress		* once BFD session is Up, the ingress SR node switches the egress
	LER into the Demand mode by setting D field in BFD Control packet		LER into the Demand mode by setting D field in BFD Control packet
	it transmits;		it transmits;
	o if the egress LER detects the failure of the BFD session, it sends		* if the egress LER detects the failure of the BFD session, it sends
	its BFD Control packet to the ingress SR node over the IP network		its BFD Control packet to the ingress SR node over the IP network
	with a Poll sequence;		with a Poll sequence;
	o if the ingress SR node receives a BFD Control packet from the		* if the ingress SR node receives a BFD Control packet from the
	remote node in a Demand mode with Poll sequence and Diag field		remote node in a Demand mode with Poll sequence and Diag field
	indicating the failure, the ingress SR node transmits BFD Control		indicating the failure, the ingress SR node transmits BFD Control
	packet with Final over IP and switches the BFD over SR-MPLS back		packet with Final over IP and switches the BFD over SR-MPLS back
	into Async mode, sending BFD Control packets one per second.		into Async mode, sending BFD Control packets one per second.
	7. Using BFD to Monitor Point-to-Multipoint SR Policy		7. Using BFD to Monitor Point-to-Multipoint SR Policy
	[I-D.voyer-spring-sr-p2mp-policy] defined variants of SR Policy to		[I-D.voyer-spring-sr-p2mp-policy] defined variants of SR Policy to
	deliver point-to-multipoint (p2mp) services. For the given P2MP		deliver point-to-multipoint (p2mp) services. For the given P2MP
	segment [RFC8562] can be used if, for example, leaves have an		segment [RFC8562] can be used if, for example, leaves have an
	skipping to change at page 8, line 44 ¶		skipping to change at page 9, line 19 ¶
	9. IANA Considerations		9. IANA Considerations
	9.1. Non-FEC Path TLV		9.1. Non-FEC Path TLV
	IANA is requested to assign new TLV type from the from Standards		IANA is requested to assign new TLV type from the from Standards
	Action range of the registry "Multiprotocol Label Switching		Action range of the registry "Multiprotocol Label Switching
	Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters -		Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters -
	TLVs" as defined in Table 1.		TLVs" as defined in Table 1.
	+-------+------------------+---------------+		+=======+==================+===============+
	| Value | TLV Name | Reference |		| Value | TLV Name | Reference |
	+-------+------------------+---------------+		+=======+==================+===============+
	| TBD1 | Non-FEC Path TLV | This document |		| TBD1 | Non-FEC Path TLV | This document |
	+-------+------------------+---------------+		+-------+------------------+---------------+
	Table 1: New Non-FEC Path TLV		Table 1: New Non-FEC Path TLV
	IANA is requested to create new Non-FEC Path sub-TLV registry for the		IANA is requested to create new Non-FEC Path sub-TLV registry for the
	Non-FEC Path TLV, as described in Table 2.		Non-FEC Path TLV, as described in Table 2.
	+-------------+---------------+-------------------------------------+		+=============+===============+=====================================+
	| Range | Registration | Note |		| Range | Registration | Note |
	| | Procedures | |		| | Procedures | |
			+=============+===============+=====================================+
			| 0-16383 | Standards | This range is for mandatory |
			| | Action | TLVs or for optional TLVs |
			| | | that require an error |
			| | | message if not recognized. |
	+-------------+---------------+-------------------------------------+		+-------------+---------------+-------------------------------------+
	| 0-16383 | Standards | This range is for mandatory TLVs or |
	| | Action | for optional TLVs that require an |
	| | | error message if not recognized. |
	| 16384-31743 | Specification | Experimental RFC needed |		| 16384-31743 | Specification | Experimental RFC needed |
	| | Required | |		| | Required | |
	| 32768-49161 | Standards | This range is for optional TLVs |		+-------------+---------------+-------------------------------------+
	| | Action | that can be silently dropped if not |		| 32768-49161 | Standards | This range is for optional |
	| | | recognized. |		| | Action | TLVs that can be silently |
			| | | dropped if not recognized. |
			+-------------+---------------+-------------------------------------+
	| 49162-64511 | Specification | Experimental RFC needed |		| 49162-64511 | Specification | Experimental RFC needed |
	| | Required | |		| | Required | |
			+-------------+---------------+-------------------------------------+
	| 64512-65535 | Private Use | |		| 64512-65535 | Private Use | |
	+-------------+---------------+-------------------------------------+		+-------------+---------------+-------------------------------------+
	Table 2: Non-FEC Path sub-TLV registry		Table 2: Non-FEC Path sub-TLV registry
	IANA is requested to allocate the following values from the Non-FEC		IANA is requested to allocate the following values from the Non-FEC
	Path sub-TLV registry as defined in Table 3.		Path sub-TLV registry as defined in Table 3.
	+-------+-------------------------------------+---------------+		+=======+=====================================+===============+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+-------------------------------------+---------------+		+=======+=====================================+===============+
	| 0 | Reserved | This document |		| 0 | Reserved | This document |
	| TBD2 | Segment Routing MPLS Tunnel sub-TLV | This document |		+-------+-------------------------------------+---------------+
			| TBD2 | Segment Routing MPLS Tunnel sub-TLV | This document |
			+-------+-------------------------------------+---------------+
	| 65535 | Reserved | This document |		| 65535 | Reserved | This document |
	+-------+-------------------------------------+---------------+		+-------+-------------------------------------+---------------+
	Table 3: New Segment Routing Tunnel sub-TLV		Table 3: New Segment Routing Tunnel sub-TLV
	9.2. Return Code		9.2. Return Code
	IANA is requested to create Non-FEC Path sub-TLV sub-registry for the		IANA is requested to create Non-FEC Path sub-TLV sub-registry for the
	new Non-FEC Path TLV and assign a new Return Code value from the		new Non-FEC Path TLV and assign a new Return Code value from the
	"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)		"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
	Ping Parameters" registry, "Return Codes" sub-registry, as follows		Ping Parameters" registry, "Return Codes" sub-registry, as follows
	using a Standards Action value.		using a Standards Action value.
	+--------+-------------------------+---------------+		+========+=========================+===============+
	| Value | Description | Reference |		| Value | Description | Reference |
	+--------+-------------------------+---------------+		+========+=========================+===============+
	| X TBD3 | Too Many TLVs Detected. | This document |		| X TBD3 | Too Many TLVs Detected. | This document |
	+--------+-------------------------+---------------+		+--------+-------------------------+---------------+
	Table 4: New Return Code		Table 4: New Return Code
	10. Implementation Status		10. Implementation Status
	- The organization responsible for the implementation: ZTE		- The organization responsible for the implementation: ZTE
	Corporation.		Corporation.
	skipping to change at page 11, line 6 ¶		skipping to change at page 12, line 4 ¶
	Note to RFC Editor: This section MUST be removed before publication		Note to RFC Editor: This section MUST be removed before publication
	of the document.		of the document.
	11. Security Considerations		11. Security Considerations
	Security considerations discussed in [RFC5880], [RFC5884], [RFC7726],		Security considerations discussed in [RFC5880], [RFC5884], [RFC7726],
	and [RFC8029] apply to this document.		and [RFC8029] apply to this document.
	12. Contributors		12. Contributors
	Xiao Min		Xiao Min
	ZTE Corp.		ZTE Corp.
	Email: xiao.min2@zte.com.cn		Email: xiao.min2@zte.com.cn
	13. Acknowledgments		13. Acknowledgments
	Authors greatly appreciate the help of Qian Xin, who provided the		Authors greatly appreciate the help of Qian Xin, who provided the
	information about the implementation of this specification.		information about the implementation of this specification.
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[I-D.ietf-mpls-bfd-directed]		[I-D.ietf-mpls-bfd-directed]
	Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen,		Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen,
	"Bidirectional Forwarding Detection (BFD) Directed Return		"Bidirectional Forwarding Detection (BFD) Directed Return
	Path for MPLS Label Switched Paths (LSPs)", draft-ietf-		Path for MPLS Label Switched Paths (LSPs)", Work in
	mpls-bfd-directed-15 (work in progress), August 2020.		Progress, Internet-Draft, draft-ietf-mpls-bfd-directed-17,
			16 February 2021, <https://tools.ietf.org/html/draft-ietf-
			mpls-bfd-directed-17>.
	[I-D.mirsky-bfd-mpls-demand]		[I-D.mirsky-bfd-mpls-demand]
	Mirsky, G., "BFD in Demand Mode over Point-to-Point MPLS		Mirsky, G., "BFD in Demand Mode over Point-to-Point MPLS
	LSP", draft-mirsky-bfd-mpls-demand-08 (work in progress),		LSP", Work in Progress, Internet-Draft, draft-mirsky-bfd-
	September 2020.		mpls-demand-08, 9 September 2020,
			<https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-
			08>.
	[I-D.voyer-spring-sr-p2mp-policy]		[I-D.voyer-spring-sr-p2mp-policy]
	daniel.voyer@bell.ca, d., Filsfils, C., Parekh, R.,		Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
	Bidgoli, H., and Z. Zhang, "SR Replication Policy for P2MP		Zhang, "SR Replication Policy for P2MP Service Delivery",
	Service Delivery", draft-voyer-spring-sr-p2mp-policy-03		Work in Progress, Internet-Draft, draft-voyer-spring-sr-
	(work in progress), July 2019.		p2mp-policy-03, 2 July 2019, <https://tools.ietf.org/html/
			draft-voyer-spring-sr-p2mp-policy-03>.
	[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 13, line 19 ¶		skipping to change at page 14, line 19 ¶
	[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,		[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
	Decraene, B., Litkowski, S., and R. Shakir, "Segment		Decraene, B., Litkowski, S., and R. Shakir, "Segment
	Routing with the MPLS Data Plane", RFC 8660,		Routing with the MPLS Data Plane", RFC 8660,
	DOI 10.17487/RFC8660, December 2019,		DOI 10.17487/RFC8660, December 2019,
	<https://www.rfc-editor.org/info/rfc8660>.		<https://www.rfc-editor.org/info/rfc8660>.
	14.2. Informative References		14.2. Informative References
	[I-D.ietf-bess-mvpn-fast-failover]		[I-D.ietf-bess-mvpn-fast-failover]
	Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN fast		Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN Fast
	upstream failover", draft-ietf-bess-mvpn-fast-failover-10		Upstream Failover", Work in Progress, Internet-Draft,
	(work in progress), February 2020.		draft-ietf-bess-mvpn-fast-failover-15, 21 January 2021,
			<https://tools.ietf.org/html/draft-ietf-bess-mvpn-fast-
			failover-15>.
	[I-D.ietf-pim-bfd-p2mp-use-case]		[I-D.ietf-pim-bfd-p2mp-use-case]
	Mirsky, G. and J. Xiaoli, "Bidirectional Forwarding		Mirsky, G. and J. Xiaoli, "Bidirectional Forwarding
	Detection (BFD) for Multi-point Networks and Protocol		Detection (BFD) for Multi-point Networks and Protocol
	Independent Multicast - Sparse Mode (PIM-SM) Use Case",		Independent Multicast - Sparse Mode (PIM-SM) Use Case",
	draft-ietf-pim-bfd-p2mp-use-case-04 (work in progress),		Work in Progress, Internet-Draft, draft-ietf-pim-bfd-p2mp-
	July 2020.		use-case-05, 30 November 2020,
			<https://tools.ietf.org/html/draft-ietf-pim-bfd-p2mp-use-
			case-05>.
	[I-D.ietf-spring-mpls-anycast-segments]		[I-D.ietf-spring-mpls-anycast-segments]
	Sarkar, P., Gredler, H., Filsfils, C., Previdi, S.,		Sarkar, P., Gredler, H., Filsfils, C., Previdi, S.,
	Decraene, B., and M. Horneffer, "Anycast Segments in MPLS		Decraene, B., and M. Horneffer, "Anycast Segments in MPLS
	based Segment Routing", draft-ietf-spring-mpls-anycast-		based Segment Routing", Work in Progress, Internet-Draft,
	segments-03 (work in progress), April 2020.		draft-ietf-spring-mpls-anycast-segments-03, 27 April 2020,
			<https://tools.ietf.org/html/draft-ietf-spring-mpls-
			anycast-segments-03>.
	[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and		[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
	L. Yong, "The Use of Entropy Labels in MPLS Forwarding",		L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
	RFC 6790, DOI 10.17487/RFC6790, November 2012,		RFC 6790, DOI 10.17487/RFC6790, November 2012,
	<https://www.rfc-editor.org/info/rfc6790>.		<https://www.rfc-editor.org/info/rfc6790>.
	Authors' Addresses		Authors' Addresses
	Greg Mirsky		Greg Mirsky
	ZTE Corp.		ZTE Corp.
	Email: gregimirsky@gmail.com		Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com
	Jeff Tantsura		Jeff Tantsura
	Apstra, Inc.		Juniper Networks
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
	Ilya Varlashkin		Ilya Varlashkin
	Google		Google
	Email: Ilya@nobulus.com		Email: Ilya@nobulus.com
	Mach(Guoyi) Chen		Mach(Guoyi) Chen
	Huawei		Huawei
	Email: mach.chen@huawei.com		Email: mach.chen@huawei.com
End of changes. 40 change blocks.
	69 lines changed or deleted		85 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/