Subject: RE: VPLS question on MAC address withdrawal

From: "Dutta, Pranjal" <[email-masked]>
Date: Tue, 3 Jan 2006 13:53:09 +0530

Hi Himanshu,

                     Reg. the first part again excerpts from the draft
as below

For a MAC Address Withdraw message with empty list: 
     - Remove all the MAC addresses associated with the VPLS 
       instance(specified by the FEC TLV) except the MAC addresses 
       learned over the PW associated with this signaling session 
       over which the message was received 
   
  The scope of a MAC List TLV is the VPLS specified in the FEC TLV in 
  the MAC Address Withdraw Message.  The number of MAC addresses can 

  be deduced from the length field in the TLV

 In the first part as per my understanding goes, empty MAC list TLV
means delete the association between all MAC addresses associated with
the VPLS instance

specified in by the FEC TLV within the address withdraw message. This
will not delete the association of MACs with the PW on which the Address
Withdraw message with empty MAC list is received.

So as specified in draft the scope is limited to the FEC specified only.

The second issue you raised is very interesting and has practical
implications. After PW switchover when, MTU originates the Address
Withdraw for all N PWs (one msg. for each PW). Those will be forwarded
by the "new" PE-rs to all peers thoughout the domain. Removal of all
MACs would cause spark of broadcast and considering the traffic for all
N FECs are flowing now via secondary PW, so associated MACs will get
relearned again across all the PEs. So broadcast will stop once
relearning completes. In the absence of MAC withdraw, traffic won't
broadcast, but will keep flowing to wrong ports (till the MACs ages out
or till relearning happens again). I think we need to see the time
window for the broadcast in a specified scenario/application where MAC
withdraw is being used. That could be also one of the reasons why MAC
withdraw is an optional feature in VPLS.  

To address the broadcast issue when empty-list MAC withdraw is used, we
can implement some filtering mechanism to selectively block MAC withdraw
msg for some FECs at PE-rs/originating MTU (for PWs where temp. b'cast
is not desired due to MAC withdraw). Anyway that is my theoretical idea
and could be implementation specific.   

Regards,

Pranjal

________________________________

From: Shah, Himanshu [mailto:[email-masked]] 
Sent: Monday, 02 January, 2006 8:50 PM
To: Dutta, Pranjal; [email-masked]
Subject: RE: VPLS question on MAC address withdrawal

Hi Pranjal,

It seems easy to get confused that
mac address withdraw list TLV and empty mac address
withdraw list TLV are one and the same and can be used
interchangeably for scalability. But that is
clearly not true.

In MAC address withdraw list TLV with MAC addresses, receiver
removes the association between MAC addresses in
the list and PW over which the signal is received.

In MAC address TLV list with no MAC addresses,
the receiver removes the association between all MAC addresses
EXCEPT the ones over which he receives this signal.

In the second part of the question, empty MAC address
withdraw List TLV receieved by secondary which now is primary
PE-rs also has some issues. Broadcasting the empty MAC
address withdraw List TLV to all other PE-rs would create
broadcasts in the core, as it removes MAC addresses
learned from ALL N-PWs EXCEPT for ones learned on the
PW over which the signal was received.  This needs to be
carefully thought out too.

regards,
himanshu

-----Original Message-----
From: Dutta, Pranjal [mailto:[email-masked]]
Sent: Mon 1/2/2006 3:16 AM
To: Shah, Himanshu; [email-masked]
Subject: RE: VPLS question on MAC address withdrawal

Hi Himanshu,

                      Please see my answers inline

Thanks,

Pranjal

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Shah, Himanshu
Sent: Friday, 30 December, 2005 2:49 AM
To: [email-masked]
Subject: VPLS question on MAC address withdrawal

Hope somebody can shed light on the following questions....

(1)
There are two mechanisms described -
MAC address withdraw List TLV and empty MAC Address withdraw List TLV

cut-and-paste from draft.

6.2.2. Address Withdraw Message Containing MAC List TLV
 
  The processing for MAC List TLV received in an Address Withdraw
  Message is:
 
  For each MAC address in the TLV:
     - Remove the association between the MAC address and the AC or
        PW over which this message is received
 
  For a MAC Address Withdraw message with empty list:
     - Remove all the MAC addresses associated with the VPLS
        instance  (specified by the FEC TLV) except the MAC addresses
        learned over the PW associated with this signaling session
        over which the message was received
 
  The scope of a MAC List TLV is the VPLS specified in the FEC TLV in
  the MAC Address Withdraw Message.  The number of MAC addresses can
  be deduced from the length field in the TLV.

To simplify the problem, lets assume that for a given VPLS instance A
there are only 5 MAC
addresses and one PW. In this case, for TCN-Triggererd
MAC-address-withdrawal, sending
a list of 5 MAC address vs sending an empty list achieves opposite
result. That is, sending
explicit list will cause the receiver to remove all 5 addresses (lets
assume that they all were
associated with sender). But by sending, empty MAC-address-withdrawal
list, it will remove
none.  However, the draft says,

In order to minimize the impact on LDP convergence time, when the
  MAC list TLV contains a large number of MAC addresses, it may be
  preferable to send a MAC address withdrawal message with an empty
  list.

[Pranjal]: What the draft means is that with empty-list in MAC withdraw
TLV means remove "ALL" MACs.

              The processing entity of MAC List TLV (in Address Withdraw
Msg) needs to flush all MACs associated with a VPLS instance when it
receives MAC list TLV

                without any MAC address(s) in the list (empty list). In
case, of the MAC List TLV that contains specific MAC addresses then the
receiving

                entity needs to remove only those MAC addresses in the
list associated with VPLS instance (identifies by FEC in the address
withdraw msg). The withdrawl with empty list

                feature is to make it more scalable. For example, a VPLS
instance that has 1000 MACs learned at a PE need not send

                Address withdraw with 1000 MACs list, can send empty
list instead. But again it is optional (means if the MAC withdraw
originating PE wants

               It can send Address Withdraw with 1000 MACs list) and
implementation specific. Let's say for a dual homed MTU in HVPLS, the
primary link has 100 PWs

                (1 for each VPLS instance) and the secondary link has
the backup of all the 100 PWs. Now if all 100 primary PWs fail then, all
will switch back to the secondary and MTU

               needs to send Address Withdraw with MACList TLV, one for
each of the 100 PWs. So, empty list would be preferable for each
message.

(2)
Is MAC-Address-withdraw mechanism ever intended to be used for U-PW
(user facing PW, MTU-S<->PErs)?
If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to
U-PW, etc needs to
be described.

[Pranjal]: The draft says that the MAC withdraw originated at a MTU (in
MTU-PErs direction) needs to be processed and forwarded by PE-rs

to other PEs. The draft hasn't specified about propagating MAC withdraw
by PEs to the distant-end MTUs in HVPLS (in PErs->MTU direction). I
think

that part is implementation specific. The reason could be the distant
end MTUs will still be receiving the traffic in the primary link and MAC
withdrawl may not be necessary.

regards,
himanshu

Himanshu Shah
Ciena Corp

---

From: "Dutta, Pranjal" <[email-masked]>
Date: Wed, 4 Jan 2006 11:21:08 +0530

Hi Himanshu,

                      The problem you are referring to seems to be
different than the way I perceive it. With reference to your first
point, the effect of empty-list MAC withdraw is definitely different
than the MAC withdraw with specific MAC addresses. And both can't be
used interchangeably (means both will not have the same effect). Rather
I would say it's a tradeoff. In the example you provided in first mail
where originating MTU has 5 MACs then definitely it makes sense to send
a MAC withdraw with those 5 MAC addresses in MAC-list. If the number of
MACs learned at the MTU (where PW switchover has taken place) is
extremely large (lets say 5000) then sending Address Withdraw with
specific MAC list might get expensive and won't be scalable proposition.
Now instead when empty-list MAC list is sent it is going to delete the
all the "other" MACs (apart from the 5000 in the MTU that are actually
switched to secondary) which are learned at PE-rs(s) from "other" MTUs
in the VPLS instance. Ideally those MACs shouldn't have been disturbed.
So sending empty-list will globally affect all MACs on the VPLS
instance. I think as MAC withdraw is an optional feature, so
implementations need to take care of such tradeoffs.

Regards,

Pranjal    

From: Shah, Himanshu [mailto:[email-masked]] 
Sent: Tuesday, 03 January, 2006 7:54 PM
To: Dutta, Pranjal; [email-masked]
Subject: RE: VPLS question on MAC address withdrawal

Hi Pranjal,

I think there is a disconnect. You are failing to understand the point

I am raising.

I perfectly understand what empty MAC address withdraw list does. 

Please go through the example I gave. The example clearly shows that

MAC address withdraw list and empty MAC address withdraw list can

NOT be used interchangeably (for scalability or for other reasons).

As for the second part, the failover causes MAC switchover at the

expense of disturbance to other MAC conversations that had nothing

to do with the failover. It would almost seem that under such
circumstances

MAC Withdraw list with switchover MAC addresses from original primary

PE-rs to other PE-rs would make more sense than having to  make all the

PE-rs to remove all the MAC addresses (for a given VPLS instances) other
than

the ones switched over. Seems too expensive.

/himanshu

	-----Original Message-----
	From: Dutta, Pranjal [mailto:[email-masked]]
	Sent: Tuesday, January 03, 2006 3:23 AM
	To: Shah, Himanshu; [email-masked]
	Subject: RE: VPLS question on MAC address withdrawal

	Hi Himanshu,

	                     Reg. the first part again excerpts from the
draft as below

	For a MAC Address Withdraw message with empty list: 
	     - Remove all the MAC addresses associated with the VPLS 
	       instance(specified by the FEC TLV) except the MAC
addresses 
	       learned over the PW associated with this signaling
session 
	       over which the message was received 
	   
	  The scope of a MAC List TLV is the VPLS specified in the FEC
TLV in 
	  the MAC Address Withdraw Message.  The number of MAC addresses
can 

	 

	 In the first part as per my understanding goes, empty MAC list
TLV means delete the association between all MAC addresses associated
with the VPLS instance

	specified in by the FEC TLV within the address withdraw message.
This will not delete the association of MACs with the PW on which the
Address Withdraw message with empty MAC list is received.

	So as specified in draft the scope is limited to the FEC
specified only. 

	The second issue you raised is very interesting and has
practical implications. After PW switchover when, MTU originates the
Address Withdraw for all N PWs (one msg. for each PW). Those will be
forwarded by the "new" PE-rs to all peers thoughout the domain. Removal
of all MACs would cause spark of broadcast and considering the traffic
for all N FECs are flowing now via secondary PW, so associated MACs will
get relearned again across all the PEs. So broadcast will stop once
relearning completes. In the absence of MAC withdraw, traffic won't
broadcast, but will keep flowing to wrong ports (till the MACs ages out
or till relearning happens again). I think we need to see the time
window for the broadcast in a specified scenario/application where MAC
withdraw is being used. That could be also one of the reasons why MAC
withdraw is an optional feature in VPLS.  

	To address the broadcast issue when empty-list MAC withdraw is
used, we can implement some filtering mechanism to selectively block MAC
withdraw msg for some FECs at PE-rs/originating MTU (for PWs where temp.
b'cast is not desired due to MAC withdraw). Anyway that is my
theoretical idea and could be implementation specific.   

	Regards,

	Pranjal

	Hi Pranjal,

	

	regards,
	himanshu
	
	-----Original Message-----
	From: Dutta, Pranjal [mailto:[email-masked]]
	Sent: Mon 1/2/2006 3:16 AM
	To: Shah, Himanshu; [email-masked]
	Subject: RE: VPLS question on MAC address withdrawal
	
	Hi Himanshu,

	
	Thanks,
	
	Pranjal

	
	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Shah, Himanshu
	Sent: Friday, 30 December, 2005 2:49 AM
	To: [email-masked]
	Subject: VPLS question on MAC address withdrawal

	
	(1)
	There are two mechanisms described -
	MAC address withdraw List TLV and empty MAC Address withdraw
List TLV

	 
	  The processing for MAC List TLV received in an Address
Withdraw
	  Message is:
	 
	  For each MAC address in the TLV:
	     - Remove the association between the MAC address and the AC
or
	        PW over which this message is received
	 
	  For a MAC Address Withdraw message with empty list:
	     - Remove all the MAC addresses associated with the VPLS
	        instance  (specified by the FEC TLV) except the MAC
addresses
	        learned over the PW associated with this signaling
session
	        over which the message was received
	 
	  The scope of a MAC List TLV is the VPLS specified in the FEC
TLV in
	  the MAC Address Withdraw Message.  The number of MAC addresses
can
	  be deduced from the length field in the TLV.
	
	To simplify the problem, lets assume that for a given VPLS
instance A there are only 5 MAC
	addresses and one PW. In this case, for TCN-Triggererd
MAC-address-withdrawal, sending
	a list of 5 MAC address vs sending an empty list achieves
opposite result. That is, sending
	explicit list will cause the receiver to remove all 5 addresses
(lets assume that they all were
	associated with sender). But by sending, empty
MAC-address-withdrawal list, it will remove
	none.  However, the draft says,
	
	In order to minimize the impact on LDP convergence time, when
the
	  MAC list TLV contains a large number of MAC addresses, it may
be
	  preferable to send a MAC address withdrawal message with an
empty
	  list.
	
	[Pranjal]: What the draft means is that with empty-list in MAC
withdraw TLV means remove "ALL" MACs.
	
	              The processing entity of MAC List TLV (in Address
Withdraw Msg) needs to flush all MACs associated with a VPLS instance
when it receives MAC list TLV
	
	                without any MAC address(s) in the list (empty
list). In case, of the MAC List TLV that contains specific MAC addresses
then the receiving
	
	                entity needs to remove only those MAC addresses
in the list associated with VPLS instance (identifies by FEC in the
address withdraw msg). The withdrawl with empty list
	
	                feature is to make it more scalable. For
example, a VPLS instance that has 1000 MACs learned at a PE need not
send
	
	                Address withdraw with 1000 MACs list, can send
empty list instead. But again it is optional (means if the MAC withdraw
originating PE wants
	
	               It can send Address Withdraw with 1000 MACs list)
and implementation specific. Let's say for a dual homed MTU in HVPLS,
the primary link has 100 PWs
	
	                (1 for each VPLS instance) and the secondary
link has the backup of all the 100 PWs. Now if all 100 primary PWs fail
then, all will switch back to the secondary and MTU
	
	               needs to send Address Withdraw with MACList TLV,
one for each of the 100 PWs. So, empty list would be preferable for each
message.
	
	(2)
	Is MAC-Address-withdraw mechanism ever intended to be used for
U-PW (user facing PW, MTU-S<->PErs)?
	If so, how, when, implication of withdraw msg from N-PW
(PE<->PE) to U-PW, etc needs to
	be described.

	[Pranjal]: The draft says that the MAC withdraw originated at a
MTU (in MTU-PErs direction) needs to be processed and forwarded by PE-rs
	
	to other PEs. The draft hasn't specified about propagating MAC
withdraw by PEs to the distant-end MTUs in HVPLS (in PErs->MTU
direction). I think
	
	that part is implementation specific. The reason could be the
distant end MTUs will still be receiving the traffic in the primary link
and MAC withdrawl may not be necessary.
	
	regards,
	himanshu
	
	Himanshu Shah
	Ciena Corp

---

From: "Dutta, Pranjal" <[email-masked]>
Date: Wed, 4 Jan 2006 13:33:31 +0530

Hi Himanshu,

                      I think I am getting the point you are referring
to. In the first example, when we send Address Withdraw with 5 MAC list,
it is going to delete the association of the 5MACs from the PW on which
it is received. So, when the address withdraw is received at secondary
PE-rs over the secondary PW (after MTU switched over to secondary), it
might delete even the switched MACs if learnt already on the secondary
PW (Because for non-empty MAC list the draft doesn't put the rider on
deletion the MACs EXCEPT receiving PW). Propagation of the message to
other PE-rs(s) in the full mesh will delete the 5 MACs learned at the
respective PEs earlier (on the PW(s) from primary PE-rs).On that part I
don't see any problem. In case of Address Withdraw with empty MAC list,
the newly learned MACs on the secondary PW won't get deleted in case if
learnt already (as draft says EXCEPT on the receiving PW). But when it
is propagated by the secondary PE-rs to other PE-rs(s) , the receiver
will do two things. First, It will delete all the 5 MACs in respective
PE-rs(s) which were learnt earlier on PW(s) from primary PE-rs (The PW
on which the message is received, that is between secondary PE-rs is now
is different than the PW to primary PE-rs, so the EXCEPT condition
prevails here and newly learned MACs won't get deleted). Secondly, it
will also delete the "other MACs" learnt from "other" MTUs in the VPLS
instance which are not actually affected by the switchover on the MTU in
discussion. Again global deletion doesn't include the "other" MACs on
the PW on which the address withdraw is received and associated with
this signaling session (secondary PE-rs to other PE-rs(s) only). But I
am failing to understand the point that you mentioned "But by sending,
empty MAC-address-withdrawal list, it will remove none".

Regards,
Pranjal

Hi Pranjal,

I am raising.

/himanshu

	-----Original Message-----
	From: Dutta, Pranjal [mailto:[email-masked]]
	Sent: Tuesday, January 03, 2006 3:23 AM
	To: Shah, Himanshu; [email-masked]
	Subject: RE: VPLS question on MAC address withdrawal

	Hi Himanshu,

	   

	 

	 

	Regards,

	Pranjal

	Hi Pranjal,

	

	regards,
	himanshu
	
	-----Original Message-----
	From: Dutta, Pranjal [mailto:[email-masked]]
	Sent: Mon 1/2/2006 3:16 AM
	To: Shah, Himanshu; [email-masked]
	Subject: RE: VPLS question on MAC address withdrawal
	
	Hi Himanshu,

	
	Thanks,
	
	Pranjal

	

	
	(1)

	 

	 

	

	

	

	
	(2)

	

	regards,
	himanshu
	
	Himanshu Shah
	Ciena Corp

---

From: "Marc Lasserre" <[email-masked]>
Date: Wed, 4 Jan 2006 12:22:14 +0100

VPLS question on MAC address withdrawalHimanshu,

Sorry to jump a bit late in this discussion.
See my answers below.

Cheers,
Marc
  ----- Original Message ----- 
  From: Shah, Himanshu 
  To: [email-masked] 
  Sent: Thursday, December 29, 2005 10:19 PM
  Subject: VPLS question on MAC address withdrawal

  (1) 

    

    

  To simplify the problem, lets assume that for a given VPLS instance A there are only 5 MAC 
  addresses and one PW. In this case, for TCN-Triggererd MAC-address-withdrawal, sending 
  a list of 5 MAC address vs sending an empty list achieves opposite result. That is, sending 
  explicit list will cause the receiver to remove all 5 addresses (lets assume that they all were 
  associated with sender). But by sending, empty MAC-address-withdrawal list, it will remove 
  none.  However, the draft says, 

Sending an empty MAC withdraw message will trigger all MACs to be unlearned (the 5 MACs

in your examples). Only MACs behing the newly active PE-rs would be preserved.

  (2) 
  Is MAC-Address-withdraw mechanism ever intended to be used for U-PW (user facing PW, MTU-S<->PErs)? 
  If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to U-PW, etc needs to 
  be described. 

The main intent is for an MTU-s to trigger MAC withdrawal to its directly attached PE-rs. The PE-rs will

propagate MAC withdrawal messages to its peer PEs. There is no withdrawal event to be performed by egress

MTUs. The triggering events for sending MAC withdrawals can be based on different failure detection

mechanisms (eg STP based TCNs, BFD, etc).

  regards, 
  himanshu 

  Himanshu Shah 
  Ciena Corp

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Wed, 4 Jan 2006 10:04:04 -0800

Hi Himanshu,
 
When this section was first written, the MAC address withdraw message
was generated by the PE detecting the failed link or PW. This was
incorrect because the backup link might not have come up yet and this
message would have resulted in deleting MAC addresses without having any
place to sent the traffic to and thus causing broadcast storms in the
provider network. 
 
When I edited this section of the draft several years ago, I corrected
this issue by modeling it after IEEE TCN operation. The version 4 of
this draft based on my edit (which I happened to have) is as follow:
 
"The processing for MAC TLVs received in an Address Withdraw Message is:

-       Relearn the association between the MAC address and the
interface/pseudowire over which this message is received

-       Send the same message to all other PEs over the corresponding
directed LDP sessions.

  For an Address Withdraw message with empty list:

-       Remove all the MAC addresses associated with the VPLS instance
(specified by the FEC TLV) except the MAC addresses learned over this
link (over the pseudowire associated with the signaling link over which
the message is received) 

-       Send the same message to all other PEs over the corresponding
directed LDP sessions.

The scope of a MAC TLV is the VPLS specified in the FEC TLV in the
Address Withdraw Message.  The number of MAC addresses can be deduced
from the length field in the TLV."  

As you can see, for the case of MAC address withdraw message with
non-empty list, the message is sent over the newly activated link (just
like TCN) but with as list of MAC addresses to be "RE-LEARNED" and NOT
deleted as specified currently in the draft. In other words, if a VPLS
has a few MAC addresses and a MTU-rs wants to let the PE know that these
MAC addresses are affected and now needs to be re-learned over this
newly activated link, then this message can be used.
 
It seems like someone has changed the correct text based on my edit into
the existing incorrect text but given that Vach and Marc are now the
primary editors (and not me), they can take the credit for this :-)
 
-Ali

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Shah, Himanshu
	Sent: Tuesday, January 03, 2006 6:24 AM
	To: Dutta, Pranjal; [email-masked]
	Subject: RE: VPLS question on MAC address withdrawal

	Hi Pranjal,
	 
	I think there is a disconnect. You are failing to understand the
point
	I am raising.
	 
	I perfectly understand what empty MAC address withdraw list
does. 
	 
	Please go through the example I gave. The example clearly shows
that
	MAC address withdraw list and empty MAC address withdraw list
can
	NOT be used interchangeably (for scalability or for other
reasons).
	 
	As for the second part, the failover causes MAC switchover at
the
	expense of disturbance to other MAC conversations that had
nothing
	to do with the failover. It would almost seem that under such
circumstances
	MAC Withdraw list with switchover MAC addresses from original
primary
	PE-rs to other PE-rs would make more sense than having to  make
all the
	PE-rs to remove all the MAC addresses (for a given VPLS
instances) other than
	the ones switched over. Seems too expensive.
	 
	/himanshu

		-----Original Message-----
		From: Dutta, Pranjal [mailto:[email-masked]]
		Sent: Tuesday, January 03, 2006 3:23 AM
		To: Shah, Himanshu; [email-masked]
		Subject: RE: VPLS question on MAC address withdrawal

		Hi Himanshu,

		                     Reg. the first part again excerpts
from the draft as below

		For a MAC Address Withdraw message with empty list: 
		     - Remove all the MAC addresses associated with the
VPLS 
		       instance(specified by the FEC TLV) except the MAC
addresses 
		       learned over the PW associated with this
signaling session 
		       over which the message was received 
		   
		  The scope of a MAC List TLV is the VPLS specified in
the FEC TLV in 
		  the MAC Address Withdraw Message.  The number of MAC
addresses can 

		 

		 In the first part as per my understanding goes, empty
MAC list TLV means delete the association between all MAC addresses
associated with the VPLS instance

		specified in by the FEC TLV within the address withdraw
message. This will not delete the association of MACs with the PW on
which the Address Withdraw message with empty MAC list is received.

		To address the broadcast issue when empty-list MAC
withdraw is used, we can implement some filtering mechanism to
selectively block MAC withdraw msg for some FECs at PE-rs/originating
MTU (for PWs where temp. b'cast is not desired due to MAC withdraw).
Anyway that is my theoretical idea and could be implementation specific.

		Regards,

		Pranjal

		Hi Pranjal,

		In MAC address withdraw list TLV with MAC addresses,
receiver
		removes the association between MAC addresses in
		the list and PW over which the signal is received.
		
		In MAC address TLV list with no MAC addresses,
		the receiver removes the association between all MAC
addresses
		EXCEPT the ones over which he receives this signal.
		
		In the second part of the question, empty MAC address
		withdraw List TLV receieved by secondary which now is
primary
		PE-rs also has some issues. Broadcasting the empty MAC
		address withdraw List TLV to all other PE-rs would
create
		broadcasts in the core, as it removes MAC addresses
		learned from ALL N-PWs EXCEPT for ones learned on the
		PW over which the signal was received.  This needs to be
		carefully thought out too.
		
		regards,
		himanshu
		
		-----Original Message-----
		From: Dutta, Pranjal [mailto:[email-masked]]
		Sent: Mon 1/2/2006 3:16 AM
		To: Shah, Himanshu; [email-masked]
		Subject: RE: VPLS question on MAC address withdrawal
		
		Hi Himanshu,

		
		Thanks,
		
		Pranjal

		
		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Shah, Himanshu
		Sent: Friday, 30 December, 2005 2:49 AM
		To: [email-masked]
		Subject: VPLS question on MAC address withdrawal

		Hope somebody can shed light on the following
questions....
		
		(1)
		There are two mechanisms described -
		MAC address withdraw List TLV and empty MAC Address
withdraw List TLV

		 
		 
		  For each MAC address in the TLV:
		     - Remove the association between the MAC address
and the AC or
		        PW over which this message is received
		 
		  For a MAC Address Withdraw message with empty list:
		     - Remove all the MAC addresses associated with the
VPLS
		        instance  (specified by the FEC TLV) except the
MAC addresses
		        learned over the PW associated with this
signaling session
		        over which the message was received
		 
		  The scope of a MAC List TLV is the VPLS specified in
the FEC TLV in
		  the MAC Address Withdraw Message.  The number of MAC
addresses can
		  be deduced from the length field in the TLV.
		
		To simplify the problem, lets assume that for a given
VPLS instance A there are only 5 MAC
		addresses and one PW. In this case, for TCN-Triggererd
MAC-address-withdrawal, sending
		a list of 5 MAC address vs sending an empty list
achieves opposite result. That is, sending
		explicit list will cause the receiver to remove all 5
addresses (lets assume that they all were
		associated with sender). But by sending, empty
MAC-address-withdrawal list, it will remove
		none.  However, the draft says,
		
		In order to minimize the impact on LDP convergence time,
when the
		  MAC list TLV contains a large number of MAC addresses,
it may be
		  preferable to send a MAC address withdrawal message
with an empty
		  list.
		
		[Pranjal]: What the draft means is that with empty-list
in MAC withdraw TLV means remove "ALL" MACs.
		
		              The processing entity of MAC List TLV (in
Address Withdraw Msg) needs to flush all MACs associated with a VPLS
instance when it receives MAC list TLV
		
		                without any MAC address(s) in the list
(empty list). In case, of the MAC List TLV that contains specific MAC
addresses then the receiving
		
		                entity needs to remove only those MAC
addresses in the list associated with VPLS instance (identifies by FEC
in the address withdraw msg). The withdrawl with empty list

		                Address withdraw with 1000 MACs list,
can send empty list instead. But again it is optional (means if the MAC
withdraw originating PE wants
		
		               It can send Address Withdraw with 1000
MACs list) and implementation specific. Let's say for a dual homed MTU
in HVPLS, the primary link has 100 PWs
		
		                (1 for each VPLS instance) and the
secondary link has the backup of all the 100 PWs. Now if all 100 primary
PWs fail then, all will switch back to the secondary and MTU
		
		               needs to send Address Withdraw with
MACList TLV, one for each of the 100 PWs. So, empty list would be
preferable for each message.
		
		(2)
		Is MAC-Address-withdraw mechanism ever intended to be
used for U-PW (user facing PW, MTU-S<->PErs)?
		If so, how, when, implication of withdraw msg from N-PW
(PE<->PE) to U-PW, etc needs to
		be described.

		[Pranjal]: The draft says that the MAC withdraw
originated at a MTU (in MTU-PErs direction) needs to be processed and
forwarded by PE-rs
		
		to other PEs. The draft hasn't specified about
propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS (in
PErs->MTU direction). I think
		
		that part is implementation specific. The reason could
be the distant end MTUs will still be receiving the traffic in the
primary link and MAC withdrawl may not be necessary.
		
		regards,
		himanshu
		
		Himanshu Shah
		Ciena Corp

---

From: "Florin Balus" <[email-masked]>
Date: Wed, 4 Jan 2006 13:47:19 -0500

Hi Ali, 
So what you are saying is that is better for the MTU-s that moved to a
new PE-rs and subsequently the new PE-rs to readvertise the MAC
addresses he knows about to avoid flooding. I assume that on reception
of a non-empty MAC Address withdraw, the receiving PE-rs will remove the
old entries pointing to the old PE-rs to avoid blackholing. 
 
This seems like a better alternative although if flooding is a concern,
we should note that the second option (empty list) may generate much
more flooding.
 
Nevertheless we should make sure there are interoperable implementations
out there as it seems there are at least 2 versions...  
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ali Sajassi (sajassi)
Sent: Wednesday, January 04, 2006 1:04 PM
To: Shah, Himanshu; Dutta, Pranjal; [email-masked]
Subject: RE: VPLS question on MAC address withdrawal

Hi Himanshu,

 

 
 
-Ali

  _____  

Hi Pranjal,

 

/himanshu

-----Original Message-----
From: Dutta, Pranjal [mailto:[email-masked]]
Sent: Tuesday, January 03, 2006 3:23 AM
To: Shah, Himanshu; [email-masked]
Subject: RE: VPLS question on MAC address withdrawal

Hi Himanshu,

   

 

 

 

Regards,

Pranjal

  _____  

Hi Pranjal,

regards,
himanshu

-----Original Message-----
From: Dutta, Pranjal [mailto:[email-masked]]
Sent: Mon 1/2/2006 3:16 AM
To: Shah, Himanshu; [email-masked]
Subject: RE: VPLS question on MAC address withdrawal

Hi Himanshu,

Thanks,

Pranjal

(1)

 

 

(2)

regards,
himanshu

Himanshu Shah
Ciena Corp

---

From: "Serbest, Yetik" <[email-masked]>
Date: Wed, 4 Jan 2006 15:03:18 -0600

As I remember Norm Finn explained this case and reasoning very clearly
in his draft (see the following link).

http://www.watersprings.org/pub/id/draft-finn-ppvpn-bridging-vpls-00.txt

thanks,

yetik

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Florin Balus
Sent: Wednesday, January 04, 2006 12:47 PM
To: Ali Sajassi (sajassi); Shah, Himanshu; Dutta, Pranjal;
[email-masked]
Subject: RE: VPLS question on MAC address withdrawal

Hi Ali, 

-----Original Message-----

	Hi Himanshu,

	When this section was first written, the MAC address withdraw
message was generated by the PE detecting the failed link or PW. This
was incorrect because the backup link might not have come up yet and
this message would have resulted in deleting MAC addresses without
having any place to sent the traffic to and thus causing broadcast
storms in the provider network. 

	When I edited this section of the draft several years ago, I
corrected this issue by modeling it after IEEE TCN operation. The
version 4 of this draft based on my edit (which I happened to have) is
as follow:

	"The processing for MAC TLVs received in an Address Withdraw
Message is:

	-       Send the same message to all other PEs over the
corresponding directed LDP sessions.

	-       Remove all the MAC addresses associated with the VPLS
instance (specified by the FEC TLV) except the MAC addresses learned
over this link (over the pseudowire associated with the signaling link
over which the message is received) 

	-       Send the same message to all other PEs over the
corresponding directed LDP sessions.

	The scope of a MAC TLV is the VPLS specified in the FEC TLV in
the Address Withdraw Message.  The number of MAC addresses can be
deduced from the length field in the TLV."  

	As you can see, for the case of MAC address withdraw message
with non-empty list, the message is sent over the newly activated link
(just like TCN) but with as list of MAC addresses to be "RE-LEARNED" and
NOT deleted as specified currently in the draft. In other words, if a
VPLS has a few MAC addresses and a MTU-rs wants to let the PE know that
these MAC addresses are affected and now needs to be re-learned over
this newly activated link, then this message can be used.

	It seems like someone has changed the correct text based on my
edit into the existing incorrect text but given that Vach and Marc are
now the primary editors (and not me), they can take the credit for this
:-)

	-Ali

		Hi Pranjal,

		I think there is a disconnect. You are failing to
understand the point

		I am raising.

		I perfectly understand what empty MAC address withdraw
list does. 

		Please go through the example I gave. The example
clearly shows that

		MAC address withdraw list and empty MAC address withdraw
list can

		NOT be used interchangeably (for scalability or for
other reasons).

		As for the second part, the failover causes MAC
switchover at the

		expense of disturbance to other MAC conversations that
had nothing

		to do with the failover. It would almost seem that under
such circumstances

		MAC Withdraw list with switchover MAC addresses from
original primary

		PE-rs to other PE-rs would make more sense than having
to  make all the

		/himanshu

			-----Original Message-----
			From: Dutta, Pranjal
[mailto:[email-masked]]
			Sent: Tuesday, January 03, 2006 3:23 AM
			To: Shah, Himanshu; [email-masked]
			Subject: RE: VPLS question on MAC address
withdrawal

			Hi Himanshu,

			                     Reg. the first part again
excerpts from the draft as below

			For a MAC Address Withdraw message with empty
list: 
			     - Remove all the MAC addresses associated
with the VPLS 
			       instance(specified by the FEC TLV) except
the MAC addresses 
			       learned over the PW associated with this
signaling session 
			       over which the message was received 
			   
			  The scope of a MAC List TLV is the VPLS
specified in the FEC TLV in 
			  the MAC Address Withdraw Message.  The number
of MAC addresses can 

			 

			 In the first part as per my understanding goes,
empty MAC list TLV means delete the association between all MAC
addresses associated with the VPLS instance

			specified in by the FEC TLV within the address
withdraw message. This will not delete the association of MACs with the
PW on which the Address Withdraw message with empty MAC list is
received.

			So as specified in draft the scope is limited to
the FEC specified only. 

			The second issue you raised is very interesting
and has practical implications. After PW switchover when, MTU originates
the Address Withdraw for all N PWs (one msg. for each PW). Those will be
forwarded by the "new" PE-rs to all peers thoughout the domain. Removal
of all MACs would cause spark of broadcast and considering the traffic
for all N FECs are flowing now via secondary PW, so associated MACs will
get relearned again across all the PEs. So broadcast will stop once
relearning completes. In the absence of MAC withdraw, traffic won't
broadcast, but will keep flowing to wrong ports (till the MACs ages out
or till relearning happens again). I think we need to see the time
window for the broadcast in a specified scenario/application where MAC
withdraw is being used. That could be also one of the reasons why MAC
withdraw is an optional feature in VPLS.  

			To address the broadcast issue when empty-list
MAC withdraw is used, we can implement some filtering mechanism to
selectively block MAC withdraw msg for some FECs at PE-rs/originating
MTU (for PWs where temp. b'cast is not desired due to MAC withdraw).
Anyway that is my theoretical idea and could be implementation specific.

			Regards,

			Pranjal

			From: Shah, Himanshu [mailto:[email-masked]] 
			Sent: Monday, 02 January, 2006 8:50 PM
			To: Dutta, Pranjal; [email-masked]
			Subject: RE: VPLS question on MAC address
withdrawal

			Hi Pranjal,
			
			It seems easy to get confused that
			mac address withdraw list TLV and empty mac
address
			withdraw list TLV are one and the same and can
be used
			interchangeably for scalability. But that is
			clearly not true.
			
			In MAC address withdraw list TLV with MAC
addresses, receiver
			removes the association between MAC addresses in
			the list and PW over which the signal is
received.
			
			In MAC address TLV list with no MAC addresses,
			the receiver removes the association between all
MAC addresses
			EXCEPT the ones over which he receives this
signal.
			
			In the second part of the question, empty MAC
address
			withdraw List TLV receieved by secondary which
now is primary
			PE-rs also has some issues. Broadcasting the
empty MAC
			address withdraw List TLV to all other PE-rs
would create
			broadcasts in the core, as it removes MAC
addresses
			learned from ALL N-PWs EXCEPT for ones learned
on the
			PW over which the signal was received.  This
needs to be
			carefully thought out too.
			
			regards,
			himanshu
			
			-----Original Message-----
			From: Dutta, Pranjal
[mailto:[email-masked]]
			Sent: Mon 1/2/2006 3:16 AM
			To: Shah, Himanshu; [email-masked]
			Subject: RE: VPLS question on MAC address
withdrawal
			
			Hi Himanshu,
			
			                      Please see my answers
inline

			Thanks,
			
			Pranjal

			

			
			(1)
			There are two mechanisms described -
			MAC address withdraw List TLV and empty MAC
Address withdraw List TLV

			6.2.2. Address Withdraw Message Containing MAC
List TLV
			 
			  The processing for MAC List TLV received in an
Address Withdraw
			  Message is:
			 
			  For each MAC address in the TLV:
			     - Remove the association between the MAC
address and the AC or
			        PW over which this message is received
			 
			  For a MAC Address Withdraw message with empty
list:
			     - Remove all the MAC addresses associated
with the VPLS
			        instance  (specified by the FEC TLV)
except the MAC addresses
			        learned over the PW associated with this
signaling session
			        over which the message was received
			 
			  The scope of a MAC List TLV is the VPLS
specified in the FEC TLV in
			  the MAC Address Withdraw Message.  The number
of MAC addresses can
			  be deduced from the length field in the TLV.
			
			To simplify the problem, lets assume that for a
given VPLS instance A there are only 5 MAC
			addresses and one PW. In this case, for
TCN-Triggererd MAC-address-withdrawal, sending
			a list of 5 MAC address vs sending an empty list
achieves opposite result. That is, sending
			explicit list will cause the receiver to remove
all 5 addresses (lets assume that they all were
			associated with sender). But by sending, empty
MAC-address-withdrawal list, it will remove
			none.  However, the draft says,
			
			In order to minimize the impact on LDP
convergence time, when the
			  MAC list TLV contains a large number of MAC
addresses, it may be
			  preferable to send a MAC address withdrawal
message with an empty
			  list.
			
			[Pranjal]: What the draft means is that with
empty-list in MAC withdraw TLV means remove "ALL" MACs.
			
			              The processing entity of MAC List
TLV (in Address Withdraw Msg) needs to flush all MACs associated with a
VPLS instance when it receives MAC list TLV
			
			                without any MAC address(s) in
the list (empty list). In case, of the MAC List TLV that contains
specific MAC addresses then the receiving
			
			                entity needs to remove only
those MAC addresses in the list associated with VPLS instance
(identifies by FEC in the address withdraw msg). The withdrawl with
empty list
			
			                feature is to make it more
scalable. For example, a VPLS instance that has 1000 MACs learned at a
PE need not send
			
			                Address withdraw with 1000 MACs
list, can send empty list instead. But again it is optional (means if
the MAC withdraw originating PE wants
			
			               It can send Address Withdraw with
1000 MACs list) and implementation specific. Let's say for a dual homed
MTU in HVPLS, the primary link has 100 PWs
			
			                (1 for each VPLS instance) and
the secondary link has the backup of all the 100 PWs. Now if all 100
primary PWs fail then, all will switch back to the secondary and MTU
			
			               needs to send Address Withdraw
with MACList TLV, one for each of the 100 PWs. So, empty list would be
preferable for each message.
			
			(2)
			Is MAC-Address-withdraw mechanism ever intended
to be used for U-PW (user facing PW, MTU-S<->PErs)?
			If so, how, when, implication of withdraw msg
from N-PW (PE<->PE) to U-PW, etc needs to
			be described.

			
			
			that part is implementation specific. The reason
could be the distant end MTUs will still be receiving the traffic in the
primary link and MAC withdrawl may not be necessary.
			
			regards,
			himanshu
			
			Himanshu Shah
			Ciena Corp

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 5 Jan 2006 10:09:54 -0500

Hi Marc,
 
It seems that you and pranjal are taking narrower view of the use of
MAC address withdraw mechanism. This being its use during
failovers to backup PE-rs in H-VPLS topology.
 
My concern is for general cases. If a TCN was triggered 5 hops
deep in C-STP land and is being propagated from root to leaves.
If PE-rs or MTU-s is monitoring such TCN and triggers MAC
address withdraw then empty and non-empty MAC address
withdraw is going to achieve different results at receiving PE-rs
(as was described in my previous emails).
 
If MAC address withdraw is strictly used for H-VPLS topology
for failover from primary to secondary PE-rs, then you should 
state this restriction in the draft. If not, then may be you need
another qualifier (i.e. flag) for empty MAC address withdraw list which
states for a given VPLS instance,
1) age out all MAC except ones learned on PW receiving this signal ( current )
2) age out all MAC that are learned on PW receiving this signal (new)
3) age out all MAC (new)
 
regards,
himanshu

-----Original Message-----
From: Marc Lasserre [mailto:[email-masked]]
Sent: Wednesday, January 04, 2006 6:22 AM
To: Shah, Himanshu; [email-masked]
Subject: Re: VPLS question on MAC address withdrawal

Himanshu,

Cheers,
Marc

----- Original Message ----- 
From: Shah, Himanshu <mailto:[email-masked]>  
To: [email-masked] 
Sent: Thursday, December 29, 2005 10:19 PM
Subject: VPLS question on MAC address withdrawal

(1) 

  

  

(2) 

regards, 
himanshu 

Himanshu Shah 
Ciena Corp

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Thu, 5 Jan 2006 08:56:18 -0800

Florin,
Please see my reply in line ...

	From: Florin Balus [mailto:[email-masked]] 
	Sent: Wednesday, January 04, 2006 10:47 AM
	To: Ali Sajassi (sajassi); Shah, Himanshu; Dutta, Pranjal;
[email-masked]
	Subject: RE: VPLS question on MAC address withdrawal

	Hi Ali, 
	So what you are saying is that is better for the MTU-s that
moved to a new PE-rs and subsequently the new PE-rs to readvertise the
MAC addresses he knows about to avoid flooding. I assume that on
reception of a non-empty MAC Address withdraw, the receiving PE-rs will
remove the old entries pointing to the old PE-rs to avoid blackholing. 
	[AS] Yes, MTU-s will notify the PE-rs via its newly activated PW
and subsequently PE-rs will notify other PE-rs to take the same action.
	 
	This seems like a better alternative although if flooding is a
concern, we should note that the second option (empty list) may generate
much more flooding.
	[AS] The main point of sending both messages (MAC withdraw
message with empty-list and MAC withdraw message with non-empty list)
over newly activated link is to avoid BLACKHOLING and unnecessary
flooding. The fact that the message with empty-list creates more
flooding is the price we pay for its simplicity but it is consistent
with the operation of current IEEE bridges. 
	 
	Nevertheless we should make sure there are interoperable
implementations out there as it seems there are at least 2 versions...  
	[AS] Yes, we need to correct the  current rev. of the draft. 
	 
	-----Original Message-----
Behalf Of Ali Sajassi (sajassi)

		Hi Himanshu,
		 
		When this section was first written, the MAC address
withdraw message was generated by the PE detecting the failed link or
PW. This was incorrect because the backup link might not have come up
yet and this message would have resulted in deleting MAC addresses
without having any place to sent the traffic to and thus causing
broadcast storms in the provider network. 
		 
		When I edited this section of the draft several years
ago, I corrected this issue by modeling it after IEEE TCN operation. The
version 4 of this draft based on my edit (which I happened to have) is
as follow:
		 
		"The processing for MAC TLVs received in an Address
Withdraw Message is:

		-       Relearn the association between the MAC address
and the interface/pseudowire over which this message is received

		-       Remove all the MAC addresses associated with the
VPLS instance (specified by the FEC TLV) except the MAC addresses
learned over this link (over the pseudowire associated with the
signaling link over which the message is received) 

		The scope of a MAC TLV is the VPLS specified in the FEC
TLV in the Address Withdraw Message.  The number of MAC addresses can be
deduced from the length field in the TLV."  

		As you can see, for the case of MAC address withdraw
message with non-empty list, the message is sent over the newly
activated link (just like TCN) but with as list of MAC addresses to be
"RE-LEARNED" and NOT deleted as specified currently in the draft. In
other words, if a VPLS has a few MAC addresses and a MTU-rs wants to let
the PE know that these MAC addresses are affected and now needs to be
re-learned over this newly activated link, then this message can be
used.
		 
		It seems like someone has changed the correct text based
on my edit into the existing incorrect text but given that Vach and Marc
are now the primary editors (and not me), they can take the credit for
this :-)
		 
		-Ali

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Thu, 5 Jan 2006 11:01:27 -0800

Yes, I agree. If there is no objection to this proposal, lets include it
in the next rev. of the document.
 
-Ali

	From: Shah, Himanshu [mailto:[email-masked]] 
	Sent: Thursday, January 05, 2006 7:28 AM
	To: Ali Sajassi (sajassi); Dutta, Pranjal; [email-masked]
	Cc: Libby, Mark
	Subject: RE: VPLS question on MAC address withdrawal

	Hi Ali,
	 
	It is a good suggestion and it would help in broadcast
	dampening, as you suggest. May be a qualifier can be
	added in the MAC address withdraw list TLV to 
	1) delete the MAC addresses in the list (current)
	2) re-learn the MAC addresses in the list to the PW over
	    which this signal is received (new - your suggestion)
	 
	I also suggested an additional qualifier for empty MAC address
	withdraw list to make operations for empty and non-empty list
consistent.
	 
	/himanshu

		-----Original Message-----
		From: Ali Sajassi (sajassi) [mailto:[email-masked]]
		Sent: Wednesday, January 04, 2006 1:04 PM
		To: Shah, Himanshu; Dutta, Pranjal; [email-masked]
		Subject: RE: VPLS question on MAC address withdrawal

		Hi Himanshu,

		 

		 
		 
		-Ali

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Thu, 5 Jan 2006 08:50:50 -0800

Florin,

	Hi Ali, 

	 
	-----Original Message-----

		Hi Himanshu,

		 

		 
		 
		-Ali

			Hi Pranjal,
			 
			I think there is a disconnect. You are failing
to understand the point
			I am raising.
			 
			I perfectly understand what empty MAC address
withdraw list does. 
			 
			Please go through the example I gave. The
example clearly shows that
			MAC address withdraw list and empty MAC address
withdraw list can
			NOT be used interchangeably (for scalability or
for other reasons).
			 
			As for the second part, the failover causes MAC
switchover at the
			expense of disturbance to other MAC
conversations that had nothing
			to do with the failover. It would almost seem
that under such circumstances
			MAC Withdraw list with switchover MAC addresses
from original primary
			PE-rs to other PE-rs would make more sense than
having to  make all the
			PE-rs to remove all the MAC addresses (for a
given VPLS instances) other than
			the ones switched over. Seems too expensive.
			 
			/himanshu

				-----Original Message-----
				From: Dutta, Pranjal
[mailto:[email-masked]]
				Sent: Tuesday, January 03, 2006 3:23 AM
				To: Shah, Himanshu; [email-masked]
				Subject: RE: VPLS question on MAC
address withdrawal

				Hi Himanshu,

				                     Reg. the first part
again excerpts from the draft as below

				For a MAC Address Withdraw message with
empty list: 
				     - Remove all the MAC addresses
associated with the VPLS 
				       instance(specified by the FEC
TLV) except the MAC addresses 
				       learned over the PW associated
with this signaling session 
				       over which the message was
received 
				   
				  The scope of a MAC List TLV is the
VPLS specified in the FEC TLV in 
				  the MAC Address Withdraw Message.  The
number of MAC addresses can 

				  be deduced from the length field in
the TLV

				 In the first part as per my
understanding goes, empty MAC list TLV means delete the association
between all MAC addresses associated with the VPLS instance

				specified in by the FEC TLV within the
address withdraw message. This will not delete the association of MACs
with the PW on which the Address Withdraw message with empty MAC list is
received.

				So as specified in draft the scope is
limited to the FEC specified only. 

				The second issue you raised is very
interesting and has practical implications. After PW switchover when,
MTU originates the Address Withdraw for all N PWs (one msg. for each
PW). Those will be forwarded by the "new" PE-rs to all peers thoughout
the domain. Removal of all MACs would cause spark of broadcast and
considering the traffic for all N FECs are flowing now via secondary PW,
so associated MACs will get relearned again across all the PEs. So
broadcast will stop once relearning completes. In the absence of MAC
withdraw, traffic won't broadcast, but will keep flowing to wrong ports
(till the MACs ages out or till relearning happens again). I think we
need to see the time window for the broadcast in a specified
scenario/application where MAC withdraw is being used. That could be
also one of the reasons why MAC withdraw is an optional feature in VPLS.

				To address the broadcast issue when
empty-list MAC withdraw is used, we can implement some filtering
mechanism to selectively block MAC withdraw msg for some FECs at
PE-rs/originating MTU (for PWs where temp. b'cast is not desired due to
MAC withdraw). Anyway that is my theoretical idea and could be
implementation specific.   

				Regards,

				Pranjal

				From: Shah, Himanshu
[mailto:[email-masked]] 
				Sent: Monday, 02 January, 2006 8:50 PM
				To: Dutta, Pranjal; [email-masked]
				Subject: RE: VPLS question on MAC
address withdrawal

				Hi Pranjal,
				
				It seems easy to get confused that
				mac address withdraw list TLV and empty
mac address
				withdraw list TLV are one and the same
and can be used
				interchangeably for scalability. But
that is
				clearly not true.
				
				In MAC address withdraw list TLV with
MAC addresses, receiver
				removes the association between MAC
addresses in
				the list and PW over which the signal is
received.
				
				In MAC address TLV list with no MAC
addresses,
				the receiver removes the association
between all MAC addresses
				EXCEPT the ones over which he receives
this signal.
				
				In the second part of the question,
empty MAC address
				withdraw List TLV receieved by secondary
which now is primary
				PE-rs also has some issues. Broadcasting
the empty MAC
				address withdraw List TLV to all other
PE-rs would create
				broadcasts in the core, as it removes
MAC addresses
				learned from ALL N-PWs EXCEPT for ones
learned on the
				PW over which the signal was received.
This needs to be
				carefully thought out too.
				
				regards,
				himanshu
				
				-----Original Message-----
				From: Dutta, Pranjal
[mailto:[email-masked]]
				Sent: Mon 1/2/2006 3:16 AM
				To: Shah, Himanshu; [email-masked]
				Subject: RE: VPLS question on MAC
address withdrawal
				
				Hi Himanshu,
				
				                      Please see my
answers inline

				Thanks,
				
				Pranjal

				
				From: [email-masked]
[mailto:[email-masked]] On Behalf Of Shah, Himanshu
				Sent: Friday, 30 December, 2005 2:49 AM
				To: [email-masked]
				Subject: VPLS question on MAC address
withdrawal

				Hope somebody can shed light on the
following questions....
				
				(1)
				There are two mechanisms described -
				MAC address withdraw List TLV and empty
MAC Address withdraw List TLV

				6.2.2. Address Withdraw Message
Containing MAC List TLV
				 
				  The processing for MAC List TLV
received in an Address Withdraw
				  Message is:
				 
				  For each MAC address in the TLV:
				     - Remove the association between
the MAC address and the AC or
				        PW over which this message is
received
				 
				  For a MAC Address Withdraw message
with empty list:
				     - Remove all the MAC addresses
associated with the VPLS
				        instance  (specified by the FEC
TLV) except the MAC addresses
				        learned over the PW associated
with this signaling session
				        over which the message was
received
				 
				  The scope of a MAC List TLV is the
VPLS specified in the FEC TLV in
				  the MAC Address Withdraw Message.  The
number of MAC addresses can
				  be deduced from the length field in
the TLV.
				
				To simplify the problem, lets assume
that for a given VPLS instance A there are only 5 MAC
				addresses and one PW. In this case, for
TCN-Triggererd MAC-address-withdrawal, sending
				a list of 5 MAC address vs sending an
empty list achieves opposite result. That is, sending
				explicit list will cause the receiver to
remove all 5 addresses (lets assume that they all were
				associated with sender). But by sending,
empty MAC-address-withdrawal list, it will remove
				none.  However, the draft says,
				
				In order to minimize the impact on LDP
convergence time, when the
				  MAC list TLV contains a large number
of MAC addresses, it may be
				  preferable to send a MAC address
withdrawal message with an empty
				  list.
				
				[Pranjal]: What the draft means is that
with empty-list in MAC withdraw TLV means remove "ALL" MACs.
				
				              The processing entity of
MAC List TLV (in Address Withdraw Msg) needs to flush all MACs
associated with a VPLS instance when it receives MAC list TLV
				
				                without any MAC
address(s) in the list (empty list). In case, of the MAC List TLV that
contains specific MAC addresses then the receiving
				
				                entity needs to remove
only those MAC addresses in the list associated with VPLS instance
(identifies by FEC in the address withdraw msg). The withdrawl with
empty list
				
				                feature is to make it
more scalable. For example, a VPLS instance that has 1000 MACs learned
at a PE need not send
				
				                Address withdraw with
1000 MACs list, can send empty list instead. But again it is optional
(means if the MAC withdraw originating PE wants
				
				               It can send Address
Withdraw with 1000 MACs list) and implementation specific. Let's say for
a dual homed MTU in HVPLS, the primary link has 100 PWs
				
				                (1 for each VPLS
instance) and the secondary link has the backup of all the 100 PWs. Now
if all 100 primary PWs fail then, all will switch back to the secondary
and MTU
				
				               needs to send Address
Withdraw with MACList TLV, one for each of the 100 PWs. So, empty list
would be preferable for each message.
				
				(2)
				Is MAC-Address-withdraw mechanism ever
intended to be used for U-PW (user facing PW, MTU-S<->PErs)?
				If so, how, when, implication of
withdraw msg from N-PW (PE<->PE) to U-PW, etc needs to
				be described.

				[Pranjal]: The draft says that the MAC
withdraw originated at a MTU (in MTU-PErs direction) needs to be
processed and forwarded by PE-rs
				
				to other PEs. The draft hasn't specified
about propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS
(in PErs->MTU direction). I think
				
				that part is implementation specific.
The reason could be the distant end MTUs will still be receiving the
traffic in the primary link and MAC withdrawl may not be necessary.
				
				regards,
				himanshu
				
				Himanshu Shah
				Ciena Corp

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 5 Jan 2006 10:28:21 -0500

Hi Ali,

I also suggested an additional qualifier for empty MAC address
withdraw list to make operations for empty and non-empty list consistent.
 
/himanshu

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Wednesday, January 04, 2006 1:04 PM
To: Shah, Himanshu; Dutta, Pranjal; [email-masked]
Subject: RE: VPLS question on MAC address withdrawal

Hi Himanshu,
 
When this section was first written, the MAC address withdraw message was generated by the PE detecting the failed link or PW. This was incorrect because the backup link might not have come up yet and this message would have resulted in deleting MAC addresses without having any place to sent the traffic to and thus causing broadcast storms in the provider network. 
 
When I edited this section of the draft several years ago, I corrected this issue by modeling it after IEEE TCN operation. The version 4 of this draft based on my edit (which I happened to have) is as follow:

-       Relearn the association between the MAC address and the interface/pseudowire over which this message is received

-       Send the same message to all other PEs over the corresponding directed LDP sessions.

-       Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over this link (over the pseudowire associated with the signaling link over which the message is received) 

-       Send the same message to all other PEs over the corresponding directed LDP sessions.

The scope of a MAC TLV is the VPLS specified in the FEC TLV in the Address Withdraw Message.  The number of MAC addresses can be deduced from the length field in the TLV."  

As you can see, for the case of MAC address withdraw message with non-empty list, the message is sent over the newly activated link (just like TCN) but with as list of MAC addresses to be "RE-LEARNED" and NOT deleted as specified currently in the draft. In other words, if a VPLS has a few MAC addresses and a MTU-rs wants to let the PE know that these MAC addresses are affected and now needs to be re-learned over this newly activated link, then this message can be used.
 
It seems like someone has changed the correct text based on my edit into the existing incorrect text but given that Vach and Marc are now the primary editors (and not me), they can take the credit for this :-)
 
-Ali

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Shah, Himanshu
Sent: Tuesday, January 03, 2006 6:24 AM
To: Dutta, Pranjal; [email-masked]
Subject: RE: VPLS question on MAC address withdrawal

Hi Pranjal,

 
 
As for the second part, the failover causes MAC switchover at the
expense of disturbance to other MAC conversations that had nothing
to do with the failover. It would almost seem that under such circumstances
MAC Withdraw list with switchover MAC addresses from original primary
PE-rs to other PE-rs would make more sense than having to  make all the
PE-rs to remove all the MAC addresses (for a given VPLS instances) other than
the ones switched over. Seems too expensive.
 
/himanshu

-----Original Message-----
From: Dutta, Pranjal [mailto:[email-masked]]
Sent: Tuesday, January 03, 2006 3:23 AM
To: Shah, Himanshu; [email-masked]
Subject: RE: VPLS question on MAC address withdrawal

Hi Himanshu,

                     Reg. the first part again excerpts from the draft as below

 

 In the first part as per my understanding goes, empty MAC list TLV means delete the association between all MAC addresses associated with the VPLS instance

specified in by the FEC TLV within the address withdraw message. This will not delete the association of MACs with the PW on which the Address Withdraw message with empty MAC list is received.

The second issue you raised is very interesting and has practical implications. After PW switchover when, MTU originates the Address Withdraw for all N PWs (one msg. for each PW). Those will be forwarded by the "new" PE-rs to all peers thoughout the domain. Removal of all MACs would cause spark of broadcast and considering the traffic for all N FECs are flowing now via secondary PW, so associated MACs will get relearned again across all the PEs. So broadcast will stop once relearning completes. In the absence of MAC withdraw, traffic won't broadcast, but will keep flowing to wrong ports (till the MACs ages out or till relearning happens again). I think we need to see the time window for the broadcast in a specified scenario/application where MAC withdraw is being used. That could be also one of the reasons why MAC withdraw is an optional feature in VPLS.  

To address the broadcast issue when empty-list MAC withdraw is used, we can implement some filtering mechanism to selectively block MAC withdraw msg for some FECs at PE-rs/originating MTU (for PWs where temp. b'cast is not desired due to MAC withdraw). Anyway that is my theoretical idea and could be implementation specific.   

Regards,

Pranjal

  _____  

Hi Pranjal,

regards,
himanshu

-----Original Message-----
From: Dutta, Pranjal [ mailto:[email-masked]]
Sent: Mon 1/2/2006 3:16 AM
To: Shah, Himanshu; [email-masked]
Subject: RE: VPLS question on MAC address withdrawal

Hi Himanshu,

Thanks,

Pranjal

From: [email-masked] [ mailto:[email-masked]] On Behalf Of Shah, Himanshu
Sent: Friday, 30 December, 2005 2:49 AM
To: [email-masked]
Subject: VPLS question on MAC address withdrawal

(1)

 

 

[Pranjal]: What the draft means is that with empty-list in MAC withdraw TLV means remove "ALL" MACs.

              The processing entity of MAC List TLV (in Address Withdraw Msg) needs to flush all MACs associated with a VPLS instance when it receives MAC list TLV

                without any MAC address(s) in the list (empty list). In case, of the MAC List TLV that contains specific MAC addresses then the receiving

                entity needs to remove only those MAC addresses in the list associated with VPLS instance (identifies by FEC in the address withdraw msg). The withdrawl with empty list

                feature is to make it more scalable. For example, a VPLS instance that has 1000 MACs learned at a PE need not send

                Address withdraw with 1000 MACs list, can send empty list instead. But again it is optional (means if the MAC withdraw originating PE wants

               It can send Address Withdraw with 1000 MACs list) and implementation specific. Let's say for a dual homed MTU in HVPLS, the primary link has 100 PWs

                (1 for each VPLS instance) and the secondary link has the backup of all the 100 PWs. Now if all 100 primary PWs fail then, all will switch back to the secondary and MTU

               needs to send Address Withdraw with MACList TLV, one for each of the 100 PWs. So, empty list would be preferable for each message.

(2)

[Pranjal]: The draft says that the MAC withdraw originated at a MTU (in MTU-PErs direction) needs to be processed and forwarded by PE-rs

to other PEs. The draft hasn't specified about propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS (in PErs->MTU direction). I think

that part is implementation specific. The reason could be the distant end MTUs will still be receiving the traffic in the primary link and MAC withdrawl may not be necessary.

regards,
himanshu

Himanshu Shah
Ciena Corp

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Thu, 5 Jan 2006 10:55:36 -0800

-Ali

	Hi Ali,

	 
	/himanshu

		-----Original Message-----
		From: Ali Sajassi (sajassi) [mailto:[email-masked]]
		Sent: Wednesday, January 04, 2006 1:04 PM
		To: Shah, Himanshu; Dutta, Pranjal; [email-masked]
		Subject: RE: VPLS question on MAC address withdrawal

		Hi Himanshu,

		 

		 
		 
		-Ali

			Hi Pranjal,

			 

			/himanshu

				-----Original Message-----
				From: Dutta, Pranjal

				Hi Himanshu,

				                     Reg. the first part

				 

				 

				 

				Regards,

				Pranjal

				From: Shah, Himanshu
[mailto:[email-masked]] 

				Hi Pranjal,

				

				regards,
				himanshu
				
				-----Original Message-----
				From: Dutta, Pranjal
				
				Hi Himanshu,
				
				                      Please see my
answers inline

				Thanks,
				
				Pranjal

				

				
				(1)

				 

				 

				
				
				              The processing entity of
				
				                without any MAC
				
				                entity needs to remove
				
				                feature is to make it
				
				                Address withdraw with
				
				               It can send Address
				
				                (1 for each VPLS
				
				               needs to send Address
				
				(2)

				

				regards,
				himanshu
				
				Himanshu Shah
				Ciena Corp