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

From: "HENDERICKX Wim" <[email-masked]>
Date: Mon, 11 Aug 2008 10:18:33 +0200

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 <[email-masked]>
To: HENDERICKX Wim
Cc: [email-masked] <[email-masked]>
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:[email-masked]] 
			Sent: donderdag 7 augustus 2008 9:31
			To: HENDERICKX Wim
			Cc: [email-masked]
			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

---

From: Jiang Yuan-long <[email-masked]>
Date: Mon, 11 Aug 2008 17:34:03 +0800

Re: RE, and benefits of draft-jiang-l2vpn-vpls-mac-operation-00Surely switching is another way of optimization, and no need to flush.

  ----- Original Message ----- 
  From: HENDERICKX Wim 
  To: Jiang Yuan-long 
  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:[email-masked]] 
  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 
    To: [email-masked] 
    Cc: [email-masked] 
    Sent: Monday, August 11, 2008 4:18 PM
    Subject: Re: RE, and benefits of draft-jiang-l2vpn-vpls-mac-operation-00

    Cheers,
    Wim
    _________________
    sent from blackberry

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

    Hi, Wim:

    Regards
    Yuanlong

                            Wim:

                            

                            

                            

                            

                            

                            Best regards,
                            
                            Yuanlong

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Mon, 11 Aug 2008 14:15:25 +0200

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

From: Jiang Yuan-long [mailto:[email-masked]] 
Sent: maandag 11 augustus 2008 11:34
To: HENDERICKX Wim
Cc: [email-masked]
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:[email-masked]>  
	To: Jiang Yuan-long <mailto:[email-masked]>  
	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.

	From: Jiang Yuan-long [mailto:[email-masked]] 
	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:[email-masked]>  
		To: [email-masked] 
		Cc: [email-masked] 
		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 <[email-masked]>
		To: HENDERICKX Wim
		Cc: [email-masked] <[email-masked]>
		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

		
		                        From: Jiang Yuan-long
[mailto:[email-masked]]
		                        Sent: donderdag 7 augustus 2008
9:31
		                        To: HENDERICKX Wim
		                        Cc: [email-masked]
		                        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