Subject: Draft charter for L3VPN

From: Alex Zinin <[email-masked]>
Date: Wed, 7 May 2003 18:51:57 -0700

Folks-

It is taking longer than I anticipated to set up the mailing lists, so
I am sending the proposed WG charters to this list. These are
_drafts_, so are likely to need more fine-tuning. Below is the
proposed charter for L3VPN. The one on L2VPN is in a separate message.
Comments welcome.

--
Alex

Layer 3 Virtual Private Networks (l3vpn)

Chair(s): <under discussion>

Area Director(s):
   Thomas Narten <[email-masked]>
   Erik Nordmark <[email-masked]>

Area Advisor:
   Thomas Narten <[email-masked]>

Technical Advisor:
   Alex Zinin <[email-masked]>

Description of Working Group:

This working group is responsible for defining and specifying a
limited number of solutions for supporting Layer-3 (routed)
Virtual Private Networks (L3VPNs).

The WG is responsible for standardization of the following solutions:

   1. BGP/MPLS IP VPNs (based on RFC 2547)
   2. IP VPNs using Virtual Routers
   3. CE-based VPNs using IPSEC

As part of this effort the WG will work on the following tasks
(additional work items will require rechartering):

   1. Requirements and framework for Layer 3 VPNs
   2. Solution documents for each approach listed above (including
      applicability statements)
   3. MIB definitions for each approach
   4. Security mechanisms for each approach

Multicast support and Inter-AS considerations are excluded from the charter 
at this time. They may be considered for inclusion in an updated charter 
at a later time. Future work items may also include OAM support.

As a general rule, the WG will not create new protocols, but will provide 
functional requirements for extensions of the existing protocols that will 
be discussed in the protocol-specific WGs.

WG Milestones (optimistic):

Dec 2002 Submit L3 VPN Requirements Document to IESG for publication as Info
         (completed)
Dec 2002 Submit L3 VPN Framework Document to IESG for publication as Info
         (completed)
Aug 2003 Submit L3 VPN Security Analysis to IESG for publication as Info
         (draft-fang-ppvpn-security-framework-00)
Aug 2003 Submit BGP/MPLS VPNs specification and AS to IESG for publication as PS
         (draft-ietf-ppvpn-rfc2547bis-03, draft-ietf-ppvpn-as2547-01)

Sep 2003 Submit CE-based specification and AS to IESG for publication as PS
         (draft-ietf-ppvpn-ce-based-03)
Sep 2003 Submit Virtual Router specification and AS to IESG for publication as PS
         (draft-ietf-ppvpn-vpn-vr-03, draft-ietf-ppvpn-as-vr-01)
Oct 2003 Submit VPN MIB Textual Conventions to IESG for publication as PS
         (draft-ietf-ppvpn-tc-mib-02)
Oct 2003 Submit MPLS BGP MIB to IESG for publication as PS
         (draft-ietf-ppvpn-mpls-vpn-mib-05)
Oct 2003 Submit VR MIB to IESG for publication as PS
         (draft-ietf-ppvpn-vr-mib-04)

Dec 2003 Submit specification of using IPSEC for PE-PE encapsulation in BGP/MPLS VPNs to IESG
         for publication as PS
         (draft-ietf-ppvpn-ipsec-2547-03)
Jan 2003 Submit specification of using GRE for PE-PE encapsulation in BGP/MPLS VPNs to IESG
         for publication as PS
         (draft-ietf-ppvpn-gre-ip-2547-02)

Jan 2003 Submit specification of CE Route Authentication to IESG for publication as PS
         (draft-ietf-ppvpn-l3vpn-auth-03)

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Thu, 08 May 2003 12:28:32 +0900 (JST)

Alex,

(1) It seems to me, "provider provisioned" is eliminated from the proposed 
charter. I think this is important property, because in the current L3
requirements, L3 framework, CE-based solution documents, the scope of the
CE-based VPNs is limited to "provider provisioned" thus, customer-managed
CE-based VPNs are out scope. If the latter is in scope of the proposed 
charter, considerable updates are needed to these documents. Therefore,
if this is not intended by the IESG, please clearly states that the scope is
limited "provider provisioned" in the charter.

(2) Interworking discussion between solutions is not clearly stated in the
proposed charter. Is it in or out the scope? According to the following 
statement in the current charter, it may be out of scope. However, based
on the WG and DT consensus, it is clearly described in the L3 requirements 
and framework documents, because we thought it was indispensable. If it is
in scope, please clearly states it.

> below for specifics). The goal is to foster interoperability among
> implementations of a specific approach. Standardization of specific

(3) draft-ietf-ppvpn-applicability-guidelines-01.txt and
draft-ietf-ppvpn-generic-reqts-02.txt are not addressed in the milestones.
I think these are active, so there should be addressed in the L2 or L3 WG
charter.

(4) In my understanding, the following draft is obsoleted and replaced by
draft-declercq-ppvpn-ce-based-sol-00.txt. And I think 
draft-declercq-ppvpn-ce-based-as-01.txt should also be addressed.

>         (draft-ietf-ppvpn-ce-based-03)

Thanks,

Muneyoshi Suzuki
Nippon Telegraph and Telephone Corp.

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 8 May 2003 07:19:03 +0300

Alex Zinin writes:

 >Inter-AS considerations are excluded from the charter at this time. 

looks like I in Ietf doesn't mean Internet anymore.

-- juha

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 7 May 2003 21:39:21 -0700 (PDT)

> Inter-AS considerations are excluded from the

Alex,
A number of SPs that provide L3VPN service use internally more than
one AS. I like to suggest that the clause above be changed to
"inter-provider considerations are excluded ... at this time".

Given that the context is of "Provider Provisioned" VPNs,
inter-provider VPNs are not necessarly within scope of the WG. This
does not exclude in my view scenarios where a provider buys transit
services from another, in order to provide the service to the customer
network. This is already contemplated in 2547bis.

Inter-AS/single provider is imho a necessary part of the L3VPN solution.

> looks like I in Ietf doesn't mean Internet anymore.

I'm not sure i understand the comment. The Internet is a public
network, a VPN a private one. Do you mean to refer to Internet access
from a VPN ? inter-action between the two ? I would believe that to be
in scope. Alex, would you please clarify ?

regards,
  Pedro.

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 8 May 2003 08:02:23 +0300

> in scope. Alex, would you please clarify ?

what i meant was that ietf should work on solutions that work across the
internet, not just within a single as.  if a vpn according to a
particular solution cannot span more than one as, the solution is
completely useless to us, because in our own network alone there are
five-to-six different ases as the result of mergers with and purchases
of other providers.

also, a regional provider like us needs to have partnerships with other
providers that cover other parts of the world.  therefore it is almost
as important to us that a vpn according to a given solution can span
more than one provider.

for example, consider the case where we provide a vpn solution for a
given customer that initially only has sites within our own network and
then suddenly they want to add another site is china, where we do not
operate?  it would be very unfortunate if we would need at that point to
switch from a single provider vpn solution to a multi-provider solution
also for the old sites.  

therefore, i don't see much point in postponing the multi-provider
aspects either.

-- juha

---

From: Alex Zinin <[email-masked]>
Date: Wed, 7 May 2003 22:19:54 -0700

Muneyoshi,

Thanks for looking closely at this, my answers inline below.

> limited "provider provisioned" in the charter.

This is an "oops". Thanks for catching this (note that the L2vpn charter has
this part.) How about we change the first para to say:

   This working group is responsible for defining and specifying a
   limited number of solutions for supporting provider-provisioned
   Layer-3 (routed) Virtual Private Networks (L3VPNs).

> in scope, please clearly states it.

If folks believe this is needed, I would suggest we put this in the
possible future items. I am not particularly opposed to the WG looking
at this, I just want us to get the base specs out before jumping on
more advanced things.

> I think these are active, so there should be addressed in the L2 or L3 WG

Agreed. I don't have a particular preference as to which WG these go
to, but it seems that L3vpn would be a good fit. I will wait until
we hear more comments from people.

>>         (draft-ietf-ppvpn-ce-based-03)

Noted.

Thanks a bunch.

Alex

---

From: Alex Zinin <[email-masked]>
Date: Wed, 7 May 2003 22:26:56 -0700

Juha,

> looks like I in Ietf doesn't mean Internet anymore.

Note the "at this time" part. The intention is not to preclude the WG
from looking at Inter-AS aspects, but rather to make sure we get
"simple" things completed first. Same for multicast, as you may have
noticed.

Alex

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 8 May 2003 08:35:43 +0300

Pedro Roque Marques writes:

 > There is in my mind a fundamental difference between a VPN that can
 > span more than one provider and a VPN which is "provided" to the
 > customer network by two different entities.

i mean the latter, i.e., the pe in china to which a site is connected to
belongs to a provider that operates in china.

 > One can have a VPN spanning multiple carrier networks by using inter-as
 > LSPs such what can be provided by carrier-of-carriers or inter-as
 > RSVP-TE (when avaliable).

sorry, but i'm only interested in ip based solutions, not mpls.

 > I'd be inclined to think that if people come forth and flush out the
 > multi-provider requirements that the work will be welcomed. But i can
 > see the attraction in attempting to focus in the single provider case.

if you look my radius based proposals, they work equally both in single
provider and multi-provider cases.

-- juha

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 7 May 2003 22:25:30 -0700 (PDT)

Juha Heinanen writes:

> also, a regional provider like us needs to have partnerships with
> other providers that cover other parts of the world.  therefore it
> is almost as important to us that a vpn according to a given
> solution can span more than one provider.

> given customer that initially only has sites within our own network
> and then suddenly they want to add another site is china, where we
> do not operate?  it would be very unfortunate if we would need at
> that point to switch from a single provider vpn solution to a
> multi-provider solution also for the old sites.

> therefore, i don't see much point in postponing the multi-provider

My assumption is that if you have two entities "providing" the VPN
service you will have to consider additional set of
requirements/problems which are distinct from buying a transit LSP
from a second provider.

regards,
  Pedro.

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 8 May 2003 08:37:20 +0300

Alex Zinin writes:

 > "simple" things completed first.

see my other email.

-- juha

---

From: Alex Zinin <[email-masked]>
Date: Wed, 7 May 2003 22:44:37 -0700

Juha, Pedro-

 Let's keep to goal of that line in the text in mind--make progress on
 basic things before going to more complex ones (while still keeping
 the Internet-wide considerations in mind).

 Now, looking at the solutions that we have on the plate now--

>    3. CE-based VPNs using IPSEC

 --let's answer two questions:

 1. Is complexity associated with inter-provider scenarios
    sufficiently higher than for the single-provider case?

 2. Is complexity associated with inter-AS (1 provider) scenarios
    sufficiently higher than for the single-AS case?

 Depending on the answers we should be able to draw the line for the
 first step to include either the single-AS or the single-provider
 scenarios only.
 
-- 
Alex

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Thu, 08 May 2003 14:51:59 +0900 (JST)

Alex,

>    Layer-3 (routed) Virtual Private Networks (L3VPNs).

Agreed.

> at this, I just want us to get the base specs out before jumping on

Agreed.

> we hear more comments from people.

Agreed.

Thanks,

Muneyoshi Suzuki

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 8 May 2003 09:10:29 +0300

>  the Internet-wide considerations in mind).

that would be fine if you can guarantee for me that there exists for
each solution a backwards compatible migration path from intra-provider to
inter-provider although the details may not have been worked out yet.
inter-AS is a MUST from the very beginning.

 >     sufficiently higher than for the single-provider case?

no, if your solution is a good one.

 >     sufficiently higher than for the single-AS case?

same here.  check out my radius drafts.

-- juha

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 7 May 2003 23:37:13 -0700 (PDT)

Alex Zinin writes:

>>    1. BGP/MPLS IP VPNs (based on RFC 2547) 2. IP VPNs using Virtual
>> Routers 3. CE-based VPNs using IPSEC

> sufficiently higher than for the single-AS case?

Regarding 2547bis, which is the model i'm familiar with, i believe the
current spec already provides enought functionality to allow
inter-as/same provider to be used in production environments.

The fundamental building blocks apear to be in place. I wouldn't
expect additional work in this area to be disjoint from the intra-as
scenarios.

The additional technology that is applicable in this case besides what
is specified in 2547bis is (to my knowledge): RFC 3107, inter-as
RSVP-TE (which is being pursued in different WG).

I believe it would be useful not to exclude this work from the
charter.

  Pedro.

---

From: "Jim Guichard" <[email-masked]>
Date: Thu, 8 May 2003 08:10:07 -0400

Hi Alex,

> >-----Original Message-----
> >From: Alex Zinin [mailto:[email-masked]]
> >Sent: Thursday, May 08, 2003 1:45 AM
> >To: Juha Heinanen
> >Cc: Pedro Roque Marques; [email-masked]
> >Subject: Re: Draft charter for L3VPN: inter-AS/inter-provider
> >
> >
> >Juha, Pedro-
> >

potentially yes as each independent AS might run differing backbone
protocols e.g. 2547oLDP Vs 2547oGRE. An end-to-end LSP must be maintained
between ingress/egress PEs so the complexity associated with this operation
is imho higher than within a single AS (although even in that case there may
be different "islands" that need to interop).

> >    sufficiently higher than for the single-AS case?

potentially yes for the same reasons as (1). Jim

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 8 May 2003 10:48:24 -0700 (PDT)

Alex,

>  first step to include either the single-AS or the single-provider

I will restrict my response to 2547. For 2547 inter-as/singe-provider
solutions exist and are hashed out. Deploying them may be more
complicated than a single-AS, but certainly doesn't validate
precluding them from the charter. Hence we should keep them in the
charter. 

Inter-provider solutions can be a future work item.

Regards,
rahul

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 08 May 2003 20:06:41 +0200

Hi Alex,

Just two small comments:

> at this time.

This is very bad thing as each extension or proposed solution has to
work both intra and inter domain. There are production deployments
already inter-as and any solution which one would come up and which
would be limited to intra-as would a bad one. Besides while a number of
solutions can be easy to solve intra-domin going out of AS those may no
longer work. So my vote is to delete this line. The Inter-AS border on
L3VPNs is crossed long time ago ;).
 
> be discussed in the protocol-specific WGs.

That is even biggest evil making essentially as ppvpn this new WG
useless :).Without at least ability to propose extensions to protocols
submitting any serious draft is pointless. If I have to write
requirements for myself and submit a solution in IDR I would just go for
the latter immediately. Also note that this line is outside of reality
of work done in vast majority of all drafts in ppvpn WG. I do hope that
this line will also be removed therefor making the ppvnp split really
useful in practice

Cheers,
R.

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 8 May 2003 11:27:19 -0700 (PDT)

[clipped]

> this line will also be removed therefor making the ppvnp split really

I very strongly second Robert's opinion. Time and again the procedure of
defining protocol extensions in PPVPN comes up. And every time the reality
is ignored. How about the following:
   "The WG may propose extensions to existing protocols and such
extensions will be discussed and reviewed by the protocol-specific WG."

The question than is: Should a document submitted to the current PPVPN WG
(or the new groups if the split happens) be accepted as a WG doc before
the protocol specific WG reviews protocol extensions (if any) ? I think we
need more discussion on this. There are cases where it makes sense to have
such a review before accepting the doc as a WG doc and there are cases
where it doesn't.

Regards,
rahul

---

From: Eric Rosen <[email-masked]>
Date: Thu, 08 May 2003 14:44:02 -0400

> Inter-AS considerations are excluded from the charter at this time. 

As many have pointed out, this doesn't make much sense, as multi-AS and even
multi-provider  capability must  be present  in order  to make  the solution
useful. 

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

With regard  to the specific  list of documents,  a notable omission  is the
specification for doing  2547bis when OSPF is the  PE/CE protocol.  Now that
a proper division of responsibilities has  been agreed with the OSPF WG, I'd
like to see this document added to the list. 

> be discussed in the protocol-specific WGs.

I happen  to like this  sort of restriction,  because it helps to  prevent a
situation in  which every  proposal includes an  extension that  is entirely
optimized for that proposal. 

One more comment: I believe that the month following Dec 2003 is Jan 2004.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 9 May 2003 11:01:25 -0700

Folks-

 Regarding inter-AS and inter-provide. Small clarification: the
 proposal is not to move it outside the charter completely, but
 to clarify what the WG would be doing first and what next, i.e.,
 make visible progress on basic things and then move to more complex
 scenarios.

 Now, having read postings from everyone, it seems that the agreement
 is (correct me if I'm mistaken) that inter-provider is better
 put as a future item for now.

 Regarding inter-AS single provider, I have a couple of questions:

    Two reasons have been brought in (1):
    
      a) different encaps for 2547 (MPLS/GRE)
      b) provisioning end-to-end LSP is more complex in the multi-AS
         case

    It seems that this may indeed complicate the mechanisms.
    I'd love to see a little more discussion on this.

 2. Are we going to need additional documents compared to what we
    already have in order to describe inter-AS scenarios
    appropriately? If yes, I'd rather say one-AS first, then multi-AS
    single provider, and then multi-provider.

 Regards.

Alex

---

From: Alex Zinin <[email-masked]>
Date: Fri, 9 May 2003 11:43:00 -0700

> be discussed in the protocol-specific WGs.

we had the following:

   > optimized for that proposal.

Here's my take on this:

1. I think I (and the IESG in this case too) would not be comfortable
   with a general approach of extensions to protocols that have
   corresponding WGs not owned by those WGs. Clearly, the expertise and
   the bigger picture of the development of a particular protocol is
   there. So, I think allowing the VPN WGs (or PPVPN) to develop and
   standardize protocol-specific extensions would not be realistic or
   fair to the protocol-specific WGs.

2. The text in the charter actually describes an existing
   situation--we do this in CCAMP--for instance, we have a generic
   routing document describing information that needs to be
   distributed and then we have protocol-specific documents that
   define encoding in that particular protocol. Not extremely
   effective from the CCAMP perspective, but quite fair if we take
   other WGs in consideration.

3. In reality, what we want to achieve is the VPN community being
   able to propose and document extensions to existing protocols
   that would help VPN technology development. Also, before a given
   mechanism goes forward, we need to make sure that:

     a. The VPN community believes that it serves the purpose
        and the right way forward
     
   AND
   
     b. The protocol-specific community believes that using
        the protocol is a good idea and the way this is done
        is correct.

   Given that finally the extension specs have to live in the
   protocol-specific WGs, ow about we use the following process
   (draft):

     1. VPN folks who believe that a given protocol extension
        is needed, come up with an individual draft describing
        the details.

     2. The draft is brought to the appropriate VPN WG. A discussion
        on the mailing list AND in the room is held on the subject of
        why this is needed and whether this is a good idea VPN-wise.
        If there is no agreement on this--the draft does not go
        any further. Otherwise:

     3. The draft is taken to the protocol-specific WG. The WG
        discusses if it is happy with it as a general approach, if
        so takes it as a WG item. Otherwise, the WG chairs summarize
        the discussion and send the summary to the VPN WG.

     4. If the draft is accepted by the protocol-specific WG,
        the appropriate VPN framework document is updated to describe
        it and refer to the doc.

     5. The WG chairs coordinate timing for the draft.
        When ready to go to IESG, the draft is LC'ed in both WGs.

   Comments?

Alex

---

From: Rahul Aggarwal <[email-masked]>
Date: Fri, 9 May 2003 12:45:41 -0700 (PDT)

Alex,

Comments inline:

>       a) different encaps for 2547 (MPLS/GRE)

There is no fundamental difference with regards to supporting different
encaps in the single AS and inter-AS case. 

>     I'd love to see a little more discussion on this.

2547 describes the mechansims for inter-AS. IMHO they are well understood.
Set up of a RSVP-TE inter-AS LSP is work in progress. However
2547 does not need any additional mechanisms for using a RSVP-TE inter-AS
LSP between the end PEs.

>     appropriately? 

Base mechanisms for implementing and deploying inter-AS are in place and
are described in 2547. 

If yes, I'd rather say one-AS first, then multi-AS
>     single provider, and then multi-provider.

I would still say one-AS and multi-AS to begin with.

Regards,
rahul

---

From: Alex Zinin <[email-masked]>
Date: Fri, 9 May 2003 15:10:06 -0700

Eric,

> the grounds that they don't provide public Internet transparency. 

Is this specific to the case of 2547 only or generic to all L3
mechanisms? If the former, I would rather not like the charter to say
so. As for rejecting the 2547-related specs, I think it would be very
useful if the applicability statement highlighted the detail about
cooperating SPs and state that Internet transparency is a non-goal.

Noted.

> One more comment: I believe that the month following Dec 2003 is Jan 2004.

We definitely need a consensus on this.

Alex

---

From: "Jim Guichard" <[email-masked]>
Date: Sat, 10 May 2003 07:42:44 -0400

> >encaps in the single AS and inter-AS case.

Perhaps, but certainly it is potentially more difficult. In the single AS
case one would expect routing information to be available so as to build the
ingress/egress PE connectivity. However, in the InterAS case this may not be
available and therefore complexity is added as the ASBRs might need to
"stitch" things together .. I do however believe that the single AS and
multiAS case are similar as typically routing information is leaked between
the AS's that make up the multiAS environment. Jim

---

From: Eric Rosen <[email-masked]>
Date: Mon, 12 May 2003 10:12:37 -0400

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?

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 12 May 2003 09:23:40 -0700

Alex,

> proposed charter for L3VPN. The one on L2VPN is in a separate message.

Why the list of documents does not include "Using BGP as an Auto-Discovery 
Mechanism for Network-based VPNs" (draft-ietf-ppvpn-bgpvpn-auto-04.txt) ?

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 12 May 2003 09:37:45 -0700

Robert,

> L3VPNs is crossed long time ago ;).

As Alex said in one of his recent e-mails "I think you might be confusing 
the IETF with the market".

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 12 May 2003 10:02:25 -0700

Juha,

> inter-AS is a MUST from the very beginning.

I don't think that a guarantee from Alex (or any other individual)
that "there exists for each solution a backwards compatible migration
path from intra-provider to inter-provider" is enough. The inter-AS
solution must has enough details from the very beginning to
demonstrate that there is a a backwards compatible migration path
from intra-provider to inter-provider.

Yakov.

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 12 May 2003 20:15:07 +0300

Yakov Rekhter writes:

 > The inter-AS

even better, juha

---

From: Alex Zinin <[email-masked]>
Date: Tue, 13 May 2003 10:40:52 -0700

Eric,

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.

> as the backbone for its intranet. 

I understand your position. I'd like to see more opinions here.

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): 

Yep, this is good, I think.

Alex

---

From: Alex Zinin <[email-masked]>
Date: Tue, 13 May 2003 10:41:00 -0700

Yakov,

> Mechanism for Network-based VPNs" (draft-ietf-ppvpn-bgpvpn-auto-04.txt) ?

Because I wanted to hear opinions on where it should go: L2 or L3,
and whether it should be in the first set of documents a specific
WG should work on or not.

Alex

---

From: Mark Duffy <[email-masked]>
Date: Tue, 13 May 2003 15:51:27 -0400

>I understand your position. I'd like to see more opinions here.

[This thread was about whether an updated L3 vpn wg charter should not 
specify the ability to operate across the public Internet as an objective.]

I would contend that the VR and CE-based solutions are viable across the 
public Internet, in a way that 2547 is not.  Yes, QOS and SLA are issues, 
but folks have been deploying CE-based VPNs on the Internet for years; 
evidently they don't consider these a show-stopper.  And the VR-based 
approach is similar to the CE-based approach as far as the impact of 
running across the Internet is concerned.

I do think that 2547 IS appropriate for the wg to pursue.  However 
different tools (alone or used together) are optimal for different 
situations and that is why we have multiple L3 vpn approaches.

Should the charter REQUIRE solutions to be viable across the 
Internet?  No.  Should it encourage development of 1 or more solutions that 
are viable across the Internet?  Yes.

--Mark

---

From: "Brijesh Kumar" <[email-masked]>
Date: Tue, 13 May 2003 14:44:30 -0700

I strongly believe that Juha's points merit a serious consideration.

A VPN solution must be able to span as many providers as 
needed to connect an organization. This requirement may be much
more useful in the European context given that  businesses there
operate in many countries while many carriers may not operate 
outside their local operating regions.

If  BGP/MPLS VPNS can be a charter item, it is hard to
understand why this group's charter can exclude proposals
such as Juha's Radius based approach  which does provide
a simple and perhaps much more manageable environment 
for multi-carrier VPNs. Every approach should be discussed
at its own merit.

Regards,

--brijesh

---

From: Matt Squire <[email-masked]>
Date: Wed, 14 May 2003 01:52:48 -0400

> I understand your position. I'd like to see more opinions here.

I'm missing the part where a VPN has to be used as the backbone of a 
companies Internet, or that QoS and SLAs are an absolute pre-requisite. 
      I'm not saying the application is invalid, or that SLAs aren't 
good things, but connectivity can be provided for other applications and 
without an SLA, and its not a useless objective.

- Matt

---

From: [email-masked]
Date: Wed, 14 May 2003 09:59:11 +0200

Alex, Eric,

> I understand your position. I'd like to see more opinions here.

It is clear that using CE-based VPNs over the public Internet will have
different QoS properties, different SLAs and different accounting
frameworks. It's the applicability statement document's task to clearly
formulate that. And it's the SLA that will also reflect this from a
service perspective (a VPN scheme shouldn't promise what it can't
accomplish). But I don't think this means that it's "not viable".

Jeremy.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 14 May 2003 10:32:56 -0400

Mark> Yes, QOS  and SLA are issues,  but folks have  been deploying CE-based
Mark> VPNs on the Internet for  years; evidently they don't consider these a
Mark> show-stopper. 

If a provider  came to you and said,  "for a lot of money,  I will provision
and manage your  enterprise backbone; however, you will not  be able to hold
me  accountable for  the service",  would you  buy it?   Sounds like  a good
business if you can get it!  

Provider-provisioned L3VPNs  are meant to  compete with ATM and  Frame Relay
services backbone  services.  User-provisioned  CE-based VPNS such  as IPsec
tunnels  from  a residence  to  a  corporate  backbone compete  with  dialup
services. 

Mark> Should the charter REQUIRE solutions to be viable across the Internet?
Mark> No.  Should it  encourage development of 1 or  more solutions that are
Mark> viable across the Internet?  Yes.

I wouldn't really  disagree, but I wouldn't want to be  the one developing a
solution which is really viable across the Internet. 

Matt> I'm missing the part  where a VPN has to be used  as the backbone of a
Matt> companies Internet, 

"Intranet."   That's really  the  target  of L3VPN  and  VPWS schemes,  else
you'd just do everything  in a hub and spoke manner.  (I'm  not as sure what
the target of VPLS is.)

Matt> or that QoS and SLAs are an absolute pre-requisite. 

Well, I'd  like to see VPLS  working over arbitrary paths  across the public
Internet, where all you know is you have a best effort datagram service with
no accountability for problems!

---

From: Matt Squire <[email-masked]>
Date: Wed, 14 May 2003 15:11:30 -0400

> you'd just do everything  in a hub and spoke manner.  (I'm  not as sure what

I think they're also being targeted for the access space.  E.g. remote 
sites accessing a core network, where the virtual network is not a core 
application but an access appllication.

> no accountability for problems! 

People by best-effort services all the time.  They pay less for them of 
course, but best-effort service isn't uncommon.

I know you have a particular application in mind and therefore the 
requirements you put forth make sense for that application.  But the 
technology can and should be applicable to other deployment scenarios 
and applications.

- Matt

---

From: Ross Callon <[email-masked]>
Date: Fri, 16 May 2003 14:32:23 -0400

At 10:02 AM 5/12/2003 -0700, Yakov Rekhter wrote:
>... The inter-AS

My understanding is that this discussion is still related to what goes into
the proposed charter for the Layer 3 VPN working group. In this context
we don't have to solve the problem right now, we just need to decide
what goes into the charter. 

My personal view is that multi-AS one-provider is important enough that
it is worth mentioning in the charter. Multi-AS, multi-provider is probably
also something that we want to have as a possible option. Thus I think 
that we might as well mention these in the charter. 

I am not so sure about slowing down the base documents in order to 
get the multi-AS cases fully fleshed out. We have already slowed down 
the base documents to wait to finish the Framework and Requirements 
documents, and there is the possibility of slowing them down to wait 
for a security document. 

To me whether to insist on the inter-AS case being solved and fully
documented before progressing the solutions documents comes down
to three things: (i) How important are the multi-AS cases; and (ii) How
confident are we that if we postpone the multi-AS work, that we 
won't end up with a situation where we wish that we had changed the
base documents; and (iii) How long will it take to fully document the
inter-AS cases?

A question for Alex and Thomas Narten: Suppose hypothetically that
there is consensus to work on the inter-AS cases, and suppose that 
we don't want to slow down the base documents to wait for this to
complete. In this case, the L3 VPN working group might work on 
progressing existing documents (the long list from the proposed 
charter that Alex sent out) as a high priority item, and work on the
inter-AS cases as a lower priority. In this case, would we want to 
explicitly mention the Inter-AS cases in the charter? 

Ross

---

From: Loa Andersson <[email-masked]>
Date: Tue, 27 May 2003 11:16:04 +0200

Ross,

thinking about this I believe that there are four different scenarios:

- single provider / single AS
- single provider / multiple AS
- multiple co-operating providers / multiple AS
- Internet

I would like any solution for the L3 VPN to work in all these
scenarions. Having said this I also recognize that there is a
difference on possible level of service in the different scenarios.

While an L3VPN across the Internet will be a best effort service,
the same service in the single provider / single AS might give you
absolute QoS guarantees.

So I my take is that we need to be open recognize all these scenarios
in the charter, but would like to see i clear priority.

My personal priority today would be:

1. Internet
2. single provider / single AS
3. multiple co-operating providers / multiple AS
4. single provider / multiple AS

Where priority 1 and 2 is a photo finish decision.

/Loa

-- 
/Loa

mobile + 46 739 81 21 64
email: [email-masked]

---

From: Alex Zinin <[email-masked]>
Date: Fri, 30 May 2003 12:54:31 -0700

Ross,

Friday, May 16, 2003, 11:32:23 AM, Ross Callon wrote:
[...]
> what goes into the charter.

Agreed

[...]
> base documents; and (iii) How long will it take to fully document the

Very true

> explicitly mention the Inter-AS cases in the charter? 

This would be reasonable, I think.
I will follow up on Loa's message too.

Alex