Subject: Question regarding MAC Withdrawal in H-VPLS Dual-homed MTU-s

From: "Asaf Henig" <[email-masked]>
Date: Tue, 26 Sep 2006 11:11:32 +0300

It is yet unclear from draft http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-09.txt who is responsible to send the MAC Withdrawal message to the secondary PE-rs when fail-over occures in an H-VPLS dual homed MTU-s scenario. 

It is known that when a primary VC fails in a dual-homing scenario the PE-rs connected to the secondary VC should relearn the MAC addresses behind the MTU-s. In order to make this process faster this "secondary" PE-rs should flush the relevant previously learned MAC addresses. For that to happen we have two options:
   
A) The primary PE-rs would send the MAC Withdrawal message to the secondary PE-rs (and all other PE-s) the minute it recognizes that its VC has failed. 
B) The MTU-s itself would send the MAC Withdrawal to the secondary PE-rs the minute it switches from primary to secondary VC. The secondary PE-rs would be responsible to propegate this message to all other PEs in the VPLS domain (this option is recommended by draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt).

Which option is preferred  ? 

Thanks for any help.   
Asaf Henig
MRV communications

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Wed, 4 Oct 2006 05:03:34 -0700

Option (B) is the preferred one as I describe in a separate email pasted
below.
 
-Ali
 
------------ snip ---------------------------------
 
MAC flushing in vpls-ldp draft is modeled after IEEE flushing mechanism
(TCN). In IEEE, when a bridge switches from failed link to the backup
link, then the bridge sends out a TCN message over the newly activated
link and the upstream bridge upon receiving this message, will flush all
its MAC addresses (except the one received over this link) and
propagates the TCN message out of its other ports (for that MSTI). 
 
In case of H-VPLS with u-PE dual-homing, then the following actions
should be taken:
 
1)  the u-PE shall initiate the MAC Withdraw message only after putting
the backup link into active state and the u-PE shall send the MW message
over this activated backup link. This means the u-PE shall not trigger
MW upon failure detection but only upon backup link activation
2) the u-PE shall flush its own MAC address for that VPLS instance upon
activation of the backup link (and NOT upon detection of the failure of
its primary PW/link)
3) the n-PE shall process this message as currently described in the
spec.
 
The reasons for sending MW over the activated backup link at the u-PE
are:
 
1) to avoid unnecessary flooding when the u-PE is only single homed
2) to avoid unnecessary flooding when the backup link is not activate
yet
 
In the next rev. of vpls-ldp draft, the above clarification should be
reflected.
 
-Ali

________________________________

	From: Asaf Henig [mailto:[email-masked]] 
	Sent: Tuesday, September 26, 2006 11:42 AM
	To: [email-masked]; [email-masked]; [email-masked]
	Subject: Question regarding MAC Withdrawal in H-VPLS Dual-homed
MTU-s 

	It is yet unclear from draft
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-09.txt who
is responsible to send the MAC Withdrawal message to the secondary PE-rs
when fail-over occures in an H-VPLS dual homed MTU-s scenario.
	
	It is known that when a primary VC fails in a dual-homing
scenario the PE-rs connected to the secondary VC should relearn the MAC
addresses behind the MTU-s. In order to make this process faster this
"secondary" PE-rs should flush the relevant previously learned MAC
addresses. For that to happen we have two options:
	  
	A) The primary PE-rs would send the MAC Withdrawal message to
the secondary PE-rs (and all other PE-s) the minute it recognizes that
its VC has failed.
	B) The MTU-s itself would send the MAC Withdrawal to the
secondary PE-rs the minute it switches from primary to secondary VC. The
secondary PE-rs would be responsible to propegate this message to all
other PEs in the VPLS domain (this option is recommended by
draft-pdutta-l2vpn-vpls-ldp-mac-opt-00.txt).

	Thanks for any help.  
	Asaf Henig
	MRV communications