[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PWE3] new draft - Extension to LDP-VPLS for Ethernet broadcast &multicast



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