Framework for Layer 2 Virtual Private Networks (L2VPNs)
draft-ietf-l2vpn-l2-framework-05

I cleared my Discuss because charter work was added.  I believe there remain questions that the protocol developed will be the simplest one, just for the IP supporting heterogeneous PW, and that
its applicability domain will be clearly stated.

Here is my original Discuss note, which I removed:  WG did not have consensus of community to work on IP over heterogeneous L2 VPNs (not translation among the L2s, but heterogenous ARP, MTUs, multicast, etc.), which is why the task is not on the charter.  We discussed in the telechat and there could be a charter-related discussion in the WG before going forward.

From OPS Directorate (Pekka):

Semi-editorials:
================

==> I'd "flatten out" the structure of the document.  Basically all 
the main content is in one section 3.  The document might be more 
balanced if this was split to multiple sections.  Some of these (e.g. 
the stuff under current section 3.1) might be better placed before the 
reference model section, because they seem to be rather introductory.  
However, this is not a huge issue..

==> The document is rather light on references, e.g. LDP, BGP, L2TP, 
MPLS, etc. which are all used in the body.  These could be referred to 
using informative references but I don't think this is really 
necessary.

==> it might be a good idea to include an "abbreviations" (P, PE, CE,
SP, etc.) section up front, but defer the actual terms and their
background to the terminology document -- especially if the ref to the
terminology is not normative.

   A VPLS is an L2 service that in all emulates LAN service across a
   Wide Area Network (WAN). Thus it also has all the scaling
   characteristics of a LAN. Other scaling issues might arise from the
   number of end-points that can be supported on a particular PE.

==> uhh, actually, this has much worse scaling characteristics.  It's
equal from the perspective of a host or a broadcast domain, but
entirely different from the perspective of the underlying network glue
providing the VPLS service.

3.1.3. IP-only LAN-like Service (IPLS)
                                                                                                       
   An IPLS is very like a VPLS, except that:
[...]
     - it is assumed that the service will only carry IP packets, and
       supporting packets such as ICMP and ARP; Layer2 packets which do
       not contain IP are not supported.

==> one should probably do some rather trivial rewording to clarify 
that IPLS works for either IPv4, IPv6 or both. Use of "IP" and "ICMP" 
is a bit ambiguous, and ARP is replaced by NDP.

   Multipoint-to-point PWs can be used only when the PE receiving a
   frame from the PW does not need to know where the frame came from.
 
==> this sentence may be misleading -- does that imply that the PE 
might not check the frames or the multiple senders at all?  Does it 
exclude the implementation technique where the multipoint-to-point 
-terminating PE would have a list of senders to that PW.

     - L2TP
                                                                                                       
       L2TP can be used for pseudowire signaling, resulting in
       pseudowires that are carried as "sessions" within L2TP tunnels.
       Pseudowire-specific extensions to L2TP may also be needed.

==> afaik, L2TP does not include *signalling* as such, so why L2TP 
would be a P-t-P signalling protocol might need a bit of more 
elaboration?

Editorials:
 - spell out L2VPN in the document title
 - section 2.4, s/the they both/they both/, s/differences is/difference is/ ?

The draft says:

3.2.6.3. Inter-AS Considerations

   Pseudowires may need to run from a PE in one Service Provider's
   network to a PE in another Service Provider's network. This means
   that the signaling to set up the PEs must be able to cross network
   boundaries. All known proposals for signaling are able to do this. It
   is especially advisable to use some form of authentication between
   the two PW endpoints in this case.


This looks a wee bit inadequate to me.  For starters "All known proposals
for signaling are able to do this" seems to mean "anything under consideration
by the working group" rather than *all known*.  Secondly, "some form of
authentication between the two PW endpoints" doesn't really cover the
ground; as was pointed out on a previous document on this ballot, making
sure that the two PW endpoints are configured with the same trust anchors
can bite you in cases where you are relying on something fancier than
a shared secret.

I'm putting a no-ob on this, but I have to say that seeing all the different
l2vpn stuff thrown together made me revisit those old "are we being
tunnelled to death" nightmares.  The bland "use hierarchy to solve
the n*(n-1) scaling problem" scares me in particular, as a hierarchy of 
these tunnels can easily lose the properties of a classic IP network.