Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
RFC 4761

I agree with TED's DISCUSS.
And in fact MIB Doctor revieq also raised the question as to why there are 2 solutions for the same problem. So pointing it out clearly on the front page makes sense to me.

More comments by Pekka Savola from the Ops Directorate:

editorial
---------
                                                                                                      
  Alternative approaches include: [13], which allows one to build a
   Layer 2 VPN with Ethernet as the interconnect; and [12]), which
   allows one to set up an Ethernet connection across a packet-switched
   network.
                                                                                                      
==> s/)// ?
                                                                                                      
   they know that a VPLS service is being offered.  We will call these
   VPLS edge devices, which could be either a PE or an u-PE, a VE.
                                                                                                      
==> what is a "VE"?  Please expand.  It seems to be used extensively in
later parts of the doc, but never explained.
                                                                                                      
   The term "demultiplexor" refers to an identifier in a data packet
   that identifies both the VPLS to which the packet belongs as well as
   the ingress PE.  In this document, the demultiplexor is an MPLS
   label.
==> what about L2VPN's if it wouldn't be implemented over MPLS but rather
IP, GRE, .. etc. tunnels?  Do those still use MPLS labels?  Is this doc
compatible with that approach (1st paragraph of 2.2 seems to imply that it
should be)?
                                                                                                      
   The Service Provider Network is a packet switched network.  The PEs
   are assumed to be (logically) fully meshed with tunnels over which
   packets that belong to a service (such as VPLS) are encapsulated and
   forwarded.  These tunnels can be IP tunnels, such as GRE, or MPLS
   tunnels, established by RSVP-TE or LDP.  These tunnels are
   established independently of the services offered over them; the
   signaling and establishment of these tunnels are not discussed in
   this document.
...
   All the PEs participating in a VPLS are assumed to be fully meshed in
   the data plane, i.e., there is a bidirectional pseudowire between
   every pair of PEs participating in that VPLS, and thus every
   (ingress) PE can send a VPLS packet to the egress PE(s) directly,
   without the need for an intermediate PE (see Section 4.2.5.)  This
   requires that VPLS PEs are logically fully meshed in the control
   plane so that a PE can send a message to another PE to set up the
   necessary pseudowires.  See Section 3.6 for a discussion on
   alternatives to achieve a logical full mesh in the control plane.
                                                                                                      
==> aren't you saying much the same things twice?  Either reword or suggest
clarifying the differences.
                                                                                                      
   VPLS is a "LAN Service" in that CE devices that belong to VPLS V can
   interact through the SP network as if they were connected by a LAN.
                                                                                                      
==> "VPLS _V_"?  You don't use 'V' until section 3.1.1, so it would be
clearer to remove it in here.
                                                                                                      
   A VPLS BGP NLRI has the following information elements: a VE ID, a VE
   Block Offset, a VE Block Size and a label base.  The format of the
   VPLS NLRI is given below.  The AFI is the L2VPN AFI (to be assigned
   by IANA), and the SAFI is the VPLS SAFI (65).  The Length field is in
   octets.
==> it might not hurt to state explicitly whether the Length field include
the length field itself or only the subsequent fields..

I agree with the issues raised by Pekka Savola in his review, but I have no further objection.

  Please delete sections 1.3, 1.4, and 1.5 prior to publication.

  Shift Figure 6 to the left so that it does not exceed the right
  page margin.