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

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

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