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

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

Do you have proof about the optimization we get with MAC switching
versus MAC flushing?

________________________________

From: Jiang Yuan-long [mailto:[e-mail]] 
Sent: maandag 11 augustus 2008 11:34
To: HENDERICKX Wim
Cc: [e-mail]
Subject: Re: RE, and benefits of draft-jiang-l2vpn-vpls-mac-operation-00


Surely switching is another way of optimization, and no need to flush.


	----- Original Message ----- 
	From: HENDERICKX Wim <mailto:[e-mail]>  
	To: Jiang Yuan-long <mailto:[e-mail]>  
	Sent: Monday, August 11, 2008 4:55 PM
	Subject: RE: RE, and benefits of
draft-jiang-l2vpn-vpls-mac-operation-00

	Indeed, the difference is in what you signal a PW or a PE-ID. My
view is that draft-pdutta-l2vpn-vpls-ldp-mac-opt-03 covers everything we
need to optimize the flush behavior.
	 
	Do you agree on that or what is missing according to you?

________________________________

	From: Jiang Yuan-long [mailto:[e-mail]] 
	Sent: maandag 11 augustus 2008 10:46
	To: HENDERICKX Wim
	Subject: Re: RE, and benefits of
draft-jiang-l2vpn-vpls-mac-operation-00
	
	
	The difference is: 
	 
	In draft-pdutta-l2vpn-vpls-ldp-mac-opt-03, selectively flushing
MACs by carrying a unique PE-ID.
	 
	In draft-jiang-l2vpn-vpls-mac-operation-00, MAC switching by
carrying PW info.
	 
	Please see my last email for the benefits, if there is anything
you don't agree with me, please 
	point it out and give your reasons.
	 
	 

		----- Original Message ----- 
		From: HENDERICKX Wim
<mailto:[e-mail]>  
		To: [e-mail] 
		Cc: [e-mail] 
		Sent: Monday, August 11, 2008 4:18 PM
		Subject: Re: RE, and benefits of
draft-jiang-l2vpn-vpls-mac-operation-00


		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