Re: RE, and benefits of draft-jiang-l2vpn-vpls-mac-operation-00

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

Yanlong, my question is what is the difference between you draft and draft-pdutta-l2vpn-vpls-ldp-mac-opt-03? The function described are the same and I don't see the added value you bring with your draft.

Cheers,
Wim
_________________
sent from blackberry

----- Original Message -----
From: Jiang Yuan-long <[e-mail]>
To: HENDERICKX Wim
Cc: [e-mail] <[e-mail]>
Sent: Mon Aug 11 10:09:10 2008
Subject: Re: RE, and benefits of draft-jiang-l2vpn-vpls-mac-operation-00

Hi, Wim:
I am not sure what you mean by "This function is already proposed in  Draft-pdutta-l2vpn-vpls-ldp-mac-opt-03." 
If you mean "MAC switching" behavior, forgive me if I am not aware of it in the above draft.
Otherwise,if you mean the null-list of MACs,  it is RFC 4762 which first introduces such a kind of sub-TLV.
 
As to the benefits of draft-jiang-l2vpn-vpls-mac-operation-00, although I had analyzed them in the emails to this WG
mailing list several days ago, I would be more than willing to re-sumarize them here:
 
1. Faster convergence of topology, maybe more precisely, faster MAC learning compared with MAC flooding.
-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 as a result of MAC flooding may last for a rather long time.
 
With MAC switching, FIB can be established as fast as the MAC flushing operation itself:
In selective flushing as described in RFC 4762 or draft-pdutta-l2vpn-vpls-ldp-mac-opt-03,
the MAC flushing operation may be:
    Given PW1, for each item in the FIB, 
            if the item's outport is not the same as this PW, then flush it.
 
In MAC switching, as described in draft-jiang-l2vpn-vpls-mac-operation-00, the MAC switching on the FIB table: 
     Given PW1, PW2, for each item in the FIB, 
            if the item's outport is the same as PW1, then change it to PW2.
 
As the pseudocode shown above, MAC switching is no more complex than the selective MAC flushing.
Actually, with more accurate PW information, it is quite possible that less PWs will be involved in the data plane lookup.
 
2. Less flooding burst in the core. 
For the customer sites with hundreds or more of MACs, a lot of MAC learning will be needed, and for the customer site 
with few MACs but large bandwidth, although few MACs are flushed, but as the time for the responsive frame to arrive 
at the PEs where MACs are flushed is not trivial, the total frames flooded accross the core may be added to a high volume.
 
Optimized selecive flooding as described in Draft-pdutta-l2vpn-vpls-ldp-mac-opt-03 can alleviate the MAC learning and 
flooding problem to some degree, but not so completely, and it applies only to a certain hub-and-spoke network topology, 
if CE is dual-homed to the PEs by ACs, it will be out of the capability of this draft. While draft-jiang-l2vpn-vpls-mac-operation-00 
tries to eliminate the MAC leaning and subsequent flooding procedures due to PE or PW switching completely, and in a broader way.
 
Regards
Yuanlong
 

Snippet of your last email:

________________________________

			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