[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PWE3] [L2VPN] RE: new draft - Extension to LDP-VPLS forEthernet broadcast &multicast
>
> If the P2MP tree has links with high latency (or are experiencing
> prolonged queuing due to congestion), then using the P2MP path for
> unknown unicast MAY lead to out-of-order delivery of the Ethernet
> frames if the unknown unicast becomes known to the source, while in
the
> middle of transmitting a given flow. The probability of this happening
> is relatively low, but is not zero. That could be one reason in favor
> of using the p2p path for unknown unicast.
>
Yes, good point but with the same token, we can still have out-of-order
delivery of frames even if we use P2P PWs for unknown unicast; however,
this time, it would be between multicast and unicast traffic. However,
given that both unicast MP2P and multicast P2MP LSPs use the
shortest-path through the network, the likelihood of such out-of-order
delivery should be extremely small. So, I think we should have the same
treatment for unknown unicast frames as we have for multicast/broadcast
frames.
Cheers,
Ali
> Regards,
> Samer
>
>
> >-----Original Message-----
> >From: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] On Behalf
> Of
> >list_work at beckhaus-net.de
> >Sent: Thursday, March 11, 2010 10:37 AM
> >To: Olen Stokes
> >Cc: l2vpn at ietf.org; Ali Sajassi (sajassi); pwe3
> >Subject: Re: [PWE3] [L2VPN] RE: new draft - Extension to LDP-VPLS
> >forEthernet 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
> >>
> >
> >_______________________________________________
> >pwe3 mailing list
> >pwe3 at ietf.org
> >https://www.ietf.org/mailman/listinfo/pwe3