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

From: Lizhong Jin<[email-masked]>
Date: Sat, 7 Apr 2012 14:49:31 +0800

Hi Florin,
Sorry for the late reply, please see inline.

Thanks
Lizhong

"Balus, Florin Stelian (Florin)" <[email-masked]> wrote 
2012/02/11 05:47:22:

> 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, 
> Thanks for the reply, see inline below. 
> Regards 
> Lizhong 
> 
> "Balus, Florin Stelian (Florin)" <[email-masked]> 
> wrote 2012/02/07 23:51:55:
> > 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. 
> [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. 
[Lizhong] draft-ietf-l2vpn-vpls-ldp-mac-opt does not say anything about 
the MAC withdraw capability negotiation. In CE multihoming scenario, both 
PEs will send MAC withdraw message. 
draft-liu-l2vpn-vpls-inter-domain-redundancy defines the MAC withdraw 
capability negotiation in ICCP case. One more benefit of negative MAC 
Flush with PE-ID TLV is when PE1-rs does not support negative capability, 
then PE3-rs could send negative MAC withdraw with PE1-rs ID TLV, to 
optimize MAC flush.

> 
> 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. 
[Lizhong] IGP tracking is not always there, especially in MPLS-TP network 
in backhaul. Take the scenario in 
draft-liu-l2vpn-vpls-inter-domain-redundancy for example, usually BFD will 
be deployed between active and standby PE, and standby PE would sense the 
failure of active PE much faster. Moreover, what if the original active PE 
does not support negative capability, then let the original standby PE to 
send negative MAC withdraw with PE-ID TLV would optimize MAC flush.

> > 
> > 
> > Hope to see your comments. 
> > 
> > Thanks 
> > Lizhong 
> > 
> > 
> > 
> > 
>