From: Lizhong Jin
[mailto:lizhong.jin at zte.com.cn]
Sent: Tuesday, February 07, 2012 11:51 PM
To: Balus, Florin Stelian (Florin)
Cc: geraldine.calvignac at orange-ftgroup.com; l2vpn at ietf.org;
ostokes at extremenetworks.com; 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)"
<florin.balus at alcatel-lucent.com> wrote 2012/02/07 23:51:55:
> Lizhong,
> See in-line…
>
> From: Lizhong Jin [mailto:lizhong.jin at zte.com.cn]
> Sent: Tuesday, February 07, 2012 12:45 AM
> To: Dutta, Pranjal K (Pranjal); Balus, Florin Stelian (Florin);
> geraldine.calvignac at orange-ftgroup.com; ostokes at extremenetworks.com
> Cc: l2vpn at ietf.org
> 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.
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.
>
>
> 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.