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

[<neil.2.harrison at bt.com>]

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: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org] 
> On Behalf Of Raymond Key
> Sent: 12 March 2010 21:19
> To: l2vpn at ietf.org; pwe3 at ietf.org
> Cc: frederic.jounay at orange-ftgroup.com
> 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.
> 
> 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
>