< draft-xuclad-spring-sr-service-chaining-00.txt		draft-xuclad-spring-sr-service-chaining-01.txt >
	SPRING F. Clad, Ed.		SPRING F. Clad, Ed.
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Intended status: Standards Track X. Xu, Ed.		Intended status: Standards Track X. Xu, Ed.
	Expires: July 12, 2018 Huawei		Expires: September 6, 2018 Alibaba
	C. Filsfils		C. Filsfils
	Cisco Systems, Inc.		Cisco Systems, Inc.
	D. Bernier		D. Bernier
	Bell Canada		Bell Canada
			C. Li
			Huawei
	B. Decraene		B. Decraene
	Orange		Orange
	S. Ma		S. Ma
	Juniper		Juniper
	C. Yadlapalli		C. Yadlapalli
	AT&T		AT&T
	W. Henderickx		W. Henderickx
	Nokia		Nokia
	S. Salsano		S. Salsano
	Universita di Roma "Tor Vergata"		Universita di Roma "Tor Vergata"
	January 8, 2018		March 5, 2018
	Segment Routing for Service Chaining		Segment Routing for Service Chaining
	draft-xuclad-spring-sr-service-chaining-00		draft-xuclad-spring-sr-service-chaining-01
	Abstract		Abstract
	This document defines data plane functionality required to implement		This document defines data plane functionality required to implement
	service segments and achieve service chaining in SR-enabled MPLS and		service segments and achieve service chaining in SR-enabled MPLS and
	IP networks, as described in the Segment Routing architecture.		IP networks, as described in the Segment Routing architecture.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 10 ¶
	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 July 12, 2018.		This Internet-Draft will expire on September 6, 2018.
	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 3, line 12 ¶		skipping to change at page 3, line 14 ¶
	6.4.3. Variant 2: Caching . . . . . . . . . . . . . . . . . 29		6.4.3. Variant 2: Caching . . . . . . . . . . . . . . . . . 29
	7. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 29		7. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	7.1. MPLS data plane . . . . . . . . . . . . . . . . . . . . . 29		7.1. MPLS data plane . . . . . . . . . . . . . . . . . . . . . 29
	7.2. IPv6 data plane . . . . . . . . . . . . . . . . . . . . . 29		7.2. IPv6 data plane . . . . . . . . . . . . . . . . . . . . . 29
	7.2.1. SRH TLV objects . . . . . . . . . . . . . . . . . . . 29		7.2.1. SRH TLV objects . . . . . . . . . . . . . . . . . . . 29
	7.2.2. SRH tag . . . . . . . . . . . . . . . . . . . . . . . 30		7.2.2. SRH tag . . . . . . . . . . . . . . . . . . . . . . . 30
	8. Implementation status . . . . . . . . . . . . . . . . . . . . 30		8. Implementation status . . . . . . . . . . . . . . . . . . . . 30
	9. Related works . . . . . . . . . . . . . . . . . . . . . . . . 31		9. Related works . . . . . . . . . . . . . . . . . . . . . . . . 31
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 31		11. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
	13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32		13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
	14.1. Normative References . . . . . . . . . . . . . . . . . . 32		14.1. Normative References . . . . . . . . . . . . . . . . . . 32
	14.2. Informative References . . . . . . . . . . . . . . . . . 32		14.2. Informative References . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
	1. Introduction		1. Introduction
	Segment Routing (SR) is an architecture based on the source routing		Segment Routing (SR) is an architecture based on the source routing
	paradigm that seeks the right balance between distributed		paradigm that seeks the right balance between distributed
	skipping to change at page 4, line 22 ¶		skipping to change at page 4, line 25 ¶
	[I-D.ietf-spring-segment-routing-mpls]		[I-D.ietf-spring-segment-routing-mpls]
	o Segment Routing Traffic Engineering Policy		o Segment Routing Traffic Engineering Policy
	[I-D.filsfils-spring-segment-routing-policy]		[I-D.filsfils-spring-segment-routing-policy]
	o Segment Routing Header [I-D.ietf-6man-segment-routing-header]		o Segment Routing Header [I-D.ietf-6man-segment-routing-header]
	o SRv6 Network Programming		o SRv6 Network Programming
	[I-D.filsfils-spring-srv6-network-programming]		[I-D.filsfils-spring-srv6-network-programming]
	o Unified Source Routing Instruction using MPLS Label Stack		o SR-MPLS over IP [I-D.xu-mpls-sr-over-ip]
	[I-D.xu-mpls-unified-source-routing-instruction]
	o Service Function Chaining Architecture [RFC7665]		o Service Function Chaining Architecture [RFC7665]
	2. Terminology		2. Terminology
	This document leverages the terminology introduced in		This document leverages the terminology introduced in
	[I-D.ietf-spring-segment-routing],		[I-D.ietf-spring-segment-routing],
	[I-D.filsfils-spring-segment-routing-policy] and [RFC7665]. It also		[I-D.filsfils-spring-segment-routing-policy] and [RFC7665]. It also
	introduces the following new terminology.		introduces the following new terminology.
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 7 ¶
	Service Segment: Segment associated with an SF, either directly or		Service Segment: Segment associated with an SF, either directly or
	via an SR proxy		via an SR proxy
	SR SFC policy: SR policy, as defined in		SR SFC policy: SR policy, as defined in
	[I-D.filsfils-spring-segment-routing-policy], that includes at least		[I-D.filsfils-spring-segment-routing-policy], that includes at least
	one Service Segment. An SR SFC policy may also contain other types		one Service Segment. An SR SFC policy may also contain other types
	of segments, such as VPN or TE segments.		of segments, such as VPN or TE segments.
	3. Classification and steering		3. Classification and steering
	Classification and steering mechanisms are defined in section 12 of		Classification and steering mechanisms are defined in section 8 of
	[I-D.filsfils-spring-segment-routing-policy] and are independent from		[I-D.filsfils-spring-segment-routing-policy] and are independent from
	the purpose of the SR policy. From a headend perspective, there is		the purpose of the SR policy. From a headend perspective, there is
	no difference whether a policy contains IGP, BGP, peering, VPN and		no difference whether a policy contains IGP, BGP, peering, VPN and
	service segments, or any combination of these.		service segments, or any combination of these.
	As documented in the above reference, traffic is classified when		As documented in the above reference, traffic is classified when
	entering an SR domain. The SR policy head-end may, depending on its		entering an SR domain. The SR policy head-end may, depending on its
	capabilities, classify the packets on a per-destination basis, via		capabilities, classify the packets on a per-destination basis, via
	simple FIB entries, or apply more complex policy routing rules		simple FIB entries, or apply more complex policy routing rules
	requiring to look deeper into the packet. These rules are expected		requiring to look deeper into the packet. These rules are expected
	skipping to change at page 9, line 10 ¶		skipping to change at page 9, line 10 ¶
	5.1. SR-MPLS data plane		5.1. SR-MPLS data plane
	5.1.1. Encoding SFP Information by an MPLS Label Stack		5.1.1. Encoding SFP Information by an MPLS Label Stack
	+-----------------------------------------------------+		+-----------------------------------------------------+
	| SR-MPLS network |		| SR-MPLS network |
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| | SF1 | | SF2 | |		| | SF1 | | SF2 | |
	| +----+----+ +----+----+ |		| +----+----+ +----+----+ |
	| +---------+ | | +---------+ |		| +---------+ | | +---------+ |
	| | L(SFF2) | | | | L(T) | |		| | S(SFF2) | | | | S(T) | |
	| +---------+ | | +---------+ |		| +---------+ | | +---------+ |
	| | L(SF2) | | | |Inner pkt| |		| | S(SF2) | | | |Inner pkt| |
	| +---------+ | | +---------+ |		| +---------+ | | +---------+ |
	| | L(T) | | | |		| | S(T) | | | |
	| +---------+ | ^ | | |		| +---------+ | ^ | | |
	| |Inner pkt| ^ | | | | | |		| |Inner pkt| ^ | | | | | |
	| +---------+ | | | (5)| | |(6) |		| +---------+ | | | (5)| | |(6) |
	| (2)| | |(3) | | V |		| (2)| | |(3) | | V |
	| (1) | | V (4) | (7) |		| (1) | | V (4) | (7) |
	+----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+		+----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+
	| Head-end +------+ SFF1 +-------+ SFF2 +-------+ Tail-end |		| Head-end +------+ SFF1 +-------+ SFF2 +-------+ Tail-end |
	+----------+ +---------+ +---------+ +----+-----+		+----------+ +---------+ +---------+ +----+-----+
	| +---------+ +---------+ +---------+ |		| +---------+ +---------+ +---------+ |
	| | L(SFF1) | | L(SFF2) | | L(T) | |		| | S(SFF1) | | S(SFF2) | | S(T) | |
	| +---------+ +---------+ +---------+ |		| +---------+ +---------+ +---------+ |
	| | L(SF1) | | L(SF2) | |Inner pkt| |		| | S(SF1) | | S(SF2) | |Inner pkt| |
	| +---------+ +---------+ +---------+ |		| +---------+ +---------+ +---------+ |
	| | L(SFF2) | | L(T) | |		| | S(SFF2) | | S(T) | |
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| | L(SF2) | |Inner pkt| |		| | S(SF2) | |Inner pkt| |
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| | L(T) | |		| | S(T) | |
	| +---------+ |		| +---------+ |
	| |Inner pkt| |		| |Inner pkt| |
	| +---------+ |		| +---------+ |
	+-----------------------------------------------------+		+-----------------------------------------------------+
	Figure 2: Packet walk in MPLS underlay		Figure 2: Packet walk in MPLS underlay
	As shown in Figure 2, the head-end, acting as a service classifier,		As shown in Figure 2, the head-end, acting as a service classifier,
	determines that the selected packet needs to travel through an SFC		determines that the selected packet needs to travel through an SFC
	(SF1->SF2) and steers this packet into the appropriate SR policy as		(SF1->SF2) and steers this packet into the appropriate SR policy as
	skipping to change at page 10, line 6 ¶		skipping to change at page 10, line 6 ¶
	result, the packet is encapsulated with an MPLS label stack		result, the packet is encapsulated with an MPLS label stack
	containing the segment list <SFF1, SF1, SFF2, SF2, T>. This segment		containing the segment list <SFF1, SF1, SFF2, SF2, T>. This segment
	list encodes in a stateless manner the SFP corresponding to the above		list encodes in a stateless manner the SFP corresponding to the above
	SFC as an MPLS label stack where each service segment is a local MPLS		SFC as an MPLS label stack where each service segment is a local MPLS
	label allocated from SFFs' label spaces. To some extent, the MPLS		label allocated from SFFs' label spaces. To some extent, the MPLS
	label stack here could be looked as a specific implementation of the		label stack here could be looked as a specific implementation of the
	SFC encapsulation used for containing the SFP information [RFC7665],		SFC encapsulation used for containing the SFP information [RFC7665],
	which does not require the SFF to maintain per-chain state.		which does not require the SFF to maintain per-chain state.
	When the encapsulated packet arrives at SFF1, SFF1 knows how to send		When the encapsulated packet arrives at SFF1, SFF1 knows how to send
	the packet to SF1 based on the top label (i.e., L(SF1)) of the		the packet to SF1 based on the top label (i.e., S(SF1)) of the
	received MPLS packet. We first consider the case where SF1 is an SR-		received MPLS packet. We first consider the case where SF1 is an SR-
	aware SF, i.e., it understands how to process a packet with a pre-		aware SF, i.e., it understands how to process a packet with a pre-
	pended SR-MPLS label stack. In this case the packet would be sent to		pended SR-MPLS label stack. In this case the packet would be sent to
	SF1 by SFF1 with the label stack L(SFF2)->L(SF2). SF1 would perform		SF1 by SFF1 with the label stack S(SFF2)->S(SF2). SF1 would perform
	the required service function on the received MPLS packet where the		the required service function on the received MPLS packet where the
	payload type is determined using the first nibble of the MPLS		payload type is determined using the first nibble of the MPLS
	payload. After the MPLS packet is returned from SF1, SFF1 would send		payload. After the MPLS packet is returned from SF1, SFF1 would send
	it to SFF2 according to the top label (i.e., L(SFF2)).		it to SFF2 according to the top label (i.e., S(SFF2)).
	If SF1 is an SR-unaware SF, i.e. one that is unable to process the		If SF1 is an SR-unaware SF, i.e. one that is unable to process the
	MPLS label stack, the remaining MPLS label stack (i.e.,		MPLS label stack, the remaining MPLS label stack (i.e.,
	L(SFF2)->L(SF2)) MUST be stripped from the packet before sending the		S(SFF2)->S(SF2)) MUST be stripped from the packet before sending the
	packet to SF1. When the packet is returned from SF1, SFF1 would re-		packet to SF1. When the packet is returned from SF1, SFF1 would re-
	impose the MPLS label stack which had been previously stripped and		impose the MPLS label stack which had been previously stripped and
	then send the packet to SFF2 according to the current top label		then send the packet to SFF2 according to the current top label
	(i.e., L(SFF2)). Proxy mechanisms to support SR-unaware SFs are		(i.e., S(SFF2)). Proxy mechanisms to support SR-unaware SFs are
	proposed in section 6 of this document.		proposed in section 6 of this document.
	When the encapsulated packet arrives at SFF2, SFF2 would perform the		When the encapsulated packet arrives at SFF2, SFF2 would perform the
	similar action to that described above.		similar action to that described above.
	By leveraging the SR-MPLS data plane,		By leveraging the SR-MPLS data plane, [I-D.xu-mpls-sr-over-ip]
	[I-D.xu-mpls-unified-source-routing-instruction] describes a source		describes a source routing instruction which works across both IPv4
	routing instruction which works across both IPv4 and IPv6 underlays		and IPv6 underlays in addition to the MPLS underlay. As shown in
	in addition to the MPLS underlay. As shown in Figure 3, if there is		Figure 3, if there is no MPLS LSP towards the next node segment
	no MPLS LSP towards the next node segment (i.e., the next SFF		(i.e., the next SFF identified by the current top label), the
	identified by the current top label), the corresponding IP-based		corresponding IP-based tunnel for MPLS (e.g., MPLS-in-IP/GRE tunnel
	tunnel for MPLS (e.g., MPLS-in-IP/GRE tunnel [RFC4023], MPLS-in-UDP		[RFC4023], MPLS-in-UDP tunnel [RFC7510] or MPLS-in-L2TPv3 tunnel
	tunnel [RFC7510] or MPLS-in-L2TPv3 tunnel [RFC4817]) would be used.		[RFC4817]) would be used.
	+-----------------------------------------------------+		+-----------------------------------------------------+
	| IP network |		| IP network |
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| | SF1 | | SF2 | |		| | SF1 | | SF2 | |
	| +----+----+ +----+----+ |		| +----+----+ +----+----+ |
	| +---------+ | | +---------+ |		| +---------+ | | +---------+ |
	| | L(SFF2) | | | | L(T) | |		| | S(SFF2) | | | | S(T) | |
	| +---------+ | | +---------+ |		| +---------+ | | +---------+ |
	| | L(SF2) | | | |Inner pkt| |		| | S(SF2) | | | |Inner pkt| |
	| +---------+ | | +---------+ |		| +---------+ | | +---------+ |
	| | L(T) | | | |		| | S(T) | | | |
	| +---------+ | ^ | | |		| +---------+ | ^ | | |
	| |Inner pkt| ^ | | | | | |		| |Inner pkt| ^ | | | | | |
	| +---------+ | | | (5)| | |(6) |		| +---------+ | | | (5)| | |(6) |
	| (2)| | |(3) | | V |		| (2)| | |(3) | | V |
	| (1) | | V (4) | (7) |		| (1) | | V (4) | (7) |
	+----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+		+----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+
	| Head-end +------+ SFF1 +-------+ SFF2 +-------+ Tail-end |		| Head-end +------+ SFF1 +-------+ SFF2 +-------+ Tail-end |
	+----------+ +---------+ +---------+ +----+-----+		+----------+ +---------+ +---------+ +----+-----+
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| |IP Tunnel| |IP Tunnel| +---------+ |		| |IP Tunnel| |IP Tunnel| +---------+ |
	| |to SFF1 | | to SFF2 | | L(T) | |		| |to SFF1 | | to SFF2 | | S(T) | |
	| +---------+ +---------+ +---------+ |		| +---------+ +---------+ +---------+ |
	| | L(SF1) | | L(SF2) | |Inner pkt| |		| | S(SF1) | | S(SF2) | |Inner pkt| |
	| +---------+ +---------+ +---------+ |		| +---------+ +---------+ +---------+ |
	| | L(SFF2) | | L(T) | |		| | S(SFF2) | | S(T) | |
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| | L(SF2) | |Inner pkt| |		| | S(SF2) | |Inner pkt| |
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| | L(T) | |		| | S(T) | |
	| +---------+ |		| +---------+ |
	| |Inner pkt| |		| |Inner pkt| |
	| +---------+ |		| +---------+ |
	+-----------------------------------------------------+		+-----------------------------------------------------+
	Figure 3: Packet walk in IP underlay		Figure 3: Packet walk in IP underlay
	Since the transport (i.e., the underlay) could be IPv4, IPv6 or even		Since the transport (i.e., the underlay) could be IPv4, IPv6 or even
	MPLS networks, the above approach of encoding the SFP information by		MPLS networks, the above approach of encoding the SFP information by
	an MPLS label stack is fully transport-independent which is one of		an MPLS label stack is fully transport-independent which is one of
	skipping to change at page 12, line 12 ¶		skipping to change at page 12, line 12 ¶
	this packet into the appropriate SR policy as described in		this packet into the appropriate SR policy as described in
	[I-D.filsfils-spring-segment-routing-policy]. This results in the		[I-D.filsfils-spring-segment-routing-policy]. This results in the
	packet being encapsulated with an MPLS label stack containing the		packet being encapsulated with an MPLS label stack containing the
	segment list <SF1, SF2, T>, which encodes that SFC. Those SF labels		segment list <SF1, SF2, T>, which encodes that SFC. Those SF labels
	MUST be domain-wide unique MPLS labels. Since it is known to the		MUST be domain-wide unique MPLS labels. Since it is known to the
	service classifier that SFF1 is attached with an instance of SF1, the		service classifier that SFF1 is attached with an instance of SF1, the
	service classifier would therefore send the MPLS encapsulated packet		service classifier would therefore send the MPLS encapsulated packet
	through either an MPLS LSP tunnel or an IP-based tunnel towards SFF1		through either an MPLS LSP tunnel or an IP-based tunnel towards SFF1
	(as shown in Figure 4 and Figure 5 respectively). When the MPLS		(as shown in Figure 4 and Figure 5 respectively). When the MPLS
	encapsulated packet arrives at SFF1, SFF1 would know which SF should		encapsulated packet arrives at SFF1, SFF1 would know which SF should
	be performed according to the current top label (i.e., L(SF1)).		be performed according to the current top label (i.e., S(SF1)).
	Similarly, SFF1 would send the packet returned from SF1 to SFF2		Similarly, SFF1 would send the packet returned from SF1 to SFF2
	through either an MPLS LSP tunnel or an IP-based tunnel towards SFF2		through either an MPLS LSP tunnel or an IP-based tunnel towards SFF2
	since it's known to SFF1 that SFF2 is attached with an instance of		since it's known to SFF1 that SFF2 is attached with an instance of
	SF2. When the encapsulated packet arrives at SFF2, SFF2 would do the		SF2. When the encapsulated packet arrives at SFF2, SFF2 would do the
	similar action as what has been done by SFF1. Since the transport		similar action as what has been done by SFF1. Since the transport
	(i.e., the underlay) could be IPv4, IPv6 or even MPLS networks, the		(i.e., the underlay) could be IPv4, IPv6 or even MPLS networks, the
	above approach of encoding the SFC information by an MPLS label stack		above approach of encoding the SFC information by an MPLS label stack
	is fully transport-independent which is one of the major requirements		is fully transport-independent which is one of the major requirements
	for the SFC encapsulation [RFC7665].		for the SFC encapsulation [RFC7665].
	+-----------------------------------------------------+		+-----------------------------------------------------+
	| MPLS Network |		| MPLS Network |
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| | SF1 | | SF2 | |		| | SF1 | | SF2 | |
	| +----+----+ +----+----+ |		| +----+----+ +----+----+ |
	| +---------+ | | +---------+ |		| +---------+ | | +---------+ |
	| | L(SF2) | | | | L(T) | |		| | S(SF2) | | | | S(T) | |
	| +---------+ | | +---------+ |		| +---------+ | | +---------+ |
	| | L(T) | | | |Inner pkt| |		| | S(T) | | | |Inner pkt| |
	| +---------+ | ^ | | +---------+ |		| +---------+ | ^ | | +---------+ |
	| |Inner pkt| ^ | | | | | |		| |Inner pkt| ^ | | | | | |
	| +---------+ | | | (5)| | |(6) |		| +---------+ | | | (5)| | |(6) |
	| (2)| | |(3) | | V |		| (2)| | |(3) | | V |
	| (1) | | V (4) | (7) |		| (1) | | V (4) | (7) |
	+----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+		+----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+
	| Head-end +------+ SFF1 +-------+ SFF2 +-------+ Tail-end |		| Head-end +------+ SFF1 +-------+ SFF2 +-------+ Tail-end |
	+----------+ +---------+ +---------+ +----+-----+		+----------+ +---------+ +---------+ +----+-----+
	| +---------+ +---------+ +---------+ |		| +---------+ +---------+ +---------+ |
	| | L(SFF1) | | L(SFF2) | | L(T) | |		| | S(SFF1) | | S(SFF2) | | S(T) | |
	| +---------+ +---------+ +---------+ |		| +---------+ +---------+ +---------+ |
	| | L(SF1) | | L(SF2) | |Inner pkt| |		| | S(SF1) | | S(SF2) | |Inner pkt| |
	| +---------+ +---------+ +---------+ |		| +---------+ +---------+ +---------+ |
	| | L(SF2) | | L(T) | |		| | S(SF2) | | S(T) | |
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| | L(T) | |Inner pkt| |		| | S(T) | |Inner pkt| |
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| |Inner pkt| |		| |Inner pkt| |
	| +---------+ |		| +---------+ |
	+-----------------------------------------------------+		+-----------------------------------------------------+
	Figure 4: Packet walk in MPLS underlay		Figure 4: Packet walk in MPLS underlay
	+-----------------------------------------------------+		+-----------------------------------------------------+
	| IP Network |		| IP Network |
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| | SF1 | | SF2 | |		| | SF1 | | SF2 | |
	| +----+----+ +----+----+ |		| +----+----+ +----+----+ |
	| +---------+ | | +---------+ |		| +---------+ | | +---------+ |
	| | L(SF2) | | | | L(T) | |		| | S(SF2) | | | | S(T) | |
	| +---------+ | | +---------+ |		| +---------+ | | +---------+ |
	| | L(T) | | | |Inner pkt| |		| | S(T) | | | |Inner pkt| |
	| +---------+ | ^ | | +---------+ |		| +---------+ | ^ | | +---------+ |
	| |Inner pkt| ^ | | | | | |		| |Inner pkt| ^ | | | | | |
	| +---------+ | | | (5)| | |(6) |		| +---------+ | | | (5)| | |(6) |
	| (2)| | |(3) | | V |		| (2)| | |(3) | | V |
	| (1) | | V (4) | (7) |		| (1) | | V (4) | (7) |
	+----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+		+----+-----+ ---> +----+----+ ----> +----+----+ ---> +----+-----+
	| Head-end +------+ SFF1 +-------+ SFF2 +-------+ Tail-end |		| Head-end +------+ SFF1 +-------+ SFF2 +-------+ Tail-end |
	+----------+ +---------+ +---------+ +----+-----+		+----------+ +---------+ +---------+ +----+-----+
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| |IP Tunnel| |IP Tunnel| +---------+ |		| |IP Tunnel| |IP Tunnel| +---------+ |
	| |to SFF1 | | to SFF2 | | L(T) | |		| |to SFF1 | | to SFF2 | | S(T) | |
	| +---------+ +---------+ +---------+ |		| +---------+ +---------+ +---------+ |
	| | L(SF1) | | L(SF2) | |Inner pkt| |		| | S(SF1) | | S(SF2) | |Inner pkt| |
	| +---------+ +---------+ +---------+ |		| +---------+ +---------+ +---------+ |
	| | L(SF2) | | L(T) | |		| | S(SF2) | | S(T) | |
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| | L(T) | |Inner pkt| |		| | S(T) | |Inner pkt| |
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| |Inner pkt| |		| |Inner pkt| |
	| +---------+ |		| +---------+ |
	+-----------------------------------------------------+		+-----------------------------------------------------+
	Figure 5: Packet walk in IP underlay		Figure 5: Packet walk in IP underlay
	5.2. SRv6 data plane		5.2. SRv6 data plane
	5.2.1. Encoding SFP Information by an SRv6 SRH		5.2.1. Encoding SFP Information by an SRv6 SRH
	skipping to change at page 18, line 7 ¶		skipping to change at page 18, line 7 ¶
	packet reaches the SF (MPLS PHP, SRv6 End.D or PSP).		packet reaches the SF (MPLS PHP, SRv6 End.D or PSP).
	As illustrated on Figure 8, the generic behavior of an SR proxy has		As illustrated on Figure 8, the generic behavior of an SR proxy has
	two parts. The first part is in charge of passing traffic from the		two parts. The first part is in charge of passing traffic from the
	network to the SF. It intercepts the SR traffic destined for the SF		network to the SF. It intercepts the SR traffic destined for the SF
	via a locally instantiated service segment, modifies it in such a way		via a locally instantiated service segment, modifies it in such a way
	that it appears as non-SR traffic to the SF, then sends it out on a		that it appears as non-SR traffic to the SF, then sends it out on a
	given interface, IFACE-OUT, connected to the SF. The second part		given interface, IFACE-OUT, connected to the SF. The second part
	receives the traffic coming back from the SF on IFACE-IN, restores		receives the traffic coming back from the SF on IFACE-IN, restores
	the SR information and forwards it according to the next segment in		the SR information and forwards it according to the next segment in
	the list. Unless otherwise stated IFACE-OUT and IFACE-IN can		the list. IFACE-OUT and IFACE-IN are respectively the proxy
	represent the same interface.		interface used for sending traffic to the SF and the proxy interface
			that receives the traffic coming back from the SF. These can be
			physical interfaces or sub-interfaces (VLANs) and, unless otherwise
			stated, IFACE-OUT and IFACE-IN can represent the same interface.
	+----------------------------+		+----------------------------+
	| |		| |
	| Service Function |		| Service Function |
	| |		| |
	+----------------------------+		+----------------------------+
	^ Non SR |		^ Non SR |
	| traffic |		| traffic |
	| v		| v
	+-----------+----------+		+-----------+----------+
	+--| IFACE OUT : IFACE IN |--+		+--| IFACE OUT | IFACE IN |--+
	SR traffic | +-----------+----------+ | SR traffic		SR traffic | +-----------+----------+ | SR traffic
	---------->| SR proxy |---------->		---------->| SR proxy |---------->
	| |		| |
	+----------------------------+		+----------------------------+
	Figure 8: Generic SR proxy		Figure 8: Generic SR proxy
	In the next subsections, the following SR proxy mechanisms are		In the next subsections, the following SR proxy mechanisms are
	defined:		defined:
	skipping to change at page 25, line 35 ¶		skipping to change at page 25, line 35 ¶
	The cache entry is not mapped to any particular packet, but instead		The cache entry is not mapped to any particular packet, but instead
	to an SR SC policy identified by the receiving interface (IFACE-IN).		to an SR SC policy identified by the receiving interface (IFACE-IN).
	Any non-link-local IP packet or non-local Ethernet frame received on		Any non-link-local IP packet or non-local Ethernet frame received on
	that interface will be re-encapsulated with the cached headers as		that interface will be re-encapsulated with the cached headers as
	described in Section 6.1. The SF may thus drop, modify or generate		described in Section 6.1. The SF may thus drop, modify or generate
	new packets without affecting the proxy.		new packets without affecting the proxy.
	6.2.1. SR-MPLS pseudocode		6.2.1. SR-MPLS pseudocode
	The static proxy SR-MPLS pseudocode is augmented by inserting the		The dynamic proxy SR-MPLS pseudocode is obtained by inserting the
	following instructions between lines 1 and 2.		following instructions between lines 1 and 2 of the static SR-MPLS
			pseudocode.
	1. IF top label S bit is 0 THEN		1. IF top label S bit is 0 THEN
	2. Pop top label		2. Pop top label
	3. IF C(IFACE-IN) different from remaining labels THEN ;; Ref1		3. IF C(IFACE-IN) different from remaining labels THEN ;; Ref1
	4. Copy all remaining labels into C(IFACE-IN) ;; Ref2		4. Copy all remaining labels into C(IFACE-IN) ;; Ref2
	5. ELSE		5. ELSE
	6. Drop the packet		6. Drop the packet
	Ref1: A TTL margin can be configured for the top label stack entry to		Ref1: A TTL margin can be configured for the top label stack entry to
	prevent constant cache updates when multiple equal-cost paths with		prevent constant cache updates when multiple equal-cost paths with
	skipping to change at page 26, line 13 ¶		skipping to change at page 26, line 16 ¶
	dynamic SR proxy segment. It is identified with IFACE-IN in order to		dynamic SR proxy segment. It is identified with IFACE-IN in order to
	efficiently retrieve the right SR information when a packet arrives		efficiently retrieve the right SR information when a packet arrives
	on this interface.		on this interface.
	In addition, the inbound policy should check that C(IFACE-IN) has		In addition, the inbound policy should check that C(IFACE-IN) has
	been defined before attempting to restore the MPLS label stack, and		been defined before attempting to restore the MPLS label stack, and
	drop the packet otherwise.		drop the packet otherwise.
	6.2.2. SRv6 pseudocode		6.2.2. SRv6 pseudocode
	The static proxy SRv6 pseudocode is augmented by inserting the		The dynamic proxy SRv6 pseudocode is obtained by inserting the
	following instructions between lines 1 and 2.		following instructions between lines 1 and 2 of the static proxy SRv6
			pseudocode.
	1. IF NH=SRH & SL > 0 THEN		1. IF NH=SRH & SL > 0 THEN
	2. Decrement SL and update the IPv6 DA with SRH[SL]		2. Decrement SL and update the IPv6 DA with SRH[SL]
	3. IF C(IFACE-IN) different from IPv6 encaps THEN ;; Ref1		3. IF C(IFACE-IN) different from IPv6 encaps THEN ;; Ref1
	4. Copy the IPv6 encaps into C(IFACE-IN) ;; Ref2		4. Copy the IPv6 encaps into C(IFACE-IN) ;; Ref2
	5. ELSE		5. ELSE
	6. Drop the packet		6. Drop the packet
	Ref1: "IPv6 encaps" represents the IPv6 header and any attached		Ref1: "IPv6 encaps" represents the IPv6 header and any attached
	extension header.		extension header.
	skipping to change at page 30, line 17 ¶		skipping to change at page 30, line 17 ¶
	SRH.		SRH.
	Metadata imposition and handling will be further discussed in a		Metadata imposition and handling will be further discussed in a
	future version of this document.		future version of this document.
	7.2.2. SRH tag		7.2.2. SRH tag
	The SRH tag identifies a packet as part of a group or class of		The SRH tag identifies a packet as part of a group or class of
	packets [I-D.ietf-6man-segment-routing-header].		packets [I-D.ietf-6man-segment-routing-header].
	In an SFC context, this field can be used as a simple man's metadata		In an SFC context, this field can be used to encode basic metadata in
	to encode additional information in the SRH.		the SRH.
	8. Implementation status		8. Implementation status
	The static SR proxy is available for SR-MPLS and SRv6 on various		The static SR proxy is available for SR-MPLS and SRv6 on various
	Cisco hardware and software platforms. Furthermore, the following		Cisco hardware and software platforms. Furthermore, the following
	proxies are available on open-source software.		proxies are available on open-source software.
	+-------------+-------------+		+-------------+-------------+
	| VPP | Linux |		| VPP | Linux |
	+---+-----------------------------------+-------------+-------------+		+---+-----------------------------------+-------------+-------------+
	skipping to change at page 31, line 16 ¶		skipping to change at page 31, line 16 ¶
	The Segment Routing solution addresses a wide problem that covers		The Segment Routing solution addresses a wide problem that covers
	both topological and service chaining policies. The topological and		both topological and service chaining policies. The topological and
	service instructions can be either deployed in isolation or in		service instructions can be either deployed in isolation or in
	combination. SR has thus a wider applicability than the architecture		combination. SR has thus a wider applicability than the architecture
	defined in [RFC7665]. Furthermore, the inherent property of SR is a		defined in [RFC7665]. Furthermore, the inherent property of SR is a
	stateless network fabric. In SR, there is no state within the fabric		stateless network fabric. In SR, there is no state within the fabric
	to recognize a flow and associate it with a policy. State is only		to recognize a flow and associate it with a policy. State is only
	present at the ingress edge of the SR domain, where the policy is		present at the ingress edge of the SR domain, where the policy is
	encoded into the packets. This is completely different from other		encoded into the packets. This is completely different from other
	proposals such as [I-D.ietf-sfc-nsh] and the MPLS label swapping		proposals such as [RFC8300] and the MPLS label swapping mechanism
	mechanism described in [I-D.farrel-mpls-sfc], which rely on state		described in [I-D.farrel-mpls-sfc], which rely on state configured at
	configured at every hop of the service chain.		every hop of the service chain.
	10. IANA Considerations		10. IANA Considerations
	This document has no actions for IANA.		This I-D requests the IANA to allocate, within the "SRv6 Endpoint
			Types" sub-registry belonging to the top-level "Segment-routing with
			IPv6 dataplane (SRv6) Parameters" registry, the following
			allocations:
			+-------------+-----+-----------------------------------+-----------+
			| Value/Range | Hex | Endpoint function | Reference |
			+-------------+-----+-----------------------------------+-----------+
			| TBA | TBA | End.AN - SR-aware function | [This.ID] |
			| | | (native) | |
			| TBA | TBA | End.AS - Static proxy | [This.ID] |
			| TBA | TBA | End.AD - Dynamic proxy | [This.ID] |
			| TBA | TBA | End.AM - Masquerading proxy | [This.ID] |
			+-------------+-----+-----------------------------------+-----------+
			Table 1: SRv6 SFC Endpoint Types
	11. Security Considerations		11. Security Considerations
	The security requirements and mechanisms described in		The security requirements and mechanisms described in
	[I-D.ietf-spring-segment-routing] and		[I-D.ietf-spring-segment-routing] and
	[I-D.ietf-6man-segment-routing-header] also apply to this document.		[I-D.ietf-6man-segment-routing-header] also apply to this document.
	Furthermore, it is fundamental to the SFC design that the classifier		Furthermore, it is fundamental to the SFC design that the classifier
	is a trusted resource which determines the processing that the packet		is a trusted resource which determines the processing that the packet
	will be subject to, including for example the firewall. Where an SF		will be subject to, including for example the firewall. Where an SF
	skipping to change at page 32, line 36 ¶		skipping to change at page 32, line 46 ¶
	Dawra, G., Filsfils, C., daniel.bernier@bell.ca, d.,		Dawra, G., Filsfils, C., daniel.bernier@bell.ca, d.,
	Uttaro, J., Decraene, B., Elmalky, H., Xu, X., Clad, F.,		Uttaro, J., Decraene, B., Elmalky, H., Xu, X., Clad, F.,
	and K. Talaulikar, "BGP Control Plane Extensions for		and K. Talaulikar, "BGP Control Plane Extensions for
	Segment Routing based Service Chaining", draft-dawra-idr-		Segment Routing based Service Chaining", draft-dawra-idr-
	bgp-sr-service-chaining-02 (work in progress), January		bgp-sr-service-chaining-02 (work in progress), January
	2018.		2018.
	[I-D.farrel-mpls-sfc]		[I-D.farrel-mpls-sfc]
	Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based		Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
	Forwarding Plane for Service Function Chaining", draft-		Forwarding Plane for Service Function Chaining", draft-
	farrel-mpls-sfc-02 (work in progress), October 2017.		farrel-mpls-sfc-04 (work in progress), March 2018.
	[I-D.filsfils-spring-segment-routing-policy]		[I-D.filsfils-spring-segment-routing-policy]
	Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad,		Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad,
	F., Talaulikar, K., Hegde, S., daniel.voyer@bell.ca, d.,		F., Talaulikar, K., Ali, Z., Hegde, S.,
	Lin, S., bogdanov@google.com, b., Horneffer, M.,		daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com,
	Steinberg, D., Decraene, B., Litkowski, S., and P. Mattes,		b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B.,
	"Segment Routing Policy for Traffic Engineering", draft-		Litkowski, S., and P. Mattes, "Segment Routing Policy for
	filsfils-spring-segment-routing-policy-04 (work in		Traffic Engineering", draft-filsfils-spring-segment-
	progress), December 2017.		routing-policy-05 (work in progress), February 2018.
	[I-D.filsfils-spring-srv6-network-programming]		[I-D.filsfils-spring-srv6-network-programming]
	Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d.,		Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d.,
	daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,		daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
	Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,		Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
	Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P.,		Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P.,
	Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W.,		Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W.,
	Bashandy, A., Raza, K., Dukes, D., Clad, F., and P.		Bashandy, A., Raza, K., Dukes, D., Clad, F., and P.
	Camarillo, "SRv6 Network Programming", draft-filsfils-		Camarillo, "SRv6 Network Programming", draft-filsfils-
	spring-srv6-network-programming-03 (work in progress),		spring-srv6-network-programming-03 (work in progress),
	December 2017.		December 2017.
	[I-D.ietf-6man-segment-routing-header]		[I-D.ietf-6man-segment-routing-header]
	Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B.,		Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
	daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d.,		Field, B., daniel.voyer@bell.ca, d.,
	Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi,		daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
	T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk,		Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
	"IPv6 Segment Routing Header (SRH)", draft-ietf-6man-		D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
	segment-routing-header-07 (work in progress), July 2017.		Header (SRH)", draft-ietf-6man-segment-routing-header-08
			(work in progress), January 2018.
	[I-D.ietf-sfc-nsh]
	Quinn, P., Elzur, U., and C. Pignataro, "Network Service
	Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress),
	November 2017.
	[I-D.ietf-spring-segment-routing]		[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,		Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing		Litkowski, S., and R. Shakir, "Segment Routing
	Architecture", draft-ietf-spring-segment-routing-14 (work		Architecture", draft-ietf-spring-segment-routing-15 (work
	in progress), December 2017.		in progress), January 2018.
	[I-D.ietf-spring-segment-routing-mpls]		[I-D.ietf-spring-segment-routing-mpls]
	Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,		Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing with MPLS		Litkowski, S., and R. Shakir, "Segment Routing with MPLS
	data plane", draft-ietf-spring-segment-routing-mpls-11		data plane", draft-ietf-spring-segment-routing-mpls-12
	(work in progress), October 2017.		(work in progress), February 2018.
	[I-D.xu-mpls-payload-protocol-identifier]		[I-D.xu-mpls-payload-protocol-identifier]
	Xu, X., Assarpour, H., and S. Ma, "MPLS Payload Protocol		Xu, X., Assarpour, H., and S. Ma, "MPLS Payload Protocol
	Identifier", draft-xu-mpls-payload-protocol-identifier-04		Identifier", draft-xu-mpls-payload-protocol-identifier-04
	(work in progress), January 2018.		(work in progress), January 2018.
	[I-D.xu-mpls-unified-source-routing-instruction]		[I-D.xu-mpls-sr-over-ip]
	Xu, X., Bashandy, A., Assarpour, H., Ma, S., Henderickx,		Xu, X., Bryant, S., Farrel, A., Bashandy, A., Henderickx,
	W., and J. Tantsura, "Unified Source Routing Instructions		W., and Z. Li, "SR-MPLS over IP", draft-xu-mpls-sr-over-
	using MPLS Label Stack", draft-xu-mpls-unified-source-		ip-00 (work in progress), February 2018.
	routing-instruction-04 (work in progress), September 2017.
	[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,		[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
	"Encapsulating MPLS in IP or Generic Routing Encapsulation		"Encapsulating MPLS in IP or Generic Routing Encapsulation
	(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,		(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
	<https://www.rfc-editor.org/info/rfc4023>.		<https://www.rfc-editor.org/info/rfc4023>.
	[RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and		[RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and
	J. Young, "Encapsulation of MPLS over Layer 2 Tunneling		J. Young, "Encapsulation of MPLS over Layer 2 Tunneling
	Protocol Version 3", RFC 4817, DOI 10.17487/RFC4817, March		Protocol Version 3", RFC 4817, DOI 10.17487/RFC4817, March
	2007, <https://www.rfc-editor.org/info/rfc4817>.		2007, <https://www.rfc-editor.org/info/rfc4817>.
	skipping to change at page 34, line 25 ¶		skipping to change at page 34, line 30 ¶
	[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,		[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
	"Encapsulating MPLS in UDP", RFC 7510,		"Encapsulating MPLS in UDP", RFC 7510,
	DOI 10.17487/RFC7510, April 2015,		DOI 10.17487/RFC7510, April 2015,
	<https://www.rfc-editor.org/info/rfc7510>.		<https://www.rfc-editor.org/info/rfc7510>.
	[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,
	<https://www.rfc-editor.org/info/rfc7665>.		<https://www.rfc-editor.org/info/rfc7665>.
			[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
			"Network Service Header (NSH)", RFC 8300,
			DOI 10.17487/RFC8300, January 2018,
			<https://www.rfc-editor.org/info/rfc8300>.
	Authors' Addresses		Authors' Addresses
	Francois Clad (editor)		Francois Clad (editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	France		France
	Email: fclad@cisco.com		Email: fclad@cisco.com
	Xiaohu Xu (editor)		Xiaohu Xu (editor)
	Huawei		Alibaba
	Email: xuxiaohu@huawei.com
			Email: xiaohu.xxh@alibaba-inc.com
	Clarence Filsfils		Clarence Filsfils
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Belgium		Belgium
	Email: cf@cisco.com		Email: cf@cisco.com
	Daniel Bernier		Daniel Bernier
	Bell Canada		Bell Canada
	Canada		Canada
	Email: daniel.bernier@bell.ca		Email: daniel.bernier@bell.ca
			Cheng Li
			Huawei
			Email: chengli13@huawei.com
	Bruno Decraene		Bruno Decraene
	Orange		Orange
	France		France
	Email: bruno.decraene@orange.com		Email: bruno.decraene@orange.com
	Shaowen Ma		Shaowen Ma
	Juniper		Juniper
	Email: mashaowen@gmail.com		Email: mashaowen@gmail.com
End of changes. 61 change blocks.
	94 lines changed or deleted		120 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/