[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PWE3] [L2VPN] RE: new draft - Extension to LDP-VPLS forEthernetbroadcast &multicast
On Mar 11, 2010, at 6:44 PM, BALUS Florin wrote:
>
> On the other hand do we need a full draft on the LDP VPLS with no BGP-AD
> case? Why not include a brief chapter summarizing the text of this draft
> in the existing WG draft on the subject: i.e.
> draft-ietf-l2vpn-vpls-mcast-06.txt?
>
That was my original suggestion, since there really are no protocol extensions in this draft, only device behavior. All of the MAC learning behavior in this draft is covered in section 15 of the above, including the unknown-unicast behavior. The above draft would need to be augmented to allow the case of static mapping of broadcast/multicast/unknown-unicast to an inclusive P2MP tree, which could be either RSVP-TE,mLDP, or P2MP PW based.
Phil
>
>> -----Original Message-----
>> From: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org] On Behalf
>> Of Samer Salam (ssalam)
>> Sent: Thursday, March 11, 2010 11:59 AM
>> To: list_work at beckhaus-net.de
>> Cc: l2vpn at ietf.org; Olen Stokes; Ali Sajassi (sajassi); pwe3
>> Subject: RE: [PWE3] [L2VPN] RE: new draft - Extension to LDP-VPLS
>> forEthernetbroadcast &multicast
>>
>>
>>> Could there be another reason to prevent the distribution of unknown
>>> unicast frames via the established P2MP tree?
>>
>> 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.
>>
>> 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
> _______________________________________________
> pwe3 mailing list
> pwe3 at ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3