[Pals] draft-ietf-pals-ldp-vpls-broadcast-exten - some comments

[Stewart Bryant <[e-mail]>]

I took a quick look at this draft and will give it a more
detailed review when it get to WGLC

Please see below.

However I have a significant concern that the PALS WG
needs to address before this draft can progress to
publication.

The approach described in this draft relies on the
use of P2MP PWs. However neither PWE3 or PALS has
published an RFC specifying a P2MP PW.

The draft that you rely on for the P2MP PW specification
(draft-ietf-pwe3-p2mp-pw) expired nearly three years
ago..


========

1. Introduction
    
    This document proposes a simple extension to LDP-VPLS [RFC4762] to
    improve bandwidth efficiency for Ethernet broadcast/multicast traffic
    within a carrier's network. This bandwidth improvement is achieved by
    adding to the existing full-mesh of bidirectional point-to-point
    PseudoWires (P2P PWs) unidirectional point-to-multipoint PseudoWires
    (P2MP PWs) between selected PEs within a VPLS instance.

SB> You have not yet provided a definition or reference to P2MP PWs.
SB> More worrying, whilst there are requirements for P2MP PWs, there
SB> is no PALS/PWE3 specification of a P2MP PW outside an MPLS-TP context
SB> (which you do not point to). I would think that we need a specification
SB> of a P2MP PW before we can publish a specification that uses them.

    With P2MP
    PWs, the ingress PE is not responsible for replicating the payload
    frame on each P2P PW towards the egress PE, instead the network
    elements along the physical path participate in the replication
    process. The replication is done by the underlying point-to-multi-
    point label switched path. This proposal allows for a large number
    of P2MP PWs to be carried through a single MPLS P2MP tunnel, thus,
    it is never necessary to maintain state in the network core for
    individual P2MP PWs.




Delord & Key                 Expires Dec 2015                  [Page 2]
   
Internet Draft   Ext to LDP-VPLS for broadcast multicast      June 2015


2. Problem Statement & Motivation

2.1. Requirements for Broadcast/Multicast Support in VPLS

    [RFC5501] provides an in-depth discussion on broadcast/multicast
    related requirements for VPLS. It highlights two specific issues:

       - issue A: replication to non-member site.
       - issue B: replication of PWs on shared physical path.

2.1.1. Issue A: replication to non-member site

    The current standard VPLS is a L2VPN service agnostic to customer's
SB> I think that should be "that is agnostic"

   Layer 3 traffic, hence does not maintain any information about IP
SB> hence what?, or do you mean "because it"
   
    multicast group membership.  Although a Layer 3 IP multicast packet
    is encapsulated in a Layer 2 Ethernet multicast frame, the current
    standard VPLS treats Ethernet multicast frame in exactly the same way
    as Ethernet broadcast frame. There is therefore an issue that
    multicast traffic is sent to sites with no members.  Since the
    upstream PE does not maintain downstream membership information, it
    simply floods frames to all downstream PEs, and the downstream PEs
    forward them to directly connected CEs; however, those CEs might not
    be the members of any multicast group.


SB> You might want to look at the logic flow in the previous para.
SB> I think you repeat yourself.

(I stopped reviewing at this point)

- Stewart