Subject: new draft - Extension to LDP-VPLS for Ethernet broadcast & multicast

From: Simon Delord <[email-masked]>
Date: Tue, 2 Mar 2010 16:12:43 +1100

Hi L2VPN & PWE3 workgroups,

There is a new internet draft - Extension to LDP-VPLS for Ethernet 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-exten-00>)
.

Our proposed approach relies on a simple extension to LDP-VPLS to optimise
Ethernet Multicast/Broadcast traffic within a carrier's network. It allows
the use of unidirectional point-to-multipoint PseudoWires to minimise
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/multicast traffic
when using VPLS.

- whether carriers with LDP-VPLS (RFC 4762) would like to consider a
solution that does not require BGP.

Thanks a lot.

Simon

---

From: [email-masked]
Date: Tue, 02 Mar 2010 14:08:52 +0800 (SGT)

Simon,

I have a quick read on the document. On Figure 1 in the document, are the 4 PE nodes connected in a ring? I would presume so, since the chances of multiple PWE going through common LSP path is higer in a ring topology than any other topologies.

/Max
---  wrote:

There is a new internet draft - Extension to LDP-VPLS for Ethernetbroadcast
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-exten-00>)
.

Our proposed approach relies on a simple extension to LDP-VPLS tooptimise
Ethernet Multicast/Broadcast traffic within a carrier's network. Itallows
the use of unidirectional point-to-multipoint PseudoWires tominimise
payload frame duplication on physical links.

- 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
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Simon Delord <[email-masked]>
Date: Wed, 3 Mar 2010 13:54:51 +1100

Bonjour Max,

Thanks for the input.
The intent of this document is to use P2MP PW selectively only when it can
help with bandwidth optimisation (e.g where multiple PWs go through a common
physical path).
This is intrinsically linked to the physical topology.

A ring topology, like you are suggesting is a good example where such
optimisation may be beneficial.
Other physical topologies (like a physical tree structure where a network
element is an
aggregation point for other network elements) may also benefit from the use
of P2MP PWs.

We will add more details in the next version of the document on this point.

How about the two questions:
- do you see a need to optimise Ethernet broadcast/multicast traffic when
using VPLS?
- would carriers with LDP-VPLS (RFC 4762) consider a solution that does not
require BGP?

cheers,
Simon

2010/3/2 <[email-masked]>

> Simon,
>
> I have a quick read on the document. On Figure 1 in the document, are the 4
> PE nodes connected in a ring? I would presume so, since the chances of
> multiple PWE going through common LSP path is higer in a ring topology than
> any other topologies.
>
> /Max
> ---  wrote:
> http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-00*
> <http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-00
> >)
>  .
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 03 Mar 2010 12:15:43 -0600

Simon, 

Your draft proposes to create parallel P2MP trees in addition to already
existed P2P LSPs just for the Multicast and broadcast traffic. IEEE802.1ak
(MMRP) allows many multicast groups to be formed (or changed) automatically.
Does it mean that each PE node has to create a new P2MP tree when a new
Multicast group is created? It is a lot of processing on each PE. Each PE is
to process the 802.ak protocol to create/delete new P2MP trees and
add/remove branches. 

It is a lot of effort for the benefit. I think a better approach is to let
each PE be aware of the 802.1ak protocol so that each PE can select the
relevant P2P LSPs (subset of entire LSPs) for each Multicast group. Are you
interested in pursuing in this direction? If yes, I can put together a draft
to outline the basic approach. 

Linda Dunbar

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Simon Delord
Sent: Monday, March 01, 2010 11:13 PM
To: [email-masked]; pwe3
Cc: [email-masked]
Subject: new draft - Extension to LDP-VPLS for Ethernet broadcast &
multicast

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-exten-00) .

Thanks a lot.

Simon

---

From: Simon Delord <[email-masked]>
Date: Thu, 4 Mar 2010 10:47:44 +1100

Hello Linda,

The answer to your question is No. Our draft is not proposing any multicast
membership control to RFC4762 VPLS. There is always single coverage of
receiver membership, no differentiation for multiple multicast groups.

Our draft proposes to use P2MP PWs in addition to the existing P2P PWs for
VPLS for all Ethernet broadcast and multicast traffic independently of any
type of multicast membership control/protocol associated with it.

How about the two questions, what do you think?

regards,

Simon

2010/3/4 Linda Dunbar <[email-masked]>

>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Simon Delord
> *Sent:* Monday, March 01, 2010 11:13 PM
>
> *To:* [email-masked]; pwe3
> *Cc:* [email-masked]
> *Subject:* new draft - Extension to LDP-VPLS for Ethernet broadcast &
> multicast
>
>
>
> There is a new internet draft - Extension to LDP-VPLS for Ethernet
> broadcast and multicast (
>

---

From: Phil Bedard <[email-masked]>
Date: Thu, 4 Mar 2010 14:55:31 -0500

On Mar 3, 2010, at 1:15 PM, Linda Dunbar wrote:

> Simon,
>  
> Your draft proposes to create parallel P2MP trees in addition to already existed P2P LSPs just for the Multicast and broadcast traffic. IEEE802.1ak (MMRP) allows many multicast groups to be formed (or changed) automatically. Does it mean that each PE node has to create a new P2MP tree when a new Multicast group is created? It is a lot of processing on each PE. Each PE is to process the 802.ak protocol to create/delete new P2MP trees and add/remove branches.

This is one of the issues with the next-gen multicast L3VPN operating in a selective non-aggregate mode today, only the signaling protocol for multicast membership is IGMP/PIM and not 802.1ak.  You can end up with thousands of P2MP LSPs based on the receiver sites and the groups they receive.  
  
However this draft is not solving RFC 5501 Issue A which is dynamic membership of (S,G) within a VPLS service, it's solving issue B which is traffic duplication.  It is assumed all member sites belong to the same inclusive P-Multicast tree.  I would make this more apparent in the draft.   I think the content of the draft is valid but may be better as part of a document covering both inclusive and selective use cases.   

>  
> It is a lot of effort for the benefit. I think a better approach is to let each PE be aware of the 802.1ak protocol so that each PE can select the relevant P2P LSPs (subset of entire LSPs) for each Multicast group. Are you interested in pursuing in this direction? If yes, I can put together a draft to outline the basic approach.

Unless my understanding of 802.1ak is incorrect I don't think it helps with traffic duplication the way VPLS is generally deployed today, at least not as shown in this draft's VPLS model.   Unless hierarchy is being used the PWs are deployed in a full mesh and split horizon ensures looping does not occur.  If I had four nodes in a ring the root node would still have  PWs built to the other three nodes.  If all three wanted to receive the same multicast traffic the 802.1ak function on the root would still use all three PWs for outbound traffic.  For 802.1ak MMRP to work the VPLS service would have to emulate a bridge where broadcast/multicast traffic is flooded out all PWs.  STP would have to run within the service to ensure looping did not occur. 

This is where we need both the construction of P2MP LSP/PW for packet transport and a signaling protocol like 802.1ak or BGP to build the selective trees.    

Phil 

>  
> Linda Dunbar
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Delord
> Subject: new draft - Extension to LDP-VPLS for Ethernet broadcast & multicast
>  
> There is a new internet draft - Extension to LDP-VPLS for Ethernet broadcast and multicast (
> 
> Our proposed approach relies on a simple extension to LDP-VPLS to optimise Ethernet Multicast/Broadcast traffic within a carrier's network. It allows the use of unidirectional point-to-multipoint PseudoWires to minimise 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/multicast traffic when using VPLS.
> 
> - whether carriers with LDP-VPLS (RFC 4762) would like to consider a solution that does not require BGP.
> 
> Thanks a lot.
> 
> Simon
>

---

From: "Thomas Beckhaus" <[email-masked]>
Date: Mon, 8 Mar 2010 10:33:16 +0100

Simon,

your ID provides a solution for the efficient propagation of Ethernet broadcast and multicast ethernet frames. Is there any reason, why you have not mentioned the distribution of unknown unicasts via this P2MP tree (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 
  To: [email-masked] ; pwe3 
  Sent: Tuesday, March 02, 2010 6:12 AM
  Subject: [PWE3] new draft - Extension to LDP-VPLS for Ethernet broadcast &multicast

  Thanks a lot.

  Simon

------------------------------------------------------------------------------

---

From: Simon Delord <[email-masked]>
Date: Wed, 10 Mar 2010 14:15:00 +1100

Bonjour Thomas,

Our current thinking is that unknown unicast frames should be handled as per
RFC 4762 (e.g flooded on the P2P PWs). What do you think?

BTW, any feedback on the following two questions:

Thanks,

Simon

2010/3/8 Thomas Beckhaus <[email-masked]>

>  Simon,
>
> your ID provides a solution for the efficient propagation of Ethernet
> broadcast and multicast ethernet frames. Is there any reason, why you have
> not mentioned the distribution of unknown unicasts via this P2MP tree
> (the required MAC learning by the leaf is mentioned in your ID) ? Or is it
> implicit by your understanding of "broadcast"?
>
> Thomas Beckhaus
>
> *From:* Simon Delord <[email-masked]>
> *To:* [email-masked] ; pwe3 <[email-masked]>
>   *Sent:* Tuesday, March 02, 2010 6:12 AM
> *Subject:* [PWE3] new draft - Extension to LDP-VPLS for Ethernet broadcast
> &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-exten-00>)
> .
>

---

From: [email-masked]
Date: Wed, 10 Mar 2010 15:20:03 +0800 (SGT)

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?

Thanks,

Simon

>  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
> *Subject:* [PWE3] new draft - Extension to LDP-VPLS for Ethernetbroadcast
> &multicast
>
> There is a new internet draft - Extension to LDP-VPLS forEthernet
> Ethernet Multicast/Broadcast traffic within a carrier's network.It allows
> The authors would like to solicit comments from the workgroups.In
> particular,
>

---

From: Olen Stokes <[email-masked]>
Date: Wed, 10 Mar 2010 05:05:56 -0800

What is the reason that unknown unicast frames would not use the P2MP PWs?

Cheers,
Olen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 10, 2010 2:20 AM
To: Simon Delord
Cc: [email-masked]; pwe3
Subject: Re: [PWE3] new draft - Extension to LDP-VPLS for Ethernet broadcast &multicast

Simon,

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

- 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

> 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
>
> *Subject:* [PWE3] new draft - Extension to LDP-VPLS for 
> Ethernetbroadcast &multicast
>
> 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.
>
> - whether there is a need to optimise Ethernet 
> broadcast/multicasttraffic when using VPLS.
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 10 Mar 2010 09:37:46 -0800

Broadcast, multicast and unknown unicast should all use P2MP PWs in case
of aggregate inclusive and selective trees and the learning should be
done over these trees (and P2MP PWs) and associate them with the
corresponding P2P PWs. 

Cheers,
Ali

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Olen Stokes
> Sent: Wednesday, March 10, 2010 5:06 AM
> To: [email-masked]'; Simon Delord
> Cc: [email-masked]; pwe3
> Subject: Re: [PWE3] new draft - Extension to LDP-VPLS for
> 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?
> 
> >*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>)
> > .
> >

---

From: Phil Bedard <[email-masked]>
Date: Wed, 10 Mar 2010 13:34:51 -0500

From an implementation and forwarding plane/replication perspective, it would be better to have all three types use the same P2MP PW.  With current implementations which support P2MP RSVP tunnels for these types of traffic, they cover all three.  

Phil 

On Mar 9, 2010, at 10:15 PM, Simon Delord wrote:

> Bonjour Thomas,
> 
> Our current thinking is that unknown unicast frames should be handled as per RFC 4762 (e.g flooded on the P2P PWs). What do you think?
>

---

From: [email-masked]
Date: Thu, 11 Mar 2010 22:14:40 +0800 (SGT)

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 <[email-masked]> wrote:

> broadcast and multicast use the p2mp PW, while unicast and unknown
> unicast uses the p2p PW.
> 
> 
> /Max
> ---  wrote:
> Bonjour Thomas,
> 
> as per RFC 4762 (e.g flooded on the P2P PWs). What do you think?
>

---

From: Phil Bedard <[email-masked]>
Date: Thu, 11 Mar 2010 10:03:45 -0500

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

---

From: Olen Stokes <[email-masked]>
Date: Thu, 11 Mar 2010 07:11:48 -0800

That was my take as well.  

Cheers,
Olen

-----Original Message-----
From: Phil Bedard [mailto:[email-masked]] 
Sent: Thursday, March 11, 2010 10:04 AM
To: [email-masked]
Cc: Olen Stokes; [email-masked]; pwe3
Subject: Re: [PWE3] new draft - Extension to LDP-VPLS for Ethernet broadcast &multicast

Phil

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 11 Mar 2010 09:20:27 -0800

MAC learning needs to be performed for multicast and broadcast frames
that are sent over P2MP PWs and unknown unicast handling is no
different. The leaf PE will learn the MAC SA and associate it with the
corresponding P2P PW (associated with that VPLS instance and the root
PE).

There is no reason for handling unknown unicast frames differently.

-Ali

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

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 11 Mar 2010 09:22:42 -0800

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

Of
> Olen Stokes
> Sent: Thursday, March 11, 2010 7:12 AM
> To: 'Phil Bedard'; [email-masked]
> Cc: [email-masked]; pwe3
> 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.
don't
> let the VSI takes time to learn.
> >
> > regards,
> > Max

---

From: Olen Stokes <[email-masked]>
Date: Thu, 11 Mar 2010 09:40:37 -0800

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:[email-masked]] 
Sent: Thursday, March 11, 2010 12:23 PM
To: Olen Stokes; Phil Bedard; [email-masked]
Cc: [email-masked]; pwe3
Subject: RE: [PWE3] new draft - Extension to LDP-VPLS for Ethernet broadcast &multicast
Importance: Low

What ? :-)

Cheers,
Ali

Of
it
don't

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 11 Mar 2010 10:19:36 -0800

Olen, thanks for the clarification. We are in synch.

Cheers,
Ali

> From: Olen Stokes [mailto:[email-masked]]
> Sent: Thursday, March 11, 2010 9:41 AM
> To: Ali Sajassi (sajassi); Phil Bedard; [email-masked]
> Cc: [email-masked]; pwe3
> 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.
Ethernet
> > >> broadcast &multicast

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 11 Mar 2010 19:37:12 +0100

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

---

From: "Samer Salam (ssalam)" <[email-masked]>
Date: Thu, 11 Mar 2010 11:58:49 -0800

>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

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>[email-masked]
>Sent: Thursday, March 11, 2010 10:37 AM
>To: Olen Stokes
>Cc: [email-masked]; 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
>
>unicast packets.  Therefore, unknown unicast packets could be sent over
>the P2MP PWs.
>>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 11 Mar 2010 14:01:08 -0800

> 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

> >>> receiving node to associate a SMAC coming in the P2MP PW with a
P2P
> >PW

---

From: "BALUS Florin" <[email-masked]>
Date: Thu, 11 Mar 2010 17:44:58 -0600

I think it is an implementation matter to give access to P2MP LSP to any
of the traffic categories mentioned below. I agree though there is no
reason to exclude unknown unicast.

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?

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Samer Salam (ssalam)
> Sent: Thursday, March 11, 2010 11:59 AM
> To: [email-masked]
> Cc: [email-masked]; Olen Stokes; Ali Sajassi (sajassi); pwe3
> Subject: RE: [PWE3] [L2VPN] RE: new draft - Extension to LDP-VPLS
> forEthernetbroadcast &multicast
> 
> 
> frames
P2P

---

From: Phil Bedard <[email-masked]>
Date: Thu, 11 Mar 2010 21:02:56 -0500

> 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

---

From: Yong Lucy <[email-masked]>
Date: Fri, 12 Mar 2010 11:23:50 -0600

It is good to have a unique way to handle all (bdct/mtct and unknown
unicast). Today, many packet applications at the host has buffer to deal
with packet disorder such as lost packet retransmission. Thus, seldom
out-of-order is no longer a problem for packet applications. 
Lucy

> Ali Sajassi (sajassi)
> Sent: Thursday, March 11, 2010 4:01 PM
> To: Samer Salam (ssalam); [email-masked]
> Cc: [email-masked]; Olen Stokes; pwe3