RE: RE:

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

Yuanlong, more in-line.

________________________________

From: Jiang Yuan-long [mailto:[e-mail]] 
Sent: maandag 11 augustus 2008 4:27
To: HENDERICKX Wim
Cc: [e-mail]
Subject: Re: RE:


Wim, please see more in-line.
 
Cheers
Yuanlong

	----- Original Message ----- 
	From: HENDERICKX Wim <mailto:[e-mail]>  
	To: Jiang Yuan-long <mailto:[e-mail]>  
	Cc: [e-mail] 
	Sent: Sunday, August 10, 2008 2:57 PM
	Subject: RE: RE:

	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> Your draft explains a solution with an MTU-s attached with PW. For this the MTU-s decides the PW status bit. In case of AC attached you need something like ICCP, but this is independent of RFC 4762. Based on the ICCP mechanism one of the AC(s) becomes active.
		 
		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.
		 
		Jiang: As the above mentioned draft indicates, pre-configuration of PWs is necessary for its working. The only difference is whether 
		we should perform MAC flushing or MAC switching when we do PW switching.
		I think blindly flushing, selectively flushing and its optimizations (see Dutta's draft), and the flush-free optimizations as I proposed, 
		should all be optional operations with their different applicability and efficiency. 
		For the case of PW switching in VPLS with redundancy, flush-free optimizations is more favorable to me.
		 
		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?  
		 
		Jiang: Selective flushing is an optional operation, not the only choice. If turning down the selecitve MAC flushing
		will improve the performance of a router, surely you can do that.
		 
		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.
		 
		Jiang: As indicated in our draft, MAC Switching message can also carry only a null-list of MACs. It's OK to change all the MACs associated with a PW 
		to another PW as egress. 
		 
		WH> This function is already proposed in  Draft-pdutta-l2vpn-vpls-ldp-mac-opt-03. Why do you think your solution is better?
		 
		
		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