Re: Draft charter for L3VPN: Internet transparency

Eric> However, in the case of 2547bis, the "multiple providers" are expected
Eric> to be a small number  of closely cooperating service providers.  There
Eric> really  isn't much  provision for  running  the VPNs  over the  public
Eric> Internet.    It  might  be   good  to   have  this   "public  Internet
Eric> transparency"  excluded  from  the  charter.  Presumably,  that  would
Eric> prevent the  IESG from later rejecting  the specs on  the grounds that
Eric> they don't provide public Internet transparency.

Alex> Is this specific to the case of 2547 only or generic to all L3
Alex> mechanisms? If the former, I would rather not like the charter to say
Alex> so.

I think this  applies to all the schemes.  Even  the CE-based schemes aren't
viable, in my opinion, over the  public Internet because issues of QoS, SLA,
and accountability really  prevent a company from using  the public Internet
as the backbone for its intranet. 

Alex> As for rejecting the 2547-related specs, I think it would be very
Alex> useful if the applicability statement highlighted the detail about
Alex> cooperating SPs and state that Internet transparency is a non-goal.

The AS already says (in section 1, Introduction): 

   2547-style VPNs are optimized for the situation in which a customer
   (an enterprise) expects a service provider to operate and maintain
   the customer's "backbone" (i.e., the customer's inter-site routing).
   As such, the service provider becomes a "business partner" of the
   enterprise.  The technical mechanisms accommodate the case in which a
   number of closely cooperating SPs can jointly offer the VPN service
   to a customer, in that the BGP-based route distribution mechanisms
   can operate between different SPs.  If a set of SPs have sufficient
   agreements with respect to QoS, SLA, etc., then the customer's VPN
   could have sites attached to different SPs from that set.

   2547-style VPNs are NOT an optimum ["appropriate" might be a better word]
   solution for the customer who
   wants to purchase local connectivity from whatever ISP happens to
   offer the best price at a given site, nor for the customer who wants
   his VPN backbone to consist of tunnels running over the public
   Internet.

   [2547bis] specifies the inter-AS mechanisms that allow a single VPN
   to have sites attached to different SPs..  However, the design center
   is not an environment where a given VPN is spread among a very large
   number (e.g., hundreds) of SPs.

   However, in cases where remote offices, individual telecommuters,
   etc., must use the public Internet to access the VPN, it is possible
   to "tunnel" the remote traffic to a PE router, and the PE router will
   treat the traffic as if it had arrived over an interface connected to
   the PE.  Remote PPP connections can be tunneled via L2TP to a PE
   router; IPsec tunnels can also be used to tunnel traffic to a PE
   router across the public Internet. Of course when the public Internet
   is used, issues such as QoS and SLAs must be carefully considered.

Isn't this clear enough?