Subject: RE: [mpls] Question regarding MAC Withdrawal in H-VPLS Dual-homedMTU-s

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Tue, 26 Sep 2006 09:22:56 -0700

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: Dutta, Pranjal [mailto:[email-masked]] 
	Sent: Tuesday, September 26, 2006 2:52 AM
	To: Asaf Henig; [email-masked]
	Subject: RE: [mpls] Question regarding MAC Withdrawal in H-VPLS
Dual-homedMTU-s

	Asaf,

	           Please refer my answers inline.

	Thanks,

	Pranjal

________________________________

	From: Asaf Henig [mailto:[email-masked]] 
	Sent: Tuesday, 26 September, 2006 1:42 PM
	To: [email-masked]; [email-masked]; [email-masked]
	Subject: [mpls] 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.

	Section 10.2.2 in the draft recommends that PE3-rs (in Figure.5
in the draft) which is secondary PE-rs may

	send out a flush message.  Secondary PE-rs is agnostic of
switchover events at MTU-s.  As MTU-s controls VC switchover so MAC
address withdrawal should be initiated by MTU-s.

	
	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.

	Primary PE-rs shouldn't initiate MAC withdrawal on VC failure.
Think about a case when primary VC from MTU-s fails and secondary VC
from MTU-s to the secondary PE-rs is also down. In that case anyway
traffic from MTU-s won't get re-learned by secondary PE-rs and/or other
PEs. So the traffic will be permanently black holed and initiating MAC
withdraw by primary PE-rs is not necessary. So the MAC withdraw is sent
only when secondary VC is made active at MTU-s. MTU-s initiates MAC
withdraw as it is the device that decides switching over to secondary
VC.

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

	In this draft we have extended the MAC withdraw method
recommended by VPLS-LDP draft. We have kept provisions for both MTU-s
initiated MAC withdraw as well as PE-rs initiated MAC withdraw in the
extension. There could be other applications/scenarios of MAC withdraw
where PE-rs may need to trigger withdrawal. 

	The 01 version is available at:
http://tools.ietf.org/wg/l2vpn/draft-pdutta-l2vpn-vpls-ldp-mac-opt-01.tx
t

	Which option is preferred?

	Thanks for any help.  
	Asaf Henig
	MRV communications

---

From: [email-masked]
Date: Tue, 26 Sep 2006 13:05:49 -0400

Ali and Pranjal,

That being the case, the generalized MAC-Withdraw for a set of specified
addresses as described in the draft seems to be overkill.

Unless there is a demonstrated case for it, we probably should not require
this subset case. A "flush" implies all learned addresses on a VSI are
purged, which is relatively simple to signal and to implement. It sounds
like MAC-Withdraw should be used only for flushing.

Also if the primary reason for MAC-Withdraw is dual-homing, then why is
dual homing only partially specified in the draft? I'd rather see a
standardized way to quickly detect that a path has failed. Hardware
detection is quick enough, but is only one failure scenario. A lightweight
protocol could be specified to achieve this (as opposed to, for example,
running RSTP on the dual-homed links.) Any thoughts on this?

Regards,
Anil

                    "Ali Sajassi                                                                                   
                    \(sajassi\)"         To:     "Dutta, Pranjal" <[email-masked]>, "Asaf Henig"         
                    <sajassi@cisco        <[email-masked]>, <[email-masked]>                                       
                    .com>                cc:                                                                       
                                         Subject:     RE: [mpls] Question regarding MAC Withdrawal in H-VPLS       
                    09/26/2006            Dual-homedMTU-s                                                          
                    12:22 PM                                                                                       

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

-Ali

 Asaf,

 Thanks,
 Pranjal

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

 Section 10.2.2 in the draft recommends that PE3-rs (in Figure.5 in the
 draft) which is secondary PE-rs may

 send out a flush message.  Secondary PE-rs is agnostic of switchover
 events at MTU-s.  As MTU-s controls VC switchover so MAC address
 withdrawal should be initiated by MTU-s.

 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.

 Primary PE-rs shouldn't initiate MAC withdrawal on VC failure. Think about
 a case when primary VC from MTU-s fails and secondary VC from MTU-s to the
 secondary PE-rs is also down. In that case anyway traffic from MTU-s won't
 get re-learned by secondary PE-rs and/or other PEs. So the traffic will be
 permanently black holed and initiating MAC withdraw by primary PE-rs is
 not necessary. So the MAC withdraw is sent only when secondary VC is made
 active at MTU-s. MTU-s initiates MAC withdraw as it is the device that
 decides switching over to secondary VC.

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

 In this draft we have extended the MAC withdraw method recommended by
 VPLS-LDP draft. We have kept provisions for both MTU-s initiated MAC
 withdraw as well as PE-rs initiated MAC withdraw in the extension. There
 could be other applications/scenarios of MAC withdraw where PE-rs may need
 to trigger withdrawal.

 The 01 version is available at:
 http://tools.ietf.org/wg/l2vpn/draft-pdutta-l2vpn-vpls-ldp-mac-opt-01.txt

 Thanks for any help.
 Asaf Henig
 MRV communications

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Tue, 26 Sep 2006 10:47:33 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, September 26, 2006 10:06 AM
> To: Ali Sajassi (sajassi)
> Cc: Asaf Henig; [email-masked]; Dutta, Pranjal
> Subject: RE: [mpls] Question regarding MAC Withdrawal in 
> H-VPLS Dual-homedMTU-s
> 
> 
> Ali and Pranjal,
> 
> That being the case, the generalized MAC-Withdraw for a set 
> of specified addresses as described in the draft seems to be overkill.
> 
> Unless there is a demonstrated case for it, we probably 
> should not require this subset case. A "flush" implies all 
> learned addresses on a VSI are purged, which is relatively 
> simple to signal and to implement. It sounds like 
> MAC-Withdraw should be used only for flushing.

I would say that flushing MAC addresses should be the mandatory
requirements and purging specific set of addresses should be optional.

> 
> Also if the primary reason for MAC-Withdraw is dual-homing, 
> then why is dual homing only partially specified in the 
> draft? I'd rather see a standardized way to quickly detect 
> that a path has failed. Hardware detection is quick enough, 
> but is only one failure scenario. A lightweight protocol 
> could be specified to achieve this (as opposed to, for 
> example, running RSTP on the dual-homed links.) Any thoughts on this?

Yes, detection can be done using hardware failure detection, BFD, etc. I
guess couple of sentences can be added to the draft to this effect.

-Ali

> 
> Regards,
> Anil
> 
> 
> 
> 
>                                                               
>                                                      
>                     "Ali Sajassi                              
>                                                      
>                     \(sajassi\)"         To:     "Dutta, 
> Pranjal" <[email-masked]>, "Asaf Henig"         
>                                          Subject:     RE: 
> [mpls] Question regarding MAC Withdrawal in H-VPLS       
> 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)
> In the next rev. of vpls-ldp draft, the above clarification 
> should be reflected.
> 
> -Ali
> 
> 
> 
>  Subject: RE: [mpls] Question regarding MAC Withdrawal in 
> H-VPLS  Dual-homedMTU-s
> 
>  Asaf,
> 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.
> 
> 
> switchover  events at MTU-s.  As MTU-s controls VC switchover 
> so MAC address  withdrawal should be initiated by MTU-s.
> 
> 
> 
> 
> 
> 
> 
> 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 
>  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.
> 
> 
>  Primary PE-rs shouldn't initiate MAC withdrawal on VC 
> failure. Think about  a case when primary VC from MTU-s fails 
> and secondary VC from MTU-s to the  secondary PE-rs is also 
> down. In that case anyway traffic from MTU-s won't  get 
> re-learned by secondary PE-rs and/or other PEs. So the 
> traffic will be  permanently black holed and initiating MAC 
> withdraw by primary PE-rs is  not necessary. So the MAC 
> withdraw is sent only when secondary VC is made  active at 
> MTU-s. MTU-s initiates MAC withdraw as it is the device that  
> 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  
> recommended by  VPLS-LDP draft. We have kept provisions for 
> both MTU-s initiated MAC  withdraw as well as PE-rs initiated 
> MAC withdraw in the extension. There  could be other 
> applications/scenarios of MAC withdraw where PE-rs may need  
> to trigger withdrawal.
> 
>

---

From: "Dutta, Pranjal" <[email-masked]>
Date: Wed, 27 Sep 2006 10:12:52 +0530

Anil,
        Please refer inline my answer.   

Thanks,
Pranjal      

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, 26 September, 2006 10:36 PM
To: Ali Sajassi (sajassi)
Cc: Asaf Henig; [email-masked]; Dutta, Pranjal
Subject: RE: [mpls] Question regarding MAC Withdrawal in H-VPLS
Dual-homedMTU-s

Ali and Pranjal,

Unless there is a demonstrated case for it, we probably should not
require
this subset case. A "flush" implies all learned addresses on a VSI are
purged, which is relatively simple to signal and to implement. It sounds
like MAC-Withdraw should be used only for flushing.

detection is quick enough, but is only one failure scenario. A
lightweight

[Pranjal] <snip> Dual homing needn't be the primary reason of MW, there
could be other instances of topology changes where MW could be
applicable (as Ali has explained MW is modeled after IEEE flushing
mechanism). In the further extension of MW that we have proposed we have
provisions for both MTU-s and PE-rs initiated MAC withdraw which could
be applied in other scenerios that may require a MAC withdraw generation
(like TCN snooping, or BFD/RSTP triggered withdraws when BFD/RSTP is
used on dual homed links).
</snip>

Regards,
Anil

                    "Ali Sajassi

                    \(sajassi\)"         To:     "Dutta, Pranjal"
<[email-masked]>, "Asaf Henig"         
                    <sajassi@cisco        <[email-masked]>,
<[email-masked]>                                       
                    .com>                cc:

                                         Subject:     RE: [mpls]
Question regarding MAC Withdrawal in H-VPLS       
                    09/26/2006            Dual-homedMTU-s

                    12:22 PM

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

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.

-Ali

 Asaf,

 Thanks,
 Pranjal

 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.

 PE-rs should flush the relevant previously learned MAC addresses. For
that

 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.

 Primary PE-rs shouldn't initiate MAC withdrawal on VC failure. Think
about
 a case when primary VC from MTU-s fails and secondary VC from MTU-s to
the
 secondary PE-rs is also down. In that case anyway traffic from MTU-s
won't
 get re-learned by secondary PE-rs and/or other PEs. So the traffic will
be
 permanently black holed and initiating MAC withdraw by primary PE-rs is
 not necessary. So the MAC withdraw is sent only when secondary VC is
made
 active at MTU-s. MTU-s initiates MAC withdraw as it is the device that
 decides switching over to secondary VC.

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

 In this draft we have extended the MAC withdraw method recommended by
 VPLS-LDP draft. We have kept provisions for both MTU-s initiated MAC
 withdraw as well as PE-rs initiated MAC withdraw in the extension.
There
 could be other applications/scenarios of MAC withdraw where PE-rs may
need
 to trigger withdrawal.

 Thanks for any help.
 Asaf Henig
 MRV communications