Re: Draft charter for L2VPN - IPLS & ARP Mediation

Ali's  point is  that once  you have  deployed  a PE  which can  do the  MAC
learning in  the data plane, you  can always shut off  the other unnecessary
parts of  the VPLS service  (e.g., bridging control  protocols, sequencing),
and you have the equivalent of an IPLS service.

This assumes that all the PEs on  which you want to provide the IPLS service
also provide the VPLS service.  It also assumes that the MAC learning in the
data plane  comes "for free", so that  there is no advantage  to shutting it
off on certain ports and on certain pseudowires.

It also overlooks the fact that  the IPLS is a true multipoint service; like
L3VPN, but  unlike VPLS, when  you receive a  packet from a  pseudowire, you
don't care where it  came from because you don't have to  do any MAC address
learning  from  the packet.   Since  there  is  no point-to-point  state  to
maintain, the overhead is less and the service should be more scalable. 

If  you think that  the main  requirement is  providing an  ethernet service
which allows  you to transparently  connect bridged ethernet  networks, then
you'll tend to think VPLS solves the  problem and IPLS is just a niche which
doesn't really merit its own architecture.  If, on the other hand, you think
that  the main  requirement is  providing  a lan-like  intetrconnect for  IP
routers, and  that the  generalized ethernet service  is just a  niche, then
IPLS seems much more important, as VPLS is really overkill.

I also don't see any reason why IPLS and "VPLS as restricted to interconnect
of IP routers" cannot be made interoperable.