Subject: RE: VPLS question on MAC address withdrawal

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 3 Jan 2006 09:24:12 -0500

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

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: "Marc Lasserre" <[email-masked]>
Date: Wed, 4 Jan 2006 12:34:21 +0100

RE: VPLS question on MAC address withdrawalThanks Pranjal for your previous replies.
See my replies below.

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

  Hi Pranjal,

Himanshu,

It is true that empty withdrawals lead to a different behaviour than withdrawals
with a MAC list, and hence one could say that they can not be used interchangeably.
However, both message types result in handling topology changes by unlearning
MACs that are no longer behind the proper circuits/devices. An empty withdrawal
does lead to unlearning MACs that were not affected. The reasoning is that there
might cases where the newly active ingress PE-rs might not know the specific list of
MACs that need to be unlearned.

  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.
In cases where such a list is available or when such a list if small enough,
the draft does not prevent such a capability (i.e. having the newly active ingress PE-rs
send a list of the MACs to be switched) from being implemented.

  /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,

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

     

    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)

     

     

    (2)

    regards,
    himanshu

    Himanshu Shah
    Ciena Corp