Re: Draft charter for L2VPN

Eric Rosen wrote:
> Matt> I'd  like  to  include  an   objective  that  the  VPLS  services  are
> Matt> transparent to higher layer protocols (e.g. really emulated a LAN) 
> 
> I  would  be  opposed to  this  as  a  charter  requirement.  This  kind  of
> requirement can  easily get you into a  situation in which you  end up doing
> 90% of the  work to handle a 1% problem.  Given  a particular solution which
> doesn't quite meet this requirement, the WG should be able to decide whether
> the solution comes  close enough or not; this  shouldn't be predetermined by
> the charter.
> 


If this requirement is not met, then we're not really providing a 
virtual X service (X=FR, X=Ethernet, etc.).  If the group is chartered 
to define new service types, and I'm not saying it can't be, thats fine. 
  But a virtual Ethernet wire that requires applications to be aware of 
the virualness of the wire has a high cost of entry.

I'm also not saying that the IPLS isn't applicable.  I had a sentence in 
there that said optimizations for specific applications are allowed. 
And thats what IPLS is - its an optimization of VPLS for IP-only LANs. 
Note its not really a virtual L2 service as there is no "real" service 
that its virtualizing, but it can be useful.  People made IP-only ATM 
LAN implementation doing the same thing, so its been done before and has 
utility.

But the base constructs have to have a goal of transparency.  I can't 
see how we can charter a work effort where the core development is to 
develop virtual services (wire, LAN) that don't have an equivalent 
"real" counterpart. That opens up the door for anything - e.g. it would 
be within the charter to create a virtual Ethernet LAN that uses source 
route bridging.

If we view VPLS as the base construct, and IPLS as an optimization, then 
I see how it fits.  Otherwise, IPLS on its own seems like a new thing. 
There is not "IP only Ethernet" standard, yet its what the document 
attempts to create.

Again, I'm not against IPLS by any means.  But transparency is a very 
useful objective, even if you want to violate it on occassion improve 
efficiency under certain restrictions.

- Matt