Subject: I-D: Extension to LDP-VPLS for Ethernet broadcast & multicast

From: Raymond Key <[email-masked]>
Date: Sat, 13 Mar 2010 08:19:01 +1100

Thanks for the comments about unknown unicast. I would like to share my 
view with the workgroups.

Our current thinking is that P2MP PW be used for Ethernet broadcast and 
multicast only, and not touch the handling of unknown unicast in existing 
VPLS solutions (i.e. keep it as per RFC4762, flooded on the P2P PWs). 
But actually we don't have strong objection to include unknown unicast in 
the P2MP PW.

The following are some of our considerations that lead to our current thinking.

(1) RFC5501 - Requirements for Multicast Support in Virtual Private LAN Services
     Extract from Section 4.1.1.2. Unknown Destination Unicast
     "Unknown destination MAC unicast requires flooding, but its characteristics 
      are quite different from multicast/broadcast.  When the unicast MAC address
      is learned, the PE changes its forwarding behavior from flooding over all PWs
      into sending over one PW. Thereby, it will require different technical studies
      from multicast/broadcast, which is out of scope of this document."

     Unknown unicast is considered out of scope according to RFC5501.

(2) RFC5501 - Requirements for Multicast Support in Virtual Private LAN Services
     Extract from Section 5.10. Frame Reordering Prevention
     "A solution SHOULD attempt to prevent frame reordering when delivering 
      customer multicast traffic.  Likewise, for unicast and unknown unicast traffic,
      it SHOULD attempt not to increase the likelihood of reordering compared with
      existing VPLS solutions."

     A conservative approach for "not to increase the likelihood of reordering
     compared with existing VPLS solutions" is to keep the handling of unknown
     unicast unchanged.

(3) We are trying to propose a minimal extension to the current standard 
     LDP-VPLS [RFC4762] that is necessary to fulfil the objective of Ethernet
     broadcast/multicast optimisation. Hence in the 00-version, we start with
     minimal, only broadcast/multicast, exclude unknown unicast. Should further
     solution development find it justified to include unknown unicast for a better
     overall solution, we will add that in the future versions.

(4) Ethernet broadcast/multicast can be identified by a specific bit position = 1 in
     the destination MAC address. There is a good chance that such identification
     can be done in hardware, which may lead to better performance. We are not
     sure about the hardware capability of existing VPLS boxes. Input from chip/
     equipment vendors are welcome.

Thanks,
Raymond Key

---

From: <[email-masked]>
Date: Tue, 16 Mar 2010 09:16:48 -0000

Some observations on this topic:

1	Firstly, I think VPLS can't be regarded as anything but a
'tactical/expedient curiosity' simply because the Ethernet layer network
has been functionally coupled to the (already functionally coupled)
IP/MPLS/PW layer network.  This is bad design practice .....which is
tacitly recognised in MPLS-TP (ie decouple IP layer network from MPLS-TP
layer network) but nevertheless these arch violations are still
tolerated as evidenced by PWs (still in MPLS-TP) and of course VPLS.

2	Secondly, BU in Ethernet is all about flooding across *total
topology* (of at least the parent VLAN topology of the MAC address).  A
p2p PW and a p2mp PW are *connections* and also *different instances* of
connections in a *server* PW layer network......which by definition only
represents a 1-dim (connectivity = 1) part of the larger parent
topology.

So although I regard VPLS as an architectural blight per se (due to
reason 1 above), having committed this arch violation then at least one
should aim to flood across total topology IMO...and since by definition
each edge in a network graph is a p2p instance then I would agree with
Raymond Key's view below wrt to keeping a consistent model based on the
atomic p2p link connection component of topology, ie a p2mp PW MUST, by
definition, be composed of > 1 p2p link connections (where these p2p
link connections are provided by end-end p2p network connections in some
lower layer network).

regards, Neil 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Raymond Key
> Sent: 12 March 2010 21:19
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: I-D: Extension to LDP-VPLS for Ethernet broadcast & multicast
> 
> Thanks for the comments about unknown unicast. I would like 
> to share my view with the workgroups.
> 
> Our current thinking is that P2MP PW be used for Ethernet 
> broadcast and multicast only, and not touch the handling of 
> unknown unicast in existing VPLS solutions (i.e. keep it as 
> per RFC4762, flooded on the P2P PWs). 
> But actually we don't have strong objection to include 
> unknown unicast in the P2MP PW.
>

---

From: "Yuji KAMITE" <[email-masked]>
Date: Thu, 18 Mar 2010 19:49:30 +0900

>      Unknown unicast is considered out of scope according to RFC5501.

The major reason why unknown unicast was excluded from RFC5501 is, 
there can a case that reordering happens, as many people say on the list
now.

But on the other hand RFC5501 never says that transporting unknown over
P2MP-PSN is prohibited.  (it was intentionally edited as such).
This is because it depends on each SP's service model and application
scenario significantly, how serious the expected influences about reordering
are.  

If you locate CE as generic L2 bridge, and the SP provides the VPLS
as the native Ethernet LAN service, and if customer's application is
senstive
about the packet sequence, then the flooding over P2MP optimization would
not be recommended.
(e.g., customer possibly might be running circuit emulation over the
ethernet LAN,
 and has a strong SLA with SP)

However,  if the customer is mostly interested in sending traffic from IP
router as CE
that is directly connected to PE,  MAC-learning of the interface is already
completed (e.g., by ARP, OSPF etc.)  and so there's no strong concern about
reordering.  In this case, P2MP optimization for unknown
flooding will be used as a simple safeguard to prevent unexpected
device's connection or wrong operation etc.  Main application of P2MP 
optimization here is only multicast flow, not unknown unicast.

So, I believe it is just a matter of operator's choice
if you apply P2MP-PW or P2P-PW to unknown unicast.

(BTW, In fact, draft-ietf-l2vpn-vpls-mcast  today covers the method to 
 perform unknown flooding over P2MP PSN tunnel as well, 
 but it does not mean that it conflicts with the requirement of RFC5501.)

Regards,
Yuji

> Sent: Saturday, March 13, 2010 6:19 AM