[PWE3] I-D: Extension to LDP-VPLS for Ethernet broadcast & multicast

[Raymond Key <raymond.key at ieee.org>]

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