Subject: RE:

From: Jiang Yuan-long <[email-masked]>
Date: Wed, 06 Aug 2008 17:29:51 +0800

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

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Wed, 6 Aug 2008 22:18:41 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Jiang Yuan-long
Sent: woensdag 6 augustus 2008 11:30
To: [email-masked]
Cc: [email-masked]
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

---

From: Jiang Yuan-long <[email-masked]>
Date: Thu, 07 Aug 2008 12:00:05 +0800

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 
  To: Jiang Yuan-long ; [email-masked] 
  Cc: [email-masked] 
  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.

  Cheers,
  WIm

------------------------------------------------------------------------------
  From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiang Yuan-long
  Sent: woensdag 6 augustus 2008 11:30
  To: [email-masked]
  Cc: [email-masked]
  Subject: 

  Hi, Ali:

  cheers,
  Yuanlong

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Thu, 7 Aug 2008 07:24:47 +0200

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

	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: [email-masked] [mailto:[email-masked]] On
Behalf Of Jiang Yuan-long
	Sent: woensdag 6 augustus 2008 11:30
	To: [email-masked]
	Cc: [email-masked]
	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

---

From: Jiang Yuan-long <[email-masked]>
Date: Thu, 07 Aug 2008 15:31:25 +0800

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?

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?
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.

Best regards,

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

  Wim:

    ----- Original Message ----- 
    From: HENDERICKX Wim 
    To: Jiang Yuan-long ; [email-masked] 
    Cc: [email-masked] 
    Sent: Thursday, August 07, 2008 4:18 AM
    Subject: RE:

    Yuanlong,

    Cheers,
    WIm

----------------------------------------------------------------------------
    From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiang Yuan-long
    Sent: woensdag 6 augustus 2008 11:30
    To: [email-masked]
    Cc: [email-masked]
    Subject: 

    Hi, Ali:

    cheers,
    Yuanlong

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Thu, 7 Aug 2008 21:39:45 +0200

Yuanlong, see in-line

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.

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.
 
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.

Best regards,
 
Yuanlong

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

	 
	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:[email-masked]>  
		To: Jiang Yuan-long <mailto:[email-masked]>  ;
[email-masked] 
		Cc: [email-masked] 
		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: [email-masked]
[mailto:[email-masked]] On Behalf Of Jiang Yuan-long
		Sent: woensdag 6 augustus 2008 11:30
		To: [email-masked]
		Cc: [email-masked]
		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

---

From: Jiang Yuan-long <[email-masked]>
Date: Fri, 08 Aug 2008 17:05:33 +0800

Hi,Wim,Please see my comments in line.
  ----- Original Message ----- 
  From: HENDERICKX Wim 
  To: Jiang Yuan-long 
  Cc: [email-masked] 
  Sent: Friday, August 08, 2008 3:39 AM
  Subject: RE: RE:

  Yuanlong, see in-line

  Wim:

  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> 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> 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. 

  Best regards,

  Yuanlong
    ----- Original Message ----- 
    From: HENDERICKX Wim 
    To: Jiang Yuan-long 
    Cc: [email-masked] 
    Sent: Thursday, August 07, 2008 1:24 PM
    Subject: RE: RE:

    Yuanlong,

    Cheers,
    Wim

    Wim:

      ----- Original Message ----- 
      From: HENDERICKX Wim 
      To: Jiang Yuan-long ; [email-masked] 
      Cc: [email-masked] 
      Sent: Thursday, August 07, 2008 4:18 AM
      Subject: RE:

      Yuanlong,

      Cheers,
      WIm

--------------------------------------------------------------------------
      From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiang Yuan-long
      Sent: woensdag 6 augustus 2008 11:30
      To: [email-masked]
      Cc: [email-masked]
      Subject: 

      Hi, Ali:

      cheers,
      Yuanlong

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Sun, 10 Aug 2008 08:57:44 +0200

Yuanlong, more in-line

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

Hi，Wim，Please see my comments in line.

	----- Original Message ----- 
	From: HENDERICKX Wim <mailto:[email-masked]>  
	To: Jiang Yuan-long <mailto:[email-masked]>  
	Cc: [email-masked] 
	Sent: Friday, August 08, 2008 3:39 AM
	Subject: RE: RE:

	Yuanlong, see in-line

	Wim:

	 
	 
	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.

	 
	WH> Isn't the main reason for this the fact that they can't handle large floods of traffic?  

	 
	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:[email-masked]>  
		To: Jiang Yuan-long <mailto:[email-masked]>  
		Cc: [email-masked] 
		Sent: Thursday, August 07, 2008 1:24 PM
		Subject: RE: RE:

		Yuanlong,

		 
		Cheers,
		Wim

		 
		Wim:

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

			Yuanlong,

			 
			Cheers,
			WIm

			Hi, Ali:

			 
			 
			cheers,
			Yuanlong

---

From: Jiang Yuan-long <[email-masked]>
Date: Mon, 11 Aug 2008 10:27:02 +0800

Wim, please see more in-line.

Cheers
Yuanlong
  ----- Original Message ----- 
  From: HENDERICKX Wim 
  To: Jiang Yuan-long 
  Cc: [email-masked] 
  Sent: Sunday, August 10, 2008 2:57 PM
  Subject: RE: RE:

  Yuanlong, more in-line

    ----- Original Message ----- 
    From: HENDERICKX Wim 
    To: Jiang Yuan-long 
    Cc: [email-masked] 
    Sent: Friday, August 08, 2008 3:39 AM
    Subject: RE: RE:

    Yuanlong, see in-line

    Wim:

    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.

    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.

    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.

    Best regards,

    Yuanlong
      ----- Original Message ----- 
      From: HENDERICKX Wim 
      To: Jiang Yuan-long 
      Cc: [email-masked] 
      Sent: Thursday, August 07, 2008 1:24 PM
      Subject: RE: RE:

      Yuanlong,

      Cheers,
      Wim

      Wim:

        ----- Original Message ----- 
        From: HENDERICKX Wim 
        To: Jiang Yuan-long ; [email-masked] 
        Cc: [email-masked] 
        Sent: Thursday, August 07, 2008 4:18 AM
        Subject: RE:

        Yuanlong,

        Cheers,
        WIm

------------------------------------------------------------------------
        From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiang Yuan-long
        Sent: woensdag 6 augustus 2008 11:30
        To: [email-masked]
        Cc: [email-masked]
        Subject: 

        Hi, Ali:

        cheers,
        Yuanlong

---

From: Jiang Yuan-long <[email-masked]>
Date: Mon, 11 Aug 2008 16:09:10 +0800

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:

      Wim:

      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> 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: "HENDERICKX Wim" <[email-masked]>
Date: Mon, 11 Aug 2008 08:21:27 +0200

Yuanlong, more in-line.

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

Cheers
Yuanlong

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

	Yuanlong, more in-line

		----- Original Message ----- 
		From: HENDERICKX Wim <mailto:[email-masked]>  
		To: Jiang Yuan-long <mailto:[email-masked]>  
		Cc: [email-masked] 
		Sent: Friday, August 08, 2008 3:39 AM
		Subject: RE: RE:

		Yuanlong, see in-line

		Wim:

		 

		 

		 

		 

		 

		Best regards,
		 
		Yuanlong

			----- Original Message ----- 
			From: HENDERICKX Wim <mailto:[email-masked]>  
			To: Jiang Yuan-long <mailto:[email-masked]>  
			Cc: [email-masked] 
			Sent: Thursday, August 07, 2008 1:24 PM
			Subject: RE: RE:

			Yuanlong,

			 
			Cheers,
			Wim

			 
			Wim:

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

				Yuanlong,

				 
				Cheers,
				WIm

				Hi, Ali:

				 
				 
				cheers,
				Yuanlong