[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PWE3] [L2VPN] RE: new draft - Extension to LDP-VPLS for Ethernet broadcast &multicast
For my understanding, the need to install the P2MP tree is primary driven by the distribution of broadcast and multicast frames and not because of the efficient propagation of unknown unicast (at least in most situation). But if there is a P2MP tree, it should also be used for unknown unicast frames, because there is no additional feature required to integrate them (the receiving PE has to learn the source MAC address anyway). But this in not a protocol issue.
Could there be another reason to prevent the distribution of unknown unicast frames via the established P2MP tree? I do not see any good reason.
Thomas
Am 11.03.2010 um 18:40 schrieb Olen Stokes:
> Sorry. "My take" is that learning from the P2MP PW is already a requirement so that is not a valid reason to prohibit learning on unicast packets. Therefore, unknown unicast packets could be sent over the P2MP PWs.
>
> I guess that I am doing a poor job of agreeing with you, Ali.
>
> Cheers,
> Olen
>
> -----Original Message-----
> From: Ali Sajassi (sajassi) [mailto:sajassi at cisco.com]
> Sent: Thursday, March 11, 2010 12:23 PM
> To: Olen Stokes; Phil Bedard; mngpl at singnet.com.sg
> Cc: l2vpn at ietf.org; pwe3
> Subject: RE: [PWE3] new draft - Extension to LDP-VPLS for Ethernet broadcast &multicast
> Importance: Low
>
> What ? :-)
>
> Olen, if it makes sense to you to treat unknown unicast frames
> differently from multicast/broadcast frames, can you share with us your
> reasoning.
>
> Cheers,
> Ali
>
>> -----Original Message-----
>> From: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] On Behalf
> Of
>> Olen Stokes
>> Sent: Thursday, March 11, 2010 7:12 AM
>> To: 'Phil Bedard'; mngpl at singnet.com.sg
>> Cc: l2vpn at ietf.org; pwe3
>> Subject: Re: [PWE3] new draft - Extension to LDP-VPLS for Ethernet
>> broadcast &multicast
>>
>> That was my take as well.
>>
>> Cheers,
>> Olen
>>
>> -----Original Message-----
>> From: Phil Bedard [mailto:bedard.phil at gmail.com]
>> Sent: Thursday, March 11, 2010 10:04 AM
>> To: mngpl at singnet.com.sg
>> Cc: Olen Stokes; l2vpn at ietf.org; pwe3
>> Subject: Re: [PWE3] new draft - Extension to LDP-VPLS for Ethernet
>> broadcast &multicast
>>
>> Section 5.1.2 of the draft specifies the ability for the VSI on the
>> receiving node to associate a SMAC coming in the P2MP PW with a P2P PW
>> back to the originating node. It's a modified learning process, but
> it
>> is covered in the draft.
>>
>> Phil
>>
>>
>> On Mar 11, 2010, at 9:14 AM, mngpl at singnet.com.sg wrote:
>>
>>> Olen,
>>>
>>> Unknown unicast are frame that has not got a learned destinaton MAC
>> address. P2mp PW are uni-directional, so if unknown unicast are send
>> out of p2mp PW, than it might always end up as unlearn, which you
> don't
>> really want. You want the MAC address to be learnt and associate it
>> with the pw.
>>>
>>> So it does make sense to flood the unknown unicast out a p2p PW and
>> let the VSI takes time to learn.
>>>
>>> regards,
>>> Max
>>> --- Olen Stokes <ostokes at extremenetworks.com> wrote:
>>>
>>>> What is the reason that unknown unicast frames would not use the
>>>> P2MP PWs?
>>>>
>>>> Cheers,
>>>> Olen
>>>>
>>>> -----Original Message-----
>>>> From: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org] On
>>>> Behalf Of mngpl at singnet.com.sg
>>>> Sent: Wednesday, March 10, 2010 2:20 AM
>>>> To: Simon Delord
>>>> Cc: l2vpn at ietf.org; pwe3
>>>> Subject: Re: [PWE3] new draft - Extension to LDP-VPLS for Ethernet
>>>> broadcast &multicast
>>>>
>>>> Simon,
>>>>
>>>> If this is the case, some kind of filter needs to ensure only
>>>> broadcast and multicast use the p2mp PW, while unicast and unknown
>>>> unicast uses the p2p PW.
>>>>
>>>>
>>>> /Max
>>>> --- wrote:
>>>> Bonjour Thomas,
>>>>
>>>> Our current thinking is that unknown unicast frames should
> behandled
>>>> as per RFC 4762 (e.g flooded on the P2P PWs). What do you think?
>>>>
>>>> BTW, any feedback on the following two questions:
>>>>
>>>> - whether there is a need to optimise Ethernet
>>>> broadcast/multicasttraffic when using VPLS.
>>>>
>>>> - whether carriers with LDP-VPLS (RFC 4762) would like to considera
>>>> solution that does not require BGP.
>>>>
>>>> Thanks,
>>>>
>>>> Simon
>>>>
>>>>
>>>> 2010/3/8 Thomas Beckhaus <list_work at beckhaus-net.de>
>>>>
>>>>> Simon,
>>>>>
>>>>> your ID provides a solution for the efficient propagation
>>>> ofEthernet
>>>>> broadcast and multicast ethernet frames. Is there any reason,
>>>> whyyou
>>>>> have not mentioned the distribution of unknown unicasts via this
>>>>> P2MPtree (the required MAC learning by the leaf is mentioned in
>>>> your
>>>>> ID) ?Or is it implicit by your understanding of "broadcast"?
>>>>>
>>>>> Thomas Beckhaus
>>>>>
>>>>> ----- Original Message -----
>>>>> *From:* Simon Delord <simon.delord at gmail.com>
>>>>> *To:* l2vpn at ietf.org ; pwe3 <pwe3 at ietf.org>
>>>>> *Sent:* Tuesday, March 02, 2010 6:12 AM
>>>>> *Subject:* [PWE3] new draft - Extension to LDP-VPLS for
>>>>> Ethernetbroadcast &multicast
>>>>>
>>>>> Hi L2VPN & PWE3 workgroups,
>>>>>
>>>>> There is a new internet draft - Extension to LDP-VPLS forEthernet
>>>>
>>>>> broadcast and multicast (
>>>>> *http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-
>> exten
>>>>> -00
>>>>>
> *<http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-
>> exte
>>>>> n-00>)
>>>>> .
>>>>>
>>>>> Our proposed approach relies on a simple extension to LDP-VPLS
>>>>> tooptimise Ethernet Multicast/Broadcast traffic within a carrier's
>>>>
>>>>> network.It allows the use of unidirectional point-to-multipoint
>>>>> PseudoWires tominimise payload frame duplication on physical
>>>> links.
>>>>>
>>>>> The authors would like to solicit comments from the workgroups.In
>>>>
>>>>> particular,
>>>>>
>>>>> - whether there is a need to optimise Ethernet
>>>>> broadcast/multicasttraffic when using VPLS.
>>>>>
>>>>> - whether carriers with LDP-VPLS (RFC 4762) would like to
>>>> considera
>>>>> solution that does not require BGP.
>>>>>
>>>>> Thanks a lot.
>>>>>
>>>>> Simon
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> pwe3 mailing list
>>>>> pwe3 at ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> pwe3 mailing list
>>> pwe3 at ietf.org
>>> https://www.ietf.org/mailman/listinfo/pwe3
>>
>> _______________________________________________
>> pwe3 mailing list
>> pwe3 at ietf.org
>> https://www.ietf.org/mailman/listinfo/pwe3
>