Subject: Comments of draft-ietf-l2vpn-vpls-ldp-mac-opt-05

From: Lizhong Jin<[email-masked]>
Date: Tue, 7 Feb 2012 16:45:02 +0800

Hi authors,
Since v04 of this draft, the PE-ID TLV has been removed and replaced by 
MAC Flush Parameters TLV. In section 4.1.1, it says "The source (mine/me) 
is defined either as the PW associated with the LDP session on which the 
LDP MAC Withdraw was received or with the BMAC(s) listed in the BMAC 
Sub-TLV". That means the MAC flushing associated PW endpoint address is 
fixed with the sending PE.
In some cases, it may be useful for a PE to send MAC withdraw with other 
source endpoint address of other PW. E.g, in a dual-homed scenario in 
figure 5 of RFC4762, if the PE1-rs with primary PW is down, the PE3-rs 
with secondary PW could send MAC withdraw with PE1-rs address, to tell 
other PE-rs to flush all MAC address from PE1-rs.

Hope to see your comments.

Thanks
Lizhong

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Tue, 7 Feb 2012 09:51:55 -0600

Lizhong,
See in-line...

From: Lizhong Jin [mailto:[email-masked]]
Sent: Tuesday, February 07, 2012 12:45 AM
To: Dutta, Pranjal K (Pranjal); Balus, Florin Stelian (Florin); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Comments of draft-ietf-l2vpn-vpls-ldp-mac-opt-05

Hi authors,
Since v04 of this draft, the PE-ID TLV has been removed and replaced by MAC Flush Parameters TLV. In section 4.1.1, it says "The source (mine/me) is defined either as the PW associated with the LDP session on which the LDP MAC Withdraw was received or with the BMAC(s) listed in the BMAC Sub-TLV".
That means the MAC flushing associated PW endpoint address is fixed with the sending PE.
In some cases, it may be useful for a PE to send MAC withdraw with other source endpoint address of other PW. E.g, in a dual-homed scenario in figure 5 of RFC4762, if the PE1-rs with primary PW is down, the PE3-rs with secondary PW could send MAC withdraw with PE1-rs address, to tell other PE-rs to flush all MAC address from PE1-rs.

FB> If PE1-rs is down the other PEs in the mesh will know about it in a number of ways: their tunnel/PW to PE1-rs will be down/nexthop tracking (IGP) will indicate PE1-rs is gone etc... As a result everybody will flush their MAC addresses from PE1 anyhow. If another PE sends the MAC Flush it will increase the flooding time by doing an unnecessary second flush.

Thanks
Lizhong

---

From: Lizhong Jin<[email-masked]>
Date: Wed, 8 Feb 2012 15:51:24 +0800

Florin,
Thanks for the reply, see inline below.

Regards
Lizhong

"Balus, Florin Stelian (Florin)" <[email-masked]> wrote 
2012/02/07 23:51:55:

> See in-line…
> To: Dutta, Pranjal K (Pranjal); Balus, Florin Stelian (Florin); 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Since v04 of this draft, the PE-ID TLV has been removed and replaced
> by MAC Flush Parameters TLV. In section 4.1.1, it says "The source 
> (mine/me) is defined either as the PW associated with the LDP 
> session on which the LDP MAC Withdraw was received or with the 
> BMAC(s) listed in the BMAC Sub-TLV". 
> In some cases, it may be useful for a PE to send MAC withdraw with 
> other source endpoint address of other PW. E.g, in a dual-homed 
> scenario in figure 5 of RFC4762, if the PE1-rs with primary PW is 
> down, the PE3-rs with secondary PW could send MAC withdraw with PE1-
> rs address, to tell other PE-rs to flush all MAC address from PE1-rs. 
> 
> FB> If PE1-rs is down the other PEs in the mesh will know about it 
> in a number of ways: their tunnel/PW to PE1-rs will be down/nexthop 
> tracking (IGP) will indicate PE1-rs is gone etc… As a result 
> everybody will flush their MAC addresses from PE1 anyhow. If another
> PE sends the MAC Flush it will increase the flooding time by doing 
> an unnecessary second flush.
[Lizhong] The precondition is that there is OAM running between PE1-rs and 
other PEs. If there is no OAM, it has to rely on LDP session timeout or 
IGP convergence which maybe a bit slow. In many cases, PE3-rs will know 
the failure of primary PW faster than other PE-rs. What's more, in 
RFC4762, PE3-rs will always send MAC withdraw with empty MAC list whatever 
PE1-rs is down or not (PE3-rs will send withdraw when second PW from 
standby to active), which worse the situation.
One more useful scenario is CE multihoming with ICCP deployed, the standby 
PE would know the primary PE failure faster than other PE, and it would be 
better for original standby PE to send MAC withdraw with failed PE 
address, instead of MAC withdraw with empty list.

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Fri, 10 Feb 2012 15:47:22 -0600

Lizhong,

From: Lizhong Jin [mailto:[email-masked]]
Sent: Tuesday, February 07, 2012 11:51 PM
To: Balus, Florin Stelian (Florin)
Cc: [email-masked]; [email-masked]; [email-masked]; Dutta, Pranjal K (Pranjal)
Subject: RE: Comments of draft-ietf-l2vpn-vpls-ldp-mac-opt-05

Florin,

"Balus, Florin Stelian (Florin)" <[email-masked]> wrote 2012/02/07 23:51:55:
> tracking (IGP) will indicate PE1-rs is gone etc... As a result
[Lizhong] The precondition is that there is OAM running between PE1-rs and other PEs. If there is no OAM, it has to rely on LDP session timeout or IGP convergence which maybe a bit slow. In many cases, PE3-rs will know the failure of primary PW faster than other PE-rs. What's more, in RFC4762, PE3-rs will always send MAC withdraw with empty MAC list whatever PE1-rs is down or not (PE3-rs will send withdraw when second PW from standby to active), which worse the situation.
FB>I think you are saying that there will be problems if both MAC Withdraw behaviors are active which is true. Definitely only one type of MAC Withdraw should be used for a certain Multi-homing relation. We have the positive/negative flag indication to differentiate between them. The procedure in RFC 4762 is the default one, the negative MAC Flush can be activated as an alternative.

One more useful scenario is CE multihoming with ICCP deployed, the standby PE would know the primary PE failure faster than other PE, and it would be better for original standby PE to send MAC withdraw with failed PE address, instead of MAC withdraw with empty list.
FB> Whether it is faster or not depends really on which failure scenarios are considered the most common. If the active link fails the PE that owns the failed link will know right away so the current procedure in the draft is faster. This was one of the use cases I heard more often justifying the need for negative MAC Flush. Even in the PE failure case the next hop tracking in IGP can be quite fast, not to speak about OAM CCMs.