RE: RE:

["HENDERICKX Wim" <[e-mail]>]

Yuanlong, more in-line


________________________________

From: Jiang Yuan-long [mailto:[e-mail]] 
Sent: vrijdag 8 augustus 2008 11:06
To: HENDERICKX Wim
Cc: [e-mail]
Subject: Re: RE:


Hi，Wim，Please see my comments in line.

	----- Original Message ----- 
	From: HENDERICKX Wim <mailto:[e-mail]>  
	To: Jiang Yuan-long <mailto:[e-mail]>  
	Cc: [e-mail] 
	Sent: Friday, August 08, 2008 3:39 AM
	Subject: RE: RE:
	
	
	
	Yuanlong, see in-line

________________________________

	From: Jiang Yuan-long [mailto:[e-mail]] 
	Sent: donderdag 7 augustus 2008 9:31
	To: HENDERICKX Wim
	Cc: [e-mail]
	Subject: Re: RE:
	
	
	Wim:
	 
	In VPLS with dual-homed topology, we must pre-configure the working PE and backup PE to form a protection group, 
	such as described in ICCP (defined in draft-martini-pwe3-iccp-00), and pre-configure working PWs with their 
	respective backup PWs, as described in "PW redundancy"(draft-ietf-pwe3-redundancy-bit-00).
	Anyway, these configurations are prerequesite to provide sevice resiliency for VPLS, and the roles of the respective 
	PE or PW will change automatically after PE or PW switching (ie. backup PE becomes working PE, backup PW becomes 
	working PW).
	The mechanism in my draft is based on such a protection relationship of PEs and PWs, I am not sure what other 
	configurations need to be changed, can you give me some more clues?
	 
	WH> We don;t need any of this for PW resilience in VPLS according to me as PW status together with the existing MAC flushes do the job for these topologies.
	 
	Jiang: But how to set the exact PW status? When a CE is dual-homed to PEs by attached circuits, and if the working AC fails, 
	how do the PEs coordinate their PWs? IMHO, RFC 4762 is not perfect for these problems.  
	 
	Wh> The way it works is you use PW status as defined in the draft-muley-dutta-pwe3-redundancy-bit-02.txt and if the PW status changes you should perform a MAC flush in the full mesh VPLS domain.
	 
	RFC 4762 already provides some selective flushing mechansms, such as flushing some specified MACs or all MACs except 
	those associated with specific PWs. So what you mean may be that all the existing implementations only provide 
	flushing "all" MACs blindly in a VPLS instance, is that true? 
	 
	WH> There are certain cases where we need to extend them like for PBB where we have C-MAC ties to B-MACs.
	Jiang: As far as I know, nowadays even some enterprise-oriented routers can selectively flush MACs. 
	 
	WH> Isn't the main reason for this the fact that they can't handle large floods of traffic?  
	 
	As our anlysis and other sources(such as draft-pdutta-l2vpn-vpls-ldp-mac-opt-03) shows, blindly flushing adversely 
	impacts all sites in a VPLS instance, even their topology is not affected, the MACs must be re-leaned may be numerous,
	and the number of frames flooded may be not so small. Thus blindly flushing is unacceptable to a carrier grade VPLS 
	service,and for this reason we proposed some optimized MAC operations such as MAC Switching and MAC notification.
	 
	WH> The optimizations which are suggested in the mentioned drafts are very simple, whilst your proposal is fairly complex and depends on the topology you propose but might not be efficient in case we change the service topology.
	

	Jiang: The draft mentioned above also do selective flushing, not blind flushing. And for what I know, this very draft may depend 
	on the hub-and-spoke network topology while our draft seems to be capable of a broader application scenario such as a CE dual-homed 
	to PEs by ACs. The formats and contents of the LDP messages are similar in all these drafts or RFC for selective flushing, and as 
	my analysis goes, complexity (times of lookup and write) in dataplane may be commensurate for all these mechanisms.  
	 
	WH> Right but the main difference is that you only need to indicate the PE or PW for which the MAC flush is performed. In your proposal you need to indicate the full MAC address list which will be very processing intensive if you have a large amount of MAC addresses in the VPLS service. The message will get very big and you will have to sent lots of them due to fragmentation implications. 
	Draft-pdutta-l2vpn-vpls-ldp-mac-opt-03 provides a simple (blind was maybe the wrong wording) flush mechanism. The indication will be fast and the re-learning will happen instantly after the MAC is removed from the MAC FIB.
	 
	You proposal will delay the trigger when the amount of MAC @ grows and on top the receiving PE needs a fast lookup mechanism to find he proper MAC and replace it which means delay the removal of the FIB.
	 
	
	Best regards,
	 
	Yuanlong

		----- Original Message ----- 
		From: HENDERICKX Wim <mailto:[e-mail]>  
		To: Jiang Yuan-long <mailto:[e-mail]>  
		Cc: [e-mail] 
		Sent: Thursday, August 07, 2008 1:24 PM
		Subject: RE: RE:
		
		
		
		Yuanlong,
		 
		My point is that how are you going to define the behavior on each PE when the topology is adapted. I hope you are not going to change the configuration on each PE in the VPLS each time.
		 
		On top, by doing selective MAC flush you need to go one by one to the items and hence the processing to withdraw the MAC(s) will be longer. When you use the existing mechanisms you can flush without the extra lookups and hence the performance will be faster. FLushing a MAC will result in re-learning which means you do not have traffic impact, just a small flooding until the MAC address is re-learned.
		 
		Cheers,
		Wim
		
________________________________

		From: Jiang Yuan-long [mailto:[e-mail]] 
		Sent: donderdag 7 augustus 2008 6:00
		To: HENDERICKX Wim
		Cc: [e-mail]
		Subject: Re: RE:
		
		
		 
		Wim:
		 
		Thanks for you comment. My draft is not a standlone protocol, it can be deployed with other protocol suites.
		For what I know, "PW redundancy" is being standardized in PWE3 WG, which can synchronize the behavior of
		the PEs and PWs in PW switching. So it is not such a difficult task to do PW switching, and do MAC switching
		subsequently. 
		 
		The MAC withdrawal process defined in RFC 4762 is not so simple as you think, it maybe not just "flush all MACs" 
		blindly, but can selectively flush MACs, which computation comlexity is on the same level as my draft.

			----- Original Message ----- 
			From: HENDERICKX Wim <mailto:[e-mail]>  
			To: Jiang Yuan-long <mailto:[e-mail]>  ; [e-mail] 
			Cc: [e-mail] 
			Sent: Thursday, August 07, 2008 4:18 AM
			Subject: RE:

			Yuanlong,
			 
			The difficulty with your draft is that it requires a PE to do different things depending in which situation the PE is in, and this makes it very cumbersome in case changes happen to topologies or configurations.
			 
			My view is that we need a simple MAC flush which we have today in LDP.
			 
			Cheers,
			WIm

________________________________

			From: [e-mail] [mailto:[e-mail]] On Behalf Of Jiang Yuan-long
			Sent: woensdag 6 augustus 2008 11:30
			To: [e-mail]
			Cc: [e-mail]
			Subject: 
			
			
			Hi, Ali:
			 
			Thanks for your comments in the last L2VPN WG meeting, I will try to give you some reasons here.
			Following are the two questions:
			 
			1. What do you think will be faster convergence? When you flush MAC addresses, 
			the learning is done in data plane at wire speed. Why does that prolong convergence time?
			
			 
			-Faster convergence means the time to associate the MACs with the "exact" out port
			will be shorter. Though learning is done in data plane at wire speed, the time for a frame to arrive 
			at the end host and the response time for a host to send a reverse frame accross the PE (on which the 
			MACs is flushed) will be a rather long time. So the learning process is not only determined solely by 
			the wire speed, but also on the host processing time and delays on all the intermediate routers.
			For this reason, flooding may also last for a rather long time.
			 
			 
			2. You consider a simple case with simple backup for primary. In cases where primary fails and traffic gets
			 distributed among multiple PE's, how do you take care of that?
			 
			-I believe the most commonly deployed scenario is one backup PE for a primary PE.
			In my opinion, for the scenario of multiple backup PEs protecting a primary PE, 
			only one PE out of them will be elected as the working PE when the primary PE failed, 
			rather than distribute the traffic over multiple backup PEs,
			otherwise, loops may be introduced to the attached customer site.
			BTW, in a similar way, for PW redundancy mechanism, only 1 secondary is selected as the working PW (see 
			draft-ietf-pwe3-redundancy-bit-00.txt in PWE3 WG)
			Anyway, if there is any such requirements confirmed, I think it will be OK for us to find some solutions and 
			add them to the future drafts. 
			 
			cheers,
			Yuanlong