Subject: RE: VPLS question on MAC address withdrawal

From: "Dutta, Pranjal" <[email-masked]>
Date: Mon, 2 Jan 2006 13:46:41 +0530

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: "Shah, Himanshu" <[email-masked]>
Date: Mon, 2 Jan 2006 10:19:42 -0500

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,

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) 

  

  

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, 

[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