Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling
draft-ietf-l2vpn-vpls-ldp-09

I agree with Ted's DISCUSS.
The question about 2 solutions for the same problem was also raised
from the MIB Doctor review team.

Gen-ART review comments from Elwyn Davies:

The document needs a normative reference to RFC2119 to be pointed at by the conventions section. [Scott Hollenbeck holds a DISCUSS for this.]

Editorial nits (input to copy editing):
The Boiler Plate is non-standard.
Location of the conventions section and section numbering of ToC needs fixing.
s4.1: Acronyms GRE, L2TP and IPSEC unexpanded.
s6.1.1: Acronyms AGI, TAII, SAII are unexpanded.
s9, para 2: s/a identifier/an identifier/

s15: should refer to RFC3036 (LDP) registry in which MAC List TLV type is to be registered.

First of all, I agree with Ted's DISCUSS.

I received the following comments from the Ops Directorate by Pekka Savola that you might want to consider to improve the document:

substantial
-----------
                                                                                                      
7.2. VPLS Learning actions
                                                                                                      
  Learning is done based on the customer Ethernet frame as defined
  above.  The Forwarding Information Base (FIB) keeps track of the
  mapping of customer Ethernet frame addressing and the appropriate
  PW to use.  We define two modes of learning: qualified and
  unqualified learning. [...]
                                                                                                      
==> unqualified learning (if I understood it correctly) really breaks
the network badly, are you sure you want to even specify that?
Ethernet switches which don't have VLAN-specific spanning trees (a
model which you're pushing here) have caused TONS of operational grief
.. especially when you have multi-port Ethernet cards which use the
same MAC address for all ports (*cough* Sun *cough*)..
                                                                                                      
I don't think you should support unqualified learning *at all* because
it's so badly broken, and you also break the customer's VPLS layer 2
by mixing different VLANs' MAC addresses together by doing so.  This
is not Layer 2 transparent so I'm not sure if it could be called
proper L2VPN service.  If an ISP doesn't want to deal with multiple
VLANs, the ISP should just refuse carry anything that except untagged
Ethernet!
                                                                                                      
But if you have to specify it, it needs a *lot* more health warnings!
                                                                                                      
9.1. MAC Address Aging
                                                                                                      
  PEs that learn remote MAC addresses SHOULD have an aging mechanism
  to remove unused entries associated with a PW label.  This is
  important both for conservation of memory as well as for
  administrative purposes.  For example, if a customer site A is shut
  down, eventually, the other PEs should unlearn A's MAC address.
                                                                                                      
==> this SHOULD should probably be a MUST?  If MAC addresses are not aged
out, they could stay around for ever, and that results in very well known
operational problems e.g., when hosts move from one port to another.
                                                                                                      
semi-editorial clarifications
-----------------------------
                                                                                                      
     - If the frame, as it arrives at the PE, has an encapsulation
        that is used by the local PE as a service delimiter, i.e., to
        identify the customer and/or the particular service of that
        customer, then that encapsulation may be stripped before the
        frame is sent into the VPLS.  As the frame exits the VPLS,
        the frame may have a service-delimiting encapsulation
        inserted.
....
  By following the above rules, the Ethernet frame that traverses a
  VPLS is always a customer Ethernet frame.  Note that the two
  actions, at ingress and egress, of dealing with service delimiters
  are local actions that neither PE has to signal to the other.
==> How does the PE know whether the VLAN tag is a service delimiter or not?
(looking at PWE3-ETHERNET, this is probably manual config, it wouldn't hurt
to talk about that a bit somewhere here as well) How does egress PE know
whether to reinsert a service delimiting VLAN ID, and how to choose it?
Isn't this something that needs to be communicated between PEs?
                                                                                                      
  As an application of these rules, a customer frame may arrive at a
  customer-facing port with a VLAN tag that identifies the customer's
  VPLS instance.  That tag would be stripped before it is
  encapsulated in the VPLS.  At egress, the frame may be tagged
  again, if a service-delimiting tag is used, or it may be untagged
  if none is used.
                                                                                                      
==> There are some assumptions here that I don't understand.  Are describing
a scenario where customer has multiple VPLS instances (e.g., has 10 sites,
VPLS 1 for VLAN 1 reaches all of them, VPLS 2 for VLAN 2 reaches the first
five, VPLS 3 for VLAN 3 rearches the last 5, or something) and needs a
mechanism to signal the "distribution" of the VPLS?  If yes, that could
possibly be clarified a bit somewhere.
                                                                                                      
How does the PE know which VPLS instances the customer has the right to
"subscribe to"?  Manual config?  How is this information syncronized across
all PEs?
                                                                                                      
Just trying to ensure that the customer cannot join someone else's VPLS by
picking the right VLAN ID...
                                                                                                      
                                                                                                      
editorial
------------
                                                                                                      
  The use of IGMP snooping and PIM snooping techniques should be used
  to improve multicast efficiency.  A description of these techniques
  is beyond the scope of this document.
                                                                                                      
==> This is a dangerous statement, as VPLS services should be
IP-agnostic, and (for example) IGMP snooping may not be able to deal
well with IPv6, MLD, newer versions of IGMP, etc.  So, I'd consider
removing this text or adding a bit of warning, like below -- but I
really think you shouldn't be recommending something like this.
                                                                                                      
  The use of IGMP snooping and PIM snooping techniques may be used
  to improve multicast efficiency, but care should be taken to ensure
  transparency of unknown traffic (e.g., IPv6 multicast, newer IGMP/MLD
  versions, etc.) .  A description of these techniques is beyond the
  scope of this document.

  s/IPSEC/IPsec/

There shouldn't be any citations in the abstract.

This item is returning, but my discuss hasn't been addressed.