< draft-ietf-trill-centralized-replication-02.txt		draft-ietf-trill-centralized-replication-03.txt >
	skipping to change at page 1, line 13 ¶		skipping to change at page 1, line 13 ¶
	INTERNET-DRAFT Y. Li		INTERNET-DRAFT Y. Li
	Intended Status: Standard Track Huawei Technologies		Intended Status: Standard Track Huawei Technologies
	M. Durrani		M. Durrani
	Cisco		Cisco
	S. Gupta		S. Gupta
	IP Infusion		IP Infusion
	A. Qu		A. Qu
	MediaTec		MediaTec
	T. Han		T. Han
	Huawei Technologies		Huawei Technologies
	Expires: October 2015 April 30, 2015		Expires: July 2016 November 09, 2015
	Centralized Replication for BUM traffic in active-active edge		Centralized Replication for BUM traffic in active-active edge
	connection		connection
	draft-ietf-trill-centralized-replication-02.txt		draft-ietf-trill-centralized-replication-03.txt
	Abstract		Abstract
	In TRILL active-active access scenario, RPF check failure issue may		In TRILL active-active access scenario, RPF check failure issue may
	occur when pseudo-nickname mechanism in [TRILLPN] is used. This		occur when pseudo-nickname mechanism in [TRILLPN] is used. This
	draft describes a solution to the RPF check failure issue through		draft describes a solution to resolve the RPF check failure issue
	centralized replication for BUM (Broadcast, Unknown unicast,		through centralized replication. The solution has all ingress RBs
	Mutlicast) traffic. The solution has all ingress RBs send BUM		send BUM(Broadcast, Unknown unicast, Mutlicast) traffic to a
	traffic to a centralized node via unicast TRILL encapsulation. When		centralized node via unicast TRILL encapsulation. When the
	the centralized node receives the BUM traffic, it decapsulates the		centralized node receives the BUM traffic, it decapsulates the
	traffic and forwards the BUM traffic to all destination RBs using a		traffic and forwards the BUM traffic to all destination RBs using a
	distribution tree established via the TRILL base protocol. To avoid		distribution tree established via the TRILL base protocol. To avoid
	RPF check failure on a RBridge sitting between the ingress RBridge		RPF check failure on a RBridge sitting between the ingress RBridge
	and the centralized replication node, some change of RPF calculation		and the centralized replication node, some change of RPF calculation
	algorithm is required. RPF calculation on each RBridge should use		algorithm is required. RPF calculation on each RBridge should use
	the centralized node as ingress RB instead of the real ingress		the centralized node as ingress RB instead of the real ingress
	RBridge of RBv to perform the calculation.		RBridge of RBv to perform the calculation.
	Status of this Memo		Status of this Memo
	skipping to change at page 2, line 39 ¶		skipping to change at page 2, line 39 ¶
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with		carefully, as they describe your rights and restrictions with
	respect to this document. Code Components extracted from this		respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described in		document must include Simplified BSD License text as described in
	Section 4.e of the Trust Legal Provisions and are provided without		Section 4.e of the Trust Legal Provisions and are provided without
	warranty as described in the Simplified BSD License.		warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction ................................................ 3		1. Introduction ................................................ 3
	2. Conventions used in this document............................ 4		2. Conventions used in this document ............................ 4
	3. Centralized Replication Solution Overview.................... 4		3. Centralized Replication Solution Overview .................... 4
	4. Frame duplication from remote RB............................. 5		4. Frame duplication from remote RB ............................. 5
	5. Local forwarding behavior on ingress RBridge................. 6		5. Local forwarding behavior on ingress RBridge ................. 6
	6. Loop prevention among RBridges in a edge group............... 7		6. Loop prevention among RBridges in a edge group ............... 7
	7. Centralized replication forwarding process................... 8		7. Centralized replication forwarding process ................... 8
	8. BUM traffic loadbalancing among multiple centralized nodes....9		8. BUM traffic loadbalancing among multiple centralized nodes.... 9
	9. Co-existing with CMT solution............................... 10		9. Co-existing with CMT solution ............................... 10
	10. Network Migration Analysis................................. 11		10. Network Migration Analysis ................................. 11
	11. TRILL protocol extension................................... 11		11. TRILL protocol extension ................................... 11
	11.1. "R" and "C" Flag in Nickname Flags APPsub-TLV..........11		11.1. "R" and "C" Flag in Nickname Flags APPsub-TLV.......... 11
	12. Security Considerations.................................... 12		12. Security Considerations .................................... 12
	13. IANA Considerations........................................ 12		13. IANA Considerations ........................................ 12
	14. References ................................................ 12		14. References ................................................ 12
	14.1. Normative References ..................................12		14.1. Normative References .................................. 12
	14.2. Informative References ................................12		14.2. Informative References ................................ 12
	15. Acknowledgments ........................................... 13		15. Acknowledgments ........................................... 13
	1. Introduction		1. Introduction
	The IETF TRILL (Transparent Interconnection of Lots of Links)		The IETF TRILL (Transparent Interconnection of Lots of Links)
	[RFC6325] protocol provides loop free and per hop based multipath		[RFC6325] protocol provides loop free and per hop based multipath
	data forwarding with minimum configuration. TRILL uses IS-IS		data forwarding with minimum configuration. TRILL uses IS-IS
	[RFC6165] [RFC6326bis] as its control plane routing protocol and		[RFC6165] [RFC6326bis] as its control plane routing protocol and
	defines a TRILL specific header for user data.		defines a TRILL specific header for user data.
	Classic Ethernet device (CE) devices typically are multi-homed to		Classic Ethernet device (CE) devices typically are multi-homed to
	skipping to change at page 3, line 41 ¶		skipping to change at page 3, line 41 ¶
	In active-active access scenario, pseudo-nickname solution in		In active-active access scenario, pseudo-nickname solution in
	[TRILLPN] can be used to avoid MAC flip-flop on remote RBs. The		[TRILLPN] can be used to avoid MAC flip-flop on remote RBs. The
	basic idea is to use a virtual RBridge of RBv with a single pseudo-		basic idea is to use a virtual RBridge of RBv with a single pseudo-
	nickname to represent an edge group that MC-LAG connects to. Any		nickname to represent an edge group that MC-LAG connects to. Any
	member RBridge of that edge group should use this pseudo-nickname		member RBridge of that edge group should use this pseudo-nickname
	rather than its own nickname as ingress nickname when it injects		rather than its own nickname as ingress nickname when it injects
	TRILL data frames to TRILL campus. The use of the nickname solves		TRILL data frames to TRILL campus. The use of the nickname solves
	the address flip flop issue by making the MAC address learnt by the		the address flip flop issue by making the MAC address learnt by the
	remote RBridge bound to pseudo-nickname. However, it introduces		remote RBridge bound to pseudo-nickname. However, it introduces
	another issue, which is incorrect packet drop by RPF check failure.		another issue of incorrect packet drop which will be described as
	When a pseudo-nickname is used by an edge RBridge as the ingress		follows. When a pseudo-nickname is used by an edge RBridge as the
	nickname to forward BUM traffic, any RBridges sitting between the		ingress nickname to forward BUM traffic, any RBridges sitting
	ingress RB and the distribution tree root will treat the traffic as		between the ingress RB and the distribution tree root will treat the
	it is ingressed from the virtual RBridge RBv. If same distribution		traffic as it is ingressed from the virtual RBridge RBv. If same
	tree is used by these different edge RBridges, the traffic may		distribution tree is used by these different edge RBridges, the
	arrive at RBn from different ports. Then the RPF check fails, and		traffic may arrive at RBn from different ports. Then the RPF check
	some of the traffic receiving from unexpected ports will be dropped		fails, and some of the traffic receiving from unexpected ports will
	by RBn.		be dropped by RBn.
	This document proposes a centralized replication solution for		This document proposes a centralized replication solution for
	broadcast, unknown unicast, multicast(BUM) traffic forwarding to		broadcast, unknown unicast, multicast(BUM) traffic forwarding to
	solve the issue of incorrect packet drop by RPF check failure. The		resolve the issue of incorrect packet drop incurred by RPF check
	basic idea is that all ingress RBs send BUM traffic to a centralized		failure. The basic idea is that all ingress RBs send BUM traffic to
	node which is recommended to be a distribution tree root using		a centralized node which is recommended to be a distribution tree
	unicast TRILL encapsulation. When the centralized node receives that		root using unicast TRILL encapsulation. When the centralized node
	traffic, it decapsulates it and then forwards the BUM traffic to all		receives that traffic, it decapsulates it and then forwards the BUM
	destination RBs using a distribution tree established per TRILL base		traffic to all destination RBs using a distribution tree established
	protocol.		per TRILL base protocol.
	2. Conventions used in this document		2. Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119		document are to be interpreted as described in RFC-2119
	[RFC2119].The acronyms and terminology in [RFC6325] is used herein		[RFC2119].The acronyms and terminology in [RFC6325] is used herein
	with the following additions:		with the following additions:
	BUM - Broadcast, Unknown unicast, and Multicast		BUM - Broadcast, Unknown unicast, and Multicast
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 43 ¶
	TRILL encapsulation to send the traffic to a centralized node. The		TRILL encapsulation to send the traffic to a centralized node. The
	centralized node is recommended to be a distribution tree root.		centralized node is recommended to be a distribution tree root.
	The TRILL header of the unicast TRILL encapsulation contains an		The TRILL header of the unicast TRILL encapsulation contains an
	"ingress RBridge nickname" field and an "egress RBridge nickname"		"ingress RBridge nickname" field and an "egress RBridge nickname"
	field. If ingress RB receives the traffic from the port which is in		field. If ingress RB receives the traffic from the port which is in
	a MC-LAG, it should set the ingress RBridge nickname to be the		a MC-LAG, it should set the ingress RBridge nickname to be the
	pseudo-nickname rather than its own nickname to avoid MAC flip-flop		pseudo-nickname rather than its own nickname to avoid MAC flip-flop
	on remote RBs as per [TRILLPN]. The egress RBridge nickname is set		on remote RBs as per [TRILLPN]. The egress RBridge nickname is set
	to the special nickname of the centralized node which is used to		to the special nickname of the centralized node which is used to
	differentiate the unicast TRILL encapsulation BUM traffic from		differentiate the centralized replication purpose unicast TRILL
	normal unicast TRILL traffic. The special nickname is called R-		encapsulation from normal unicast TRILL encapsulation. The special
	nickname.		nickname is called R-nickname.
	When the centralized node receives the unicast TRILL encapsulated		When the centralized node receives the unicast TRILL encapsulated
	BUM traffic from ingress RB, the node decapsulates the packet. Then		BUM traffic from ingress RB, the node decapsulates the packet. Then
	the centralized node replicates and forwards the BUM traffic to all		the centralized node replicates and forwards the BUM traffic to all
	destination RBs using one of the distribution trees established per		destination RBs using one of the distribution trees established per
	TRILL base protocol, if the centralized node is the root of a		TRILL base protocol, if the centralized node is the root of a
	distribution tree, the recommended distribution tree is the tree		distribution tree, the recommended distribution tree is the tree
	whose root is the centralized node itself. When the centralized node		whose root is the centralized node itself. When the centralized node
	forwards the BUM traffic, ingress nickname remains the same as that		forwards the BUM traffic, ingress nickname remains unchanged as that
	in frame it received to ensure that the MAC address learnt by all		in frame it received to ensure that the MAC address learnt by all
	egress RBridges bound to pseudo-nickname.		egress RBridges bound to pseudo-nickname.
	When the replicated traffic is forwarded on each RBridge along the		When the replicated traffic is forwarded on each RBridge along the
	distribution tree starting from the centralized node, RPF check will		distribution tree starting from the centralized node, RPF check will
	be performed as per RFC6325. For any RBridge sitting between the		be performed as per RFC6325. For any RBridge sitting between the
	ingress RBridge and the centralized replication node, the traffic		ingress RBridge and the centralized replication node, the traffic
	incoming port should be the centralized node facing port as the		incoming port should be the centralized node facing port as the
	multicast traffic always comes from the centralized node in this		multicast traffic always comes from the centralized node in this
	solution. However the RPF port as result of distribution tree		solution. However the RPF port as result of distribution tree
	calculation as per RFC 6325 will be the real ingress RB facing port		calculation as per RFC 6325 will be the real ingress RB facing port
	as it uses virtual RBridge as ingress RB, so RPF check will fail. To		as it uses virtual RBridge as ingress RB, so RPF check will fail. To
	solve this problem, some change of RPF calculation algorithm is		solve this problem, some change of RPF calculation algorithm is
	required. RPF calculation on each RBridge should use the centralized		required. RPF calculation on each RBridge should use the centralized
	node as ingress RB instead of the real ingress virtual RBridge to		node as ingress RB instead of the real ingress virtual RBridge to
	perform the calculation. As a result, RPF check will point to the		perform the calculation. As a result, RPF check will point to the
	centralized node facing port on the RBridge for multi-destination		centralized node facing port on the RBridge for multi-destination
	traffic. It prevents the incorrect frame discard by RPF check.		traffic. It prevents the incorrect frame discard by RPF check.
	To differentiate the unicast TRILL encapsulation BUM traffic from		To differentiate the centralized purpose unicast TRILL encapsulation
	normal unicast TRILL traffic on a centralized node, besides the		from normal unicast TRILL encapsulation on a centralized node,
	centralized node's own nickname, R-nickname should be introduced for		besides the centralized node's own nickname, R-nickname should be
	centralized replication. Only when the centralized node receives		introduced for centralized replication. Only when the centralized
	unicast TRILL encapsulation traffic with egress nickname equivalent		node receives unicast TRILL encapsulation traffic with egress
	to the R-nickname, the node does unicast TRILL decapsulaton and then		nickname equivalent to the R-nickname, the node does unicast TRILL
	forwards the traffic to all destination RBs through a distribution		decapsulaton and then forwards the traffic to all destination RBs
	tree. The centralized nodes should announce its R-nickname to all		through a distribution tree. The centralized nodes should announce
	TRILL campus through TRILL LSP extension.		its R-nickname to all TRILL campus through TRILL LSP extension.
	4. Frame duplication from remote RB		4. Frame duplication from remote RB
	Frame duplication may occur when a remote host sends multi-		Frame duplication may occur when a remote host sends multi-
	destination frame to a local CE which has an active-active		destination frame to a local CE which has an active-active
	connection to the TRILL campus. To avoid local CE receiving multiple		connection to the TRILL campus. To avoid local CE receiving multiple
	copies from a remote RBridge, the designated forwarder (DF)		copies from a remote RBridge, the designated forwarder (DF)
	mechanism should be supported for egress direction multicast traffic.		mechanism should be supported for egress direction multicast traffic.
	DF election mechanism allows only one port in one RB of MC-LAG to		DF election mechanism allows only one port in one RB of MC-LAG to
	forward multicast traffic from TRILL campus to local access side for		forward multicast traffic from TRILL campus to local access side for
	each VLAN. The basic idea of DF is to elect one RBridge per VLAN		each VLAN. The basic idea of DF is to elect one RBridge per VLAN
	from an edge group to be responsible for egressing the multicast		from an edge group to be responsible for egressing the multicast
	traffic. [draft-hao-trill-dup-avoidance-active-active-02] describes		traffic. [TRILLPN] describes the detail DF election mechanism among
	the detail DF mechanism and TRILL protocol extension for DF election.		member RBridges involving in a MC-LAG.
	If DF-election mechanism is used for frame duplication prevention,		If DF election mechanism is used for frame duplication prevention,
	access ports on an RB are categorized as three types: non mc-lag,		access ports on an RB are categorized as three types: non mc-lag,
	mc-lag DF port and mc-lag non-DF port. The last two types can be		mc-lag DF port and mc-lag non-DF port. The last two types can be
	called mc-lag port. For each of the mc-lag port, there is a pseudo-		called mc-lag port. For each of the mc-lag port, there is a pseudo-
	nickname associated. If consistent nickname allocation per edge		nickname associated. If consistent nickname allocation per edge
	group RBridges is used, it is possible that same pseudo-nickname		group RBridges is used, it is possible that same pseudo-nickname
	associated to more than one port on a single RB. A typical scenario		associated to more than one port on a single RB. A typical scenario
	is that CE1 is connected to RB1 & RB2 by mc-lag1 while CE2 is		is that CE1 is connected to RB1 & RB2 by mc-lag1 while CE2 is
	connected to RB1 & RB2 by mc-lag 2. In order to conserve the number		connected to RB1 & RB2 by mc-lag 2. In order to conserve the number
	of pseudo-nickname used, member ports for both mc-lag1 and mc-lag2		of pseudo-nickname used, member ports for both mc-lag1 and mc-lag2
	on RB1 & RB2 are all associated to pseudo-nickname pn1.		on RB1 & RB2 are all associated to pseudo-nickname pn1.
	5. Local forwarding behavior on ingress RBridge		5. Local forwarding behavior on ingress RBridge
	When a ingress RBridge(RB1) receives BUM traffic from an active-		When an ingress RBridge(RB1) receives BUM traffic from a local
	active accessing CE(CE1) device, the traffic will be injected to		active-active accessing CE(CE1) device, the traffic will be injected
	TRILL campus through TRILL encapsulation, and it will be replicated		to TRILL campus through TRILL encapsulation, and it will be
	and forwarded to all destination RBs which include ingress RB itself		replicated and forwarded to all destination RBs which include
	along a TRILL distribution tree. So the traffic will return to the		ingress RB itself along a TRILL distribution tree, the traffic will
	ingress RBridge. To avoid the traffic looping back to original		also return to the ingress RBridge. To avoid the traffic looping
	sender CE, ingress nickname can be used for traffic filtering.		back to original sender CE, ingress nickname of pseudo-nickname can
			be used for traffic filtering.
	If there are two local connecting CE(CE1 and CE2) devices on ingress		If there are two CEs of CE1 and CE2 connecting to the ingress RB1
	RB, the BUM traffic between these two CEs can't be forwarded locally		associated with same pseudo-nickname, CE1 needs to locally
	and through TRILL campus simultaneously, otherwise duplicated		replicates and forwards to CE2, because another copy of the BUM
	traffic will be received by destination CE. Local forwarding		traffic between CE1 and CE2 through TRILL campus will be blocked by
	behavior on ingress RBridge should be carefully designed.		the traffic filtering.
	To avoid duplicated traffic on receiver CE, local replication		If CE1 and CE2 are not associated with same pseudo-nickname, the
	behavior on RB1 is as follows:		copy of the BUM traffic between CE1 and CE2 through TRILL campus
			won't be blocked by the traffic filtering. To avoid duplicated
			traffic on receiver CE, the local replicated BUM traffic between
			these two CEs on ingress RB1 should be blocked.
			In summary, to ensure correct BUM traffic forwarding behavior for
			each CE, local replication behavior on ingress RBridge should be
			carefully designed as follows:
	1. Local replication to the ports associated with the same pseudo-		1. Local replication to the ports associated with the same pseudo-
	nickname as that associated to the incoming port.		nickname as that associated to the incoming port.
	2. Do not replicate to mc-lag port associated with different pseudo-		2. Do not replicate to mc-lag port associated with different pseudo-
	nickname.		nickname.
	3. Do not replicate to non mc-lag ports.		3. Do not replicate to non mc-lag ports.
	The above local forwarding behavior on the ingress RB of RB1 can be		The above local forwarding behavior on the ingress RB of RB1 can be
	skipping to change at page 7, line 49 ¶		skipping to change at page 8, line 9 ¶
	active access CEs as ingress nickname, egress RB can use the		active access CEs as ingress nickname, egress RB can use the
	nickname to filter traffic forwarding to all local CE. In this case,		nickname to filter traffic forwarding to all local CE. In this case,
	the traffic between these two CEs goes through local RB and another		the traffic between these two CEs goes through local RB and another
	copy of the traffic from TRILL campus is filtered. If different		copy of the traffic from TRILL campus is filtered. If different
	ingress nickname is used for two connecting CE devices, the access		ingress nickname is used for two connecting CE devices, the access
	ports connecting to these two CEs should be isolated with each other.		ports connecting to these two CEs should be isolated with each other.
	The BUM traffic between these two CEs should go through TRILL campus,		The BUM traffic between these two CEs should go through TRILL campus,
	otherwise the destination CE connected to same RB with the sender CE		otherwise the destination CE connected to same RB with the sender CE
	will receive two copies of the traffic.		will receive two copies of the traffic.
	Do note that the above sections on techniques to avoid frame
	duplication, loop prevention is applicable assuming the Link
	aggregation technology in use is unaware of the frame duplication
	happening. For example using mechanisms like IEEE802.1AX,
	Distributed Resilient Network Interconnect (DRNI) specs implements
	mechanism similar to DF and also avoids some cases of frame
	duplication & looping.
	7. Centralized replication forwarding process		7. Centralized replication forwarding process
	+-----------+		+-----------+
	| (RB5) |		| (RB5) |
	+-----------+		+-----------+
	|		|
	+-----------+		+-----------+
	| (RB4) |		| (RB4) |
	+-----------+		+-----------+
	skipping to change at page 12, line 41 ¶		skipping to change at page 12, line 41 ¶
	and A. Ghanwani, "TRILL Use of IS-IS", draft-eastlake-isis-		and A. Ghanwani, "TRILL Use of IS-IS", draft-eastlake-isis-
	rfc6326bis, work in progress.		rfc6326bis, work in progress.
	[4] [RFC7180bis] Eastlake, D., Zhang, M., Perlman, R., Banerjee, A.		[4] [RFC7180bis] Eastlake, D., Zhang, M., Perlman, R., Banerjee, A.
	Ghanwani and Gupta.S, "TRILL: Clarifications, Corrections, and		Ghanwani and Gupta.S, "TRILL: Clarifications, Corrections, and
	Updates", draft-ietf-trill-rfc7180bis-00, work in progress.		Updates", draft-ietf-trill-rfc7180bis-00, work in progress.
	14.2. Informative References		14.2. Informative References
	[1] [TRILLPN] Zhai,H., et.al., "RBridge: Pseduonode nickname",		[1] [TRILLPN] Zhai,H., et.al., "RBridge: Pseduonode nickname",
	draft-hu-trill-pseudonode-nickname, Work in progress, November		draft-hu-trill-pseudonode-nickname-07, Work in progress,
	2011.		November 2011.
	[2] [TRILAA] Li,Y., et.al., " Problem Statement and Goals for		[2] [TRILAA] Li,Y., et.al., " Problem Statement and Goals for
	Active-Active TRILL Edge", draft-ietf-trill-active-active-		Active-Active TRILL Edge", draft-ietf-trill-active-active-
	connection-prob-00, Work in progress, July 2013.		connection-prob-00, Work in progress, July 2013.
	[3] [CMT] Senevirathne, T., Pathangi, J., and J. Hudson,		[3] [CMT] Senevirathne, T., Pathangi, J., and J. Hudson,
	"Coordinated Multicast Trees (CMT)for TRILL", draft-ietf-		"Coordinated Multicast Trees (CMT)for TRILL", draft-ietf-
	trill-cmt-00.txt Work in Progress, April 2012.		trill-cmt-00.txt Work in Progress, April 2012.
	15. Acknowledgments		15. Acknowledgments
	The authors wish to acknowledge the important contributions of		The authors wish to acknowledge the important contributions of
	Hongjun Zhai, Xiaomin Wu, Liang Xia.		Russ White, Donald Eastlake, Hongjun Zhai, Xiaomin Wu, Liang Xia.
	Authors' Addresses		Authors' Addresses
	Weiguo Hao		Weiguo Hao
	Huawei Technologies		Huawei Technologies
	101 Software Avenue,		101 Software Avenue,
	Nanjing 210012		Nanjing 210012
	China		China
	Email: haoweiguo@huawei.com		Email: haoweiguo@huawei.com
	skipping to change at page 13, line 38 ¶		skipping to change at page 13, line 38 ¶
	Email: mdurrani@cisco.com		Email: mdurrani@cisco.com
	Sujay Gupta		Sujay Gupta
	IP Infusion		IP Infusion
	RMZ Centennial		RMZ Centennial
	Mahadevapura Post		Mahadevapura Post
	Bangalore - 560048		Bangalore - 560048
	India		India
	Email: sujay.gupta@ipinfusion.com		Email: sujay.gupta@ipinfusion.com
	Andrew Qu		Andrew Qu
	MediaTec		MediaTec
	Email: laodulaodu@gmail.com		Email: laodulaodu@gmail.com
	Tao Han		Tao Han
	Huawei Technologies		Huawei Technologies
	101 Software Avenue,		101 Software Avenue,
	Nanjing 210012		Nanjing 210012
	China		China
	Email: billow.han@huawei.com		Email: billow.han@huawei.com
End of changes. 18 change blocks.
	83 lines changed or deleted		83 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/