Subject: Re: WG review: Layer 2 Virtual Private Networks (l2vpn)

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Jun 2003 09:27:49 +0300 (EEST)

Hi,

I do not think this WG should be chartered.

On Tue, 17 Jun 2003, The IESG wrote:
> 
>  1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN
>        across an IP and an MPLS-enabled IP network, allowing standard
>        Ethernet devices communicate with each other as if they were
>        connected to a common LAN segment.

I *definitely* think we should *NOT* be working on this.

>  2. Virtual Private Wire Service (VPWS)--L2 service that provides L2
>        point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI,
>        point-to-point Ethernet) across an IP and an MPLS-enabled IP network.

We shouldn't be working on this.
 
>  3. IP-only L2 VPNs--L2 service across an IP and an MPLS-enabled
>        IP network, allowing standard IP devices to communicate with each
>        other as if they were connected to a common LAN segment or a point-
>        to-point circuit.

We may have to work on the point-to-point L2 VPN case, but I'd like to see 
alternative approaches to this.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 18 Jun 2003 10:15:29 +0200

Pekka,

why?

I can think of some possible reasons, not necessarily exclusive

- this is a bad idea/impossible to do well, so we shouldn't do it
- some other organization is already doing it, so we shouldn't
- we're too stupid to get it right, so we shouldn't do it
- the IETF is too large, so we shouldn't be adding more work

>From your message, I can't tell which of those, or of any number of other 
possible objections, is the basis of your objection.

BTW - all these things were already being worked on in PPVPN. Some were 
even described in the charter.

--On onsdag, juni 18, 2003 09:27:49 +0300 Pekka Savola <[email-masked]> 
wrote:

>>        other as if they were connected to a common LAN segment or a
>>        point- to-point circuit.
>
> We may have to work on the point-to-point L2 VPN case, but I'd like to
> see  alternative approaches to this.
>
> --
> _______________________________________________
> This message was passed through [email-masked], which
> is a sublist of [email-masked]. Not all messages are passed. Decisions on
> what to pass are made solely by Raffaele D'Albenzio.
>

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Jun 2003 12:12:05 +0300 (EEST)

Hi,

> - this is a bad idea/impossible to do well, so we shouldn't do it

Yes to both.

> - some other organization is already doing it, so we shouldn't

No idea about that.

> - we're too stupid to get it right, so we shouldn't do it

Yes.

> - the IETF is too large, so we shouldn't be adding more work

Yes.
 
> even described in the charter.

Fair question, I probably should have included more text in the first 
place :-).

1. Virtual Private LAN Service.  This is Internet-wise ethernet bridging
over routing protocols such as BGP, IS-IS, etc; further, this has
typically little respect for security implications which are implicit (or 
even explicit) in LAN networks.

So, my main points are:

 - we must not overload routing protocols and such infrastructure (IMHO,
this seems an inevitable path the work would go towards..)

 - we must not create complexity by deploying ethernet bridging all over
the Internet.  Our work should be focused on making IP work, not
specifying Ethernet-over-IP (or worse, Ethernet-over-IP as a *service*).

 - it is architecturally wrong: use different subnets, period -- that's 
what those are meant for in the first place!

 - the model has significant security modifications.

Seems like some operators want to move their frame relay (and what have 
you) customers to be bridged over IP, instead of fixing their networks. 
(I'm allowed to say that because I work for an ISP :-).  And vendors are 
desperate to provide to solutions for these "needs".  But is this the 
right approach?  I don't think so.

2. Virtual Private Wire Service

This is slightly better as you're "only" performing point-to-point 
communication.  Same considerations as above apply, to a slightly lesser 
extent.

Btw. how is this different from currently-specified GRE tunneling?  It 
being made a "service"?

3. IP-only L2 VPNs

This seems a subset of case 1), which seems almost reasonable when it's
made for point-to-point links.  I just don't see why folks would really
want anything like this.  I can't figure out *one* area of applicability 
where using layer 3 mechanisms couldn't be made to work around the issue.

---

From: "Vach Kompella" <[email-masked]>
Date: Wed, 18 Jun 2003 09:46:30 -0700

Pekka,

> > - this is a bad idea/impossible to do well, so we shouldn't do it

As a meaningless response, I could just say - it's a good idea.  And it is
possible to do well.  That is, of course, as useless as saying it can't be done
well and is a bad idea because it is unsubstantiated.

> > - we're too stupid to get it right, so we shouldn't do it

Speak for yourself :-)

We're doing it.  Hopefully, we're going to get it mostly right if we don't think
that this is a service that scales to infinity.

> > - the IETF is too large, so we shouldn't be adding more work

So we should not do any new work?!

> this seems an inevitable path the work would go towards..)

If you use LDP, it is NOT a routing protocol.  The specific mode of use
(targeted LDP) is already described in RFC 3036.  The FECs are different, but
the FEC TLV was defined in such a way as to be extensible.

> specifying Ethernet-over-IP (or worse, Ethernet-over-IP as a *service*).

Primarily, folks want to use it as in "Ethernet-over-MPLS".  That may not
necessarily go down well with you either, but think of MPLS as a logical FR.
Providers do not want to change their infrastructure, e.g., replace a FR cloud
with an ATM cloud, then with SONET or GigE.  That's mega-expensive.  By
abstracting the L2 using MPLS, they can provide the L2VPN service without
wholesale infrastructure replacement.

> what those are meant for in the first place!

Use different subnets to create VPNs?  I don't understand what you mean.  VPLS
and VPWS address a requirement for multiple domains (aka VPNs), logically
distinct from and invisible to each other.

> Btw. how is this different from currently-specified GRE tunneling?  It

GRE-tunneling is one option, but only for the transport of the VC.  However, you
need a demux field to identify the VC that you are carrying.  Carrying one
customer VC between a pair of PEs is obviously not adequate.

Tunneling is not new in the IETF.  The fact that you are tunneling what may be
non-IP packets seems to be giving you the heebie-jeebies.  Why?  What about the
tn3270, dlsw, netbios over ip work that has gone on in the past?  A little
massaging to make the packet look like data to be carried over an IP network,
and some implementation details at the edges.

> where using layer 3 mechanisms couldn't be made to work around the issue.

I agree with you on this.  The reason this is there is because some folks want
to do VPLS for IP only, and learn the MACs through the control plane.  I think
once you have VPLS, you don't really need this.

-Vach

---

From: Melinda Shore <[email-masked]>
Date: Wed, 18 Jun 2003 13:18:10 -0400

> We're doing it.

That's an "uh-oh" comment.  It's very common to hear people
say that the IETF doesn't know how to say "no" to new work.
I think the real problem is that many people bringing new
work to the IETF don't know how to accept being told "no"
and it leads to harass-a-thons of the IESG on the one hand
and dubious work on the other.  I think part of committing
to working in collaborative organizations like the IETF is
arguing your case the best you can but agreeing to accept
community consensus even if it doesn't come out the way
you'd like.

> Primarily, folks want to use it as in
> "Ethernet-over-MPLS".  That may not necessarily go down
> well with you either, but think of MPLS as a logical FR.

I think we need to retain a focus on connectionless,
packet-oriented delivery and how to build on that.  I wonder
if we aren't going considerably astray with the growing
emphasis on pseudo-circuits.

Melinda

---

From: "Vach Kompella" <[email-masked]>
Date: Wed, 18 Jun 2003 10:36:14 -0700

Melinda,

"We're doing it" is a statement of fact.  However, we've been doing it for over
two years.  Pseudo-wire work has been ongoing for over 4 years.  MPLS has been
ongoing since 1996 or thereabouts.

I know there are some who think the IETF shouldn't be working on MPLS and its
applications.  I think there are those who think it should be.  I haven't heard
anything that says we are doing this in opposition to a consensus who would like
to see MPLS disappear or move to some other organization.

So you may voice your personal "uh-oh" but show me the consensus "uh-oh" before
I stop.

-Vach

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Wednesday, June 18, 2003 10:18 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
>
>
> > We're doing it.
>

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 18 Jun 2003 11:04:52 -0700

>- the IETF is too large, so we shouldn't be adding more work

This might be a combination of the latter three, but I think it is 
clearer for this WG:

- the IETF's track record for this work so far is quite poor

We have not shown any ability to create standards in this area with 
due speed or predictability. We have not shown the good judgement 
needed to limit the scope of the work we do. (Look at the number of 
L2VPN-based Working Group drafts in PWE3 and PPVPN, much less the 
large number of non-WG documents being actively discussed.

The IETF understands the need for layer 2 technologies for OAM much 
better than we understand the Internet customer's need (or even 
concern) for layer 2 transport of their IP packets. This is because 
we have a tighter relationship with operators than we do with 
Internet users, and because Internet users generally could care less 
about how their ISPs move their traffic as long as they meet the 
service level agreements. The ISPs would love to have better 
cross-vendor interop for the L2VPN technologies, but so far the 
vendors haven't had time to think about that because they have been 
overloaded with the literally dozens of flavors that are being 
discussed in the IETF.

We will never know if there is another organization who could do a 
better job than this because no other organization will take on the 
work while the 800-pound gorilla of standards bodies is flailing 
around in the area. There are certainly other organizations that can 
take it on, such as the MPLS and Frame Relay Alliance. They might do 
just as bad of a job as we have so far, but they could also do much 
better because they are much more focused.

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott W Brim <[email-masked]>
Date: Wed, 18 Jun 2003 14:16:02 -0400

> emphasis on pseudo-circuits.

The IETF does continue to have an emphasis on connectionless,
packet-oriented delivery.  That's our fundamental architecture, without
question.  In the meantime there are customers who want to transition to
c, p-o d but need mechanisms for doing so.  Why did we spend any time on
transition from IPv4 to IPv6?  In order to make transition easier.  They
want to convert.  Do we say outsiders can't convert to our religion,
they can only be born into it?  Do you want them to define their own
ways to do [virtual] circuit emulation?

---

From: Uri Blumenthal <[email-masked]>
Date: Wed, 18 Jun 2003 14:24:56 -0400

On 6/18/2003 1:18 PM, Melinda Shore wrote:
>>We're doing it.
> 
> .......the real problem is that many people bringing new
> and dubious work on the other. 

:-) :-)

I agree.

> emphasis on pseudo-circuits.

Again, I agree and support.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 18 Jun 2003 20:40:02 +0200

> the FEC TLV was defined in such a way as to be extensible.

And when you want to do this inter-domain? Everything else seems to 
have made it's way into BGP so I think that Pekkas concerns are valid...

> wholesale infrastructure replacement.

Most of these providers have bought what their vendor told them to buy, 
but let's not go into that here.

> distinct from and invisible to each other.

Pekka is right in that most of the applications of VPNs today could 
actually be solved as good with "real addresses" and routing across 
networks.

> customer VC between a pair of PEs is obviously not adequate.

L2TPv3? Whats the advantage with this over the existing protocol that 
the IETF have?

> - kurtis -

---

From: Randy Bush <[email-masked]>
Date: Wed, 18 Jun 2003 10:54:21 -0700

> "We're doing it" is a statement of fact.  However, we've been
> doing it for over two years.  Pseudo-wire work has been ongoing
> for over 4 years.  MPLS has been ongoing since 1996 or
> thereabouts.

no disagreement.  the question i am hearing is not why is this
being done, but rather why is the ietf working on a an l2 over l2
protocol.  should we be doing frame over atm?  ether over atm?

randy

---

From: Melinda Shore <[email-masked]>
Date: Wed, 18 Jun 2003 15:31:56 -0400

> c, p-o d but need mechanisms for doing so.

Personally I'd find this proposal more compelling if it
were being presented as being oriented towards transitional
mechanisms.  We're seeing circuit-y proposals show up in
other working groups and I'm concerned that these reflect a
shift in basic assumptions about the characteristics of the
underlying network, at least among a non-trivial number of
participants.  

As a process kind of thing, I'm also concerned about the
growth of the "temporary" sub-IP area, so I think there are
issues here with both the work itself and in how the IETF
goes about taking on and structuring its work.

Melinda

---

From: "Vach Kompella" <[email-masked]>
Date: Wed, 18 Jun 2003 13:06:46 -0700

> have made it's way into BGP so I think that Pekkas concerns are valid...

That's only because the IETF hasn't made security easy enough, light enough, or
something.  Now some people use the argument that everything should go into BGP
because "opening another port into the provider network is a security breach."
Why is port 646 (LDP) any more insecure than port 179 (BGP)?

> but let's not go into that here.

Sheesh!  No, let's go there.  You're talking about my potential customers, and I
want to know if they really are so dense that I shouldn't have been spending all
this time working on a protocol - I could have just given them a couple of
high-priced tin cans and a piece of string.

Who exactly the IETF is going to be providing protocols for?  For protocols such
as these, it is the providers who deploy them.  You claim that most of the
providers have little or no discernment.  Let's give credit to the providers.
There are a large number of them who know what they are doing.  Many of them
participate in the standards.

> actually be solved as good with "real addresses" and routing across

You probably haven't read the requirements documents then.

-Vach

---

From: "Vach Kompella" <[email-masked]>
Date: Wed, 18 Jun 2003 13:31:38 -0700

Paul,

> - the IETF's track record for this work so far is quite poor

That's not a problem of the ppvpn group only.  It is a problem of the IETF.

I don't need to refresh your memory about IPSec, do I?  SKIP, Skeme, Oakley,
IKE.  AH or ESP with auth?  5 years of bloody fighting.

It's wherever the action is that the political jostling for position is the most
prominent.  That's also where the leadership needs to be strong and participants
need to have a "nose to the grindstone" attitude.  That's hardly an indication
that the work should not be chartered or worked upon.

> large number of non-WG documents being actively discussed.

Do you think the new L2VPN charter addresses these concerns of scoping?  How
about the timelines?  Basically, it's going to be a WG issue, chairs and
participants, to finish the WG charter items first.

> overloaded with the literally dozens of flavors that are being

Are you talking PWE3 or L2VPN?

The gazillion drafts is in PWE3.  The interop issues are localized to the drafts
with contention, silly issues of where bits should go.

There are 16 pseudowire types:
           0x0001   Frame Relay DLCI
           0x0002   ATM AAL5 SDU VCC transport
           0x0003   ATM transparent cell transport
           0x0004   Ethernet Tagged Mode
           0x0005   Ethernet
           0x0006   HDLC
           0x0007   PPP
           0x0008   SONET/SDH Circuit Emulation Service Over MPLS (CEM) [8]
           0x0009   ATM n-to-one VCC cell transport
           0x000A   ATM n-to-one VPC cell transport
           0x000B   IP Layer2 Transport
           0x000C   ATM one-to-one VCC Cell Mode
           0x000D   ATM one-to-one VPC Cell Mode
           0x000E   ATM AAL5 PDU VCC transport
           0x000F   Frame-Relay Port mode
           0x0010   SONET/SDH Circuit Emulation over Packet (CEP)

At least half of these are and have been interoperable.  It is the harder (and
more arcane, IMHO) PW types that people are having a hard time coming to some
sort of compromise.

BTW, I'm glad to see you have a healthier respect for providers than Kurtis who
claims that "most of these providers have bought what their vendor told them to
buy."

> better because they are much more focused.

An 800-pound gorilla conjures up images of one less nimble of foot.  IMHO, not
the right metaphor for the IETF.

-Vach

---

From: "Vach Kompella" <[email-masked]>
Date: Wed, 18 Jun 2003 13:39:39 -0700

Melinda,

> goes about taking on and structuring its work.

And proposals have been made to dismantle the SUBIP area and place the remaining
WGs in the most appropriate areas (some of them are pretty much done with their
chartered work).  The chartering of L2 and L3VPN WGs gives a little more focus,
and limits the solution space.

It's not the creation of the temporary SUBIP area that caused the growth of the
WGs.  It's the natural progression of the opportunities that MPLS provided that
led to the application WGs such as PWE3, PPVPN, etc.

-Vach

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 18 Jun 2003 16:17:18 -0700

>That's not a problem of the ppvpn group only.  It is a problem of the IETF.

Generally agree.

>IKE.  AH or ESP with auth?  5 years of bloody fighting.

I'm not sure how to argue with the statement "the IETF has done a 
horrible job with a similar working group, so we want our working 
group in the IETF".

First off, I agree with you about the IPsec WG, and think it is a 
very good indicator of what the IETF does poorly, particularly in the 
area of focus. (Hint: look at the number of WG Internet Drafts there 
are right now in IPsec that no one is working on.) The problems in 
the IPsec WG and others are typical of the problems of the WGs that 
are working on trusted VPN technologies.

>that the work should not be chartered or worked upon.

Er, yes it is. There is no indication that we will do a better job 
than the terrible job we are doing now. What you propose sounds like 
"we're terrible parents for our six children and barely have enough 
time to pay attention to them, but maybe we'll be better with the 
seventh."

>participants, to finish the WG charter items first.

Why do you think that the re-chartered WG will have any more luck 
with these than the current one? There are a zillion hardware vendors 
and service providers who have reasons to want the dozens of 
documents that are in the current WGs, and it takes very little 
effort on their part to promote their views. The IETF structure does 
poorly in such an environment; maybe a different standards body would 
do better.

>Are you talking PWE3 or L2VPN?

Yes. There is a significant amount of spillage between the two.

>more arcane, IMHO) PW types that people are having a hard time coming to some

And why should the IETF care at all about these? There are other fora 
for layer-2 interworking.

>claims that "most of these providers have bought what their vendor 

He and I might both be right. In my talks with service providers, I 
find that many of them who want to expand their presence in, or just 
get into, the "IP VPN" market look at what hardware they have on hand 
in their core (they certainly can't buy any significant new hardware 
these days) and base their decision on the layer-2 technologies on 
that. Usually, the customers don't know or care. If the customers 
care, they only care enough to ask "are you using MPLS" and then node 
sagely when their service provider says yes. (Humorously, the very 
large service provider who doesn't use MPLS in their core says that 
it usually only takes one or more sentences to convince the 
prospective customer that MPLS is not needed.)

>An 800-pound gorilla conjures up images of one less nimble of foot.

Exactly.

>   IMHO, not

But one that I believe is apt, at least for all of the trusted VPN 
work the IETF is doing currently.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 18 Jun 2003 18:22:45 -0600 (MDT)

> From: Paul Hoffman / IMC <[email-masked]>

> ...

> ...

That's an interesting pair of thoughts.  The obvious guess is that
interested parties are happy with the bad job the IETF has been doing and
are doing a little forum shopping.  In the areas I've been watching (which
do not include IPSEC, DNSSEC, or VPNs), the bad jobs consist of rubber
stamping ideas whose lameness is exceeded only by their complete lack of
interest and any trace of originality.  It's amazing how many people feel
compelled to take a well established idea with many ancient implementations
and write an RFC standardizing a redundant, unnecessary version elsewhere.
(Is that also the deal with this tunnel stuff?)

I suspect the IESG is overtaxed, overextended, and doesn't have enough
thumbs to stick in all of holes in the dikes holding back the floods
of wonderful ideas from marketing departments and junior, not-quite
engineers with ambitions in marketing.

A modest proposal:  Limit the supply of RFC (not to mention BCP)
numbers.  If only 50 RFC numbers were available for the next 12 months,
there would be an incentive for competent people to stick their necks
out and stomp on some of the nonsense to ensure that things that need
consideration would get it.  I doubt the IETF could produce 10 good
RFCs in the next 12 months, so 50 numbers would be generous.

Without that, an equivalent of the IEEE PAR, or some other effective
mechanism, the IETF is going to suffer the fate dictated by Gresham's
Law of any mint that fails to control its output.

Vernon Schryver    [email-masked]

---

From: Scott W Brim <[email-masked]>
Date: Wed, 18 Jun 2003 20:53:07 -0400

On Wed, Jun 18, 2003 03:31:56PM -0400, Melinda Shore allegedly wrote:
> > packet-oriented delivery.  That's our fundamental architecture,
> > without question.  In the meantime there are customers who want to
> > transition to c, p-o d but need mechanisms for doing so.
> 
> Personally I'd find this proposal more compelling if it were being
> presented as being oriented towards transitional mechanisms.  

You're right, that doesn't get mentioned.  However, many providers see
it that way.  (Admittedly there are some who don't.)

> We're seeing circuit-y proposals show up in other working groups and
> I'm concerned that these reflect a shift in basic assumptions about
> the characteristics of the underlying network, at least among a
> non-trivial number of participants.  

People who can't see beyond the circuit approach shouldn't be given
responsibility for Internet architectural thinking, and right now
fundamental architectural thinking is what we need more than anything.

.swb

---

From: "Vach Kompella" <[email-masked]>
Date: Wed, 18 Jun 2003 18:43:53 -0700

Paul,

> horrible job with a similar working group, so we want our working

Well, how about, we can't agree on IPv6 numbering schemes, so let's find another
standards org to fix that problem.  We can't decide whether site-local is good
for IPv6 or not, so let's find another standards org. ...  What kind of
unmitigated disaster would IKE have been if we had just punted it over to, say,
the ITU?

Alternatively, we can own up that it is OUR problem, i.e., the IETF, and if we
want a solution, we will create one here.  E.g., I'm happier having IPSec than
no security.

<similar problems in IPSEC snipped>

> time to pay attention to them, but maybe we'll be better with the

No, it's not.  Having a seventh child is an option.  No-one is clamoring for
that seventh child.

It's more like having seven kids and not having enough money for 7 holiday
gifts, and so declaring that one of the kids should go to a foster parent.

> poorly in such an environment; maybe a different standards body would

I thought that Moskowitz and Tso did a pretty good job of not letting new stuff
into IPSec towards the end.

Is there no perceptible difference between the rather open-ended ppvpn charter
and the rather more focused l2vpn/l3vpn charters?  Maybe that was a leading
question :-)

I have rather studiously avoided submitting three new drafts that may address
issues that some folks have raised concerns about.  As usual, thinking up new
thoughts and solutions is a lot more fun than finishing the job at hand.  That's
where individual submissions should stay until the current plate is cleaned up.
No time in the agenda, nothing but mailing list and individual submission
opportunity.

> Yes. There is a significant amount of spillage between the two.

Not really.

> for layer-2 interworking.

OK.  Which of those arcane PWs is relevant to ppvpn?  The ones ppvpn is
concerned with are pretty well established and interoperable.

-Vach

---

From: Eric Rosen <[email-masked]>
Date: Wed, 18 Jun 2003 23:18:28 -0400

People need to understand that the purpose of the Pseudowire stuff (PWE3) is
to enable service providers to  offer existing services over IP networks, so
that they can convert their backbones to IP without first requiring that all
their  customers change  their  access equipment.   Producing the  protocols
needed to enable  migration from legacy networks to IP  networks seems to me
to  be quite in  the mainstream  of IETF.   The technical  issues, involving
creating tunnels, multiplexing  sessions through tunnels, performing service
emulation at the  session endpoints, are all issues that  the IETF has taken
up in the past, there is nothing radically different going on here. 

(To those  who think that other  standards organizations can  do this better,
well, representatives from those other organizations feel free to drop in on
the WGs  in question, so  we are familiar  with their level of  expertise on
IP.   Let's just  say that  if we  want to  aid in  the migration  of legacy
networks to IP, these other organizations are not what we would want to rely
on.) 

One can think of the VPWS work  in L2VPN as taking the PWE3 stuff and adding
some IP-based auto-discovery  mechanisms to facilitate provisioning.  Again,
this isn't out of line with what the IETF typically does. 

The VPLS work is  more difficult to position within the IETF,  as it is hard
to  avoid a lot  of stuff  that overlaps  with IEEE  (a standards  org which
really is  worthy of  respect, unlike some  others), and  extending ethernet
over an IP network  is arguably a bad idea.  On the  other hand, the purpose
is the  same as  indicated above; service  providers can migrate  from their
Q-in-Q  ethernet networks  to  IP networks,  without  first requiring  their
customers to switch from an ethernet service to an IP service.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 18 Jun 2003 19:40:52 -0700

At 6:43 PM -0700 6/18/03, Vach Kompella wrote:
>for IPv6 or not, so let's find another standards org.

IPv6 is an IP technology. We are supposed to know how to make it 
work. L2VPNs (and half of the interesting parts of 2547bis L2VPNs) 
are outside the scope of our expertise.

>  ...  What kind of

Worse, no doubt. But I'm not proposing to send the L2VPN work to an 
organization with no expertise or credibility in the L2 area.

>want a solution, we will create one here.

If we decide that "the problem" is one in our realm, I fully agree. 
But transporting layer 2 stuff over IP is not a problem that affects 
the Internet. It is a problem for the service providers marketing 
departments. The past three yeas have proven that service providers 
can satisfy their customers needs with L3VPNs, with 
somewhat-interoperable L2VPNs, with non-interoperable L2VPNs, and 
with just plain layer 2 circuits. What is "the problem" that the IETF 
needs to standardize?

>   E.g., I'm happier having IPSec than
>no security.

Of course. But we'd both be happier if IPsec worked better as a VPN 
technology, and applications folks would be happier if it worked 
better as an application security technology.

--Paul Hoffman, Director

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 19 Jun 2003 07:33:54 +0200

> Why is port 646 (LDP) any more insecure than port 179 (BGP)?

Well, I think it's more to it than this. BGP doesn't traverse 
firewalls, at least not in most cases. I think the reason more and more 
is being put into these protocols is because "they are there". It's 
simply easier than thinking about the implications of doing this.
>>> not

Somehow I didn't think this comment would go unnoticed.  ;-)

> high-priced tin cans and a piece of string.

Notice that I have been one of those customers. Actually one of the 
largest outside the US. I have spent more time listening and talking to 
vendors on these issues than I like to think about. What struck me was 
how often vendors would come and tell me that provider Y bought this, 
so this should work for you to. When you then asked the vendors to go 
the economics of these decisions, and also the economics of the 
alternatives - you get everything from false and fabricated figures to 
vendors who simply can not answer. I actually remember very few 
occasions  when I got a full explanation of why a certain technology 
would help me and where I could see the benefits.

> participate in the standards.

Providers go with technology that is a) cheap b) hight margin. Did 
providers start selling MPLS based VPNs (L2 & L3) because the demand 
was so huge? No, some providers and vendors created the demand. For 
some providers this works very well and fitted the strategy.

Yes, there are providers who work on standards in the IETF. 
Unfortunately I think they are way to few though.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 19 Jun 2003 08:00:10 +0200

On torsdag, jun 19, 2003, at 01:17 Europe/Stockholm, Paul Hoffman / IMC 
wrote:

> (Humorously, the very large service provider who doesn't use MPLS in 
> their core says that it usually only takes one or more sentences to 
> convince the prospective customer that MPLS is not needed.)

My experience as well. I lost count of how many times I had the 
following conversation :

C: But MPLS gives me encryption!
Me: Err, nope.
C: Oh? But that is what Vendor X and provider Y told me?
Me: Have you looked at the technology?
C: No....

Re-iterate.

I have had the same discussion with C replaced with provides. That is 
when I got scared.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 19 Jun 2003 08:54:44 +0200

> up in the past, there is nothing radically different going on here.

But how many of these protocols do we need? And how do we want this 
done?

We are complaining that the IETF have to much work, and still we 
replicate the same functionality in several WGs....

- - kurtis -

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Jun 2003 10:39:00 +0300 (EEST)

> So we should not do any new work?!

We should focus on the work that is more integral to IP and the Internet.

> the FEC TLV was defined in such a way as to be extensible.

Then LDP has been quite carefully cloaked as being one ("graceful restart 
for LDP, ..") :-)

The problem is of course also with the statement "If you use LDP..".  But
there also seem to be some interests in placing stuff elsewhere, like 
in BGP.

> wholesale infrastructure replacement.

Bridging networks at layer _3_ with VPN's is a bit questionable, but that 
is a bit more in our radar.  I don't think this is something we can 
endorse, as a model.
 
> distinct from and invisible to each other.

Why would you want to do something like:

                     __-----___
 Ethernet           (          )         The _same_ Ethernet
  segment =======  (  Internet  )  ===== segment!
                    (__     ___)
                       -----
Instead, build two separate ethernet segments: one with IP addressing from 
1.1.1.0/24 and the other from 1.1.2.0/24.  You may even want to build a L3 
VPN between the two.

But Ethernet?  That seems misguided.

> customer VC between a pair of PEs is obviously not adequate.

I meant GRE tunneling between CPE's. :-)

> and some implementation details at the edges.

I remember the multipoint media happen to have some assumptions about the 
network, e.g. the use of interpacket delay and the use collision 
detection.  These change a lot of when you expand the scope of an Ethernet 
beyond a physical segment.  Of course, these may not be always 
problematic, if you require switched Ethernet segments, but the thought is 
worrisome regardless.

Moreover, we work on an IP layer.  We enable IP layer to be able to handle 
our tasks.  If there is some problem why we cannot just use different IP 
subnets between the two (or multiple) end-points, we need to fix that 
problem, not burrow even further down the ISO layers.

---

From: grenville armitage <[email-masked]>
Date: Thu, 19 Jun 2003 21:47:20 +1000

Pekka Savola wrote:
	[..]
> problem, not burrow even further down the ISO layers.

Oh. A layering purist. I knew something didn't seem quite right.

And "just use different IP subnets" would solve mobile IP?

cheers,
gja  (who should probably be disbarred for having once run IP over ATM
over UDP/IP between New Jersey and Georgia because, well, there
just wasn't a 'real' ATM link at the time and moving ATM cells
was my task...)

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Jun 2003 10:32:48 -0400

>        connected to a common LAN segment.

I do not believe this is a technically reasonable goal.  if even switched
Ethernets do not work right for multicast (which, remember, is essential for
IPv6) how do you expect tunneled and routed Ethernet to work right? and don't
tell me you want the routers to snoop for multicast join/leave messages --
that's just too broken.

Now, if you want to define a pseudo-L2 service that uses Ethernet hardware and
framing as a substrate, but has explicit L2 multicast control, that might be
worth considering.  But don't make it just for tunneling L2 over IP networks,
design it so it can be a truly general-purpose means of gaining access to 
the Internet over an Ethernet - replacing PPPoE and other kludges.

Really, we need a plug-and-play way by which hosts can figure out how to
connect to the Internet and authenticate themselves, one that gives each host
the address and connectivity it's supposed to have independently (within
reason) of where it's plugged in to the network, and one that would be general
enough for every network to use instead of this hodgepodge of DHCP/PPP/etc.

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 Jun 2003 11:18:14 -0700

> led to the application WGs such as PWE3, PPVPN, etc.

Not all of PPVPN is based on MPLS. Some of us are doing real IP VPNs, 
using IPsec, etc.

Joe

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 20 Jun 2003 10:41:50 +0200

> goes about taking on and structuring its work.

in case someone missed it.... both the L2VPN and L3VPN WGs are being 
proposed within the *INTERNET* area.

                     Harald

---

From: Alex Zinin <[email-masked]>
Date: Sat, 21 Jun 2003 22:26:35 -0700

Folks-

 Having watched this discussion, it seems a couple of data points
 might be helpful:

 1. L2VPN and L3VPN proposed WGs are part of PPVPN WG split

    Creation of L2VPN and L3VPN WG does not represent addition of new
    work to the IETF. They are created as part of the process of
    splitting the PPVPN WG to improve progress and focus it by setting
    clear directions in the charters.

 2. L2VPN work is already chartered within the IETF

    The discussion about whether this work should be chartered or not
    happened when the PPVPN WG was being created. Please see minutes
    and slides from the PPVPN BOF at IETF 49. L2VPN solutions are
    within the PPVPN charter and milestones.

 Hope this helps.

Alex

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 23 Jun 2003 08:52:34 -0700

>     within the PPVPN charter and milestones.

My comments about possibly moving this work to a different standards 
body is based on our track record with this work so far in the IETF, 
not a worry about new work.

Just because we chartered some work doesn't mean we shouldn't revisit 
the question of whether or not doing so was a good idea, particularly 
after we see the kind of progress that has been made and the problems 
that have come up under those charters.

--Paul Hoffman, Director

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 25 Jun 2003 09:00:28 -0700

Paul,

> due speed or predictability. 

I certainly agree with your on the "track record". But I think we
need to be a bit more specific on why the track record is "quite
poor". For example, why the IESG didn't approve 2547bis as a Proposed
Standard 2 years ago ?  Ditto for draft-martini... Perhaps folks
from the IESG would care to explain this...

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 25 Jun 2003 08:43:41 -0700

Paul,

> >Alternatively, we can own up that it is OUR problem, i.e., the IETF, and if 
> >we want a solution, we will create one here.
> 
> with just plain layer 2 circuits. 

I certainly agree with you that there are enough examples that
clearly show that service providers can satisfy their customers
needs with *multi-vendor* *interoperable* implementations based on
the *open* specs, where the spec is an Internet Draft, rather than
an IETF standard. In other words, an Internet Draft + working code
is both necessary *and* sufficient.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 25 Jun 2003 09:42:19 -0700

Paul,

> - the IETF's track record for this work so far is quite poor

the attached e-mail that have been posted to the PPVPN mailing
list sheds some light on why the IETF's track record for this
work so far is quite poor.

Yakov.
---------------------------------------------------------------------
Date:         Sun, 4 May 2003 13:24:58 -0700
Reply-To:     PPVPN <[email-masked]>
Sender:       PPVPN <[email-masked]>
From:         [email-masked]
Subject:      Strategy for VPN work in IETF
Comments: To: [email-masked]
Comments: cc: [email-masked]

Alex Zinin writes:

> Since San Francisco IETF meeting the IESG has been considering the
> situation in the SUB-IP area and in the PPVPN Working Group in
> particular.

> Such close attention to this WG was triggered by numerous concerns

> thatthe IESG members received from the WG participants about limited
> and slow progress within the WG despite the efforts of the WG chairs
> and its members. The IESG also used this opportunity to consider
> the IETF area that the PPVPN work would fit best.

> After much deliberation, the involved ADs (Bert, Thomas, and I) are
> considering the following organizational changes in order to
> improve WG focus and productivity and ensure faster progress of the
> VPN-related work:

> 1. Split of Layer-2 and Layer-3 VPN work in separate Working Groups.

>   The L2 and L3 VPN work spaces are each big enough to warrant a
>   separate WG. While concentration of all VPN-related work in a
>   single forum was the right thing to do to ensure coordination
>   of efforts when the PPVPN WG was created and L2 VPN work came in,

>   such concentration is causing scaling problems within the WG at
>   this moment.

>   Migration of work into two separate WGs for L2 and L3 VPN
>   technologies with more specific WG charters will help to focus
>   discussions, prevent staff and meeting time overloading, and will
>   aid faster progress of corresponding technologies.

Alex,
The proposed solution ignores the origins of the problem.

The fact that PPVPN has been making any progress at all, despite the
bureaucracy imposed on it by the IESG is rather comendable.

This is a typically example of a WG which was setup despite many architectural
objections that it doesn't fit in the "internet" design. One cannot help
but to suspect that there was the hope ammoung the inner circles that
it would fail altogether. At least giving the ammount of "framework"
nonsense required and the interdiction to discuss solutions before a
framework is agreed upon.

The work of this working group is particularly harder given that this
is todays "fashion" area... work is much harder on such areas (like mpls
was a couple of years ago). One would suspect that the IESG
efforts to slow the WG steem also from concerns that fashion areas tend
to create a fair ammount of nonsense proposals most of which tend to
be naturally eliminated by the WGs.

Given the environment the performance of the ppvpn WG seems to me to
rather positive. It has actually come up with several documents that
are useful and deserve publication.

One of the reasons given here for this proposed disolution of the WG
is that the "L2VPN and L3VPN work spaces are big enought". However both
in the list and WG meetings it seems to me that the current l3vpn WG
is close to 0. The base document on l3vpn has been rather stable for
a while and it is not likely to change. The IESG/inner-circle has chosen
for mostly ideological reasons to attempt to marginalize this work so
it can hardly expect to be heard now.

It seems to me that if there is a problem w/ PPVPN that problem lies
within the IESG itself. As such i would like to propose to split the
IESG in two WGs: one that concerns itself w/ architecture and one group
that concerns itself with the process of documenting interoperable solutions
that are not known to be good or bad ideas until used in pratice. This
latter group should have the task to assure that the process is fair
and that both the pluses and minus of a solution are considered and documented.

One of the ideal caractheristics of the latter group would be if they
where to realize that by definition an IESG member is much less of an
expert in a given domain than the membership of the WG it steers. It
is humanly impossible for it to be otherwise. Unless you assume that
the membership of WG is 100% incompetent which is never the case. A steerer
cannot possibly be an expert in 20 groups it oversees... usually it can't
even keep up with the problems and technology due to the fact that there
is only 24 hours in each day.

In the rather arrogant terms of internet engineering, the IESG is by
definition the set of people that are "clueless". It is not possible
for it to be the other way around. No matter how wise and inteligent
IESG memebers are...

It is necessarly that the IESG understands that latter point and restricts
its job to document in a timely manner interoperable solutions for the
problems at hand regardless of personal opinion on the value of such
problems and technologies.
- ----

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 25 Jun 2003 12:46:37 -0600 (MDT)

> From: Yakov Rekhter <[email-masked]>

> problems and technologies.

That is a valid position only if you assume the premise that the
IETF should publish RFCs on any and all subjects.

If you don't accept that premise but instead think the IETF should
only publish RFCs related to the Internet, then the inevitable
ignorance of the IESG is a valuable feature.  If the IESG is clueless
about something, then it is likely that whatever it is should be
handled outside the IETF.

It seems clear that much of the pressure for the IETF to deal with
this particular area as well as some other areas that have nothing
to do with "Internet engineering" is due to "forum shopping" by
people and organizations that also see the inevitable ignorance of
the IESG and IAB as a positive feature.  However, their intended
utilization of that ignorance is not respectable.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 25 Jun 2003 23:46:23 +0300 (EEST)

> And "just use different IP subnets" would solve mobile IP?

No; the primary goal of Mobile IP to provide connection survability.  
Unchanging IP address is just a means to get that.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 30 Jun 2003 08:03:32 +0200

> work so far is quite poor.

since we've started recycling other people's arguments, let me repost what 
Brian Carpenter replied on problem-statement too... nobody else rose up to 
refute him there on this issue.

> My spam filters decided to put it in the junk. But it neatly
> illustrates the issue we have when the I* tries to look at
> the big picture, and a special interest group looks only at its
> own small area - there is a genuine conflict of interest, and
> the IETF and its processes are set up to favour the big picture.
> That is not a problem IMHO. It's exactly correct, except that we
> have to explain it better to the special interest groups.
>
>    Brian

---

From: Paul Vixie <[email-masked]>
Date: 30 Jun 2003 07:36:24 +0000

[email-masked] (Harald Tveit Alvestrand) writes:

> ... nobody else rose up to refute him there on this issue.

ok, i'll bite.

> > illustrates the issue we have when the I* tries to look at the big
> > picture, and a special interest group looks only at its own small area
> > - there is a genuine conflict of interest, and the IETF and its
> > processes are set up to favour the big picture.  That is not a problem
> > IMHO. It's exactly correct, except that we have to explain it better to
> > the special interest groups.

if the ietf could have goals, and one of them was to become dilute and
ineffectual, then the words "exactly right" above are, well, exactly right.
(priority focus on the big picture used to be more exactly right than it
is today, since the big picture in 1989 had fewer moving parts than today.)

so, i don't know if i'm refuting him exactly, but i do surely disagree.
it's only "not a problem" if someone takes a nondilute "bite sized" ("useful")
view of cross-special groups.  otherwise we'll have the special groups
in heads-down sandbox mode, doing work with no architectural connection to
their brothers and sisters in the next sandbox over, while the general
interest groups are trying to move continents but getting no traction. (oops.)
-- 
Paul Vixie

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 30 Jun 2003 12:30:43 +0200

> from the IESG would care to explain this...

It might have something to do with the fact that the WG has not requested 
that the IESG process these drafts.... if the WG has not come to consensus 
on asking for the drafts to be published, I'm afraid the IESG cannot do 
anything.

NOTE: I am completely aware that IESG members have been active in the 
architectural discussions that have led to the WG not asking for 
standards-track publication on these drafts. But the reason for these 
non-actions is, I believe, to be found in the *working group* process.

                Harald, who is NOT active in ppvpn

---

From: Eric Rosen <[email-masked]>
Date: Mon, 30 Jun 2003 11:26:12 -0400

Harald> It might  have something  to do with  the fact  that the WG  has not
Harald> requested that the  IESG process these drafts.... if  the WG has not
Harald> come  to consensus on  asking for  the drafts  to be  published, I'm
Harald> afraid the IESG cannot do anything. 

I consider this answer to be rather disingenuous.

The WG has  not requested that the IESG process these  drafts because the WG
chairs have  told the  WG that  the ADs have  told them  that the  drafts in
question cannot be submitted to the IESG until numerous other drafts that no
one  will  ever  read  (requirements,  framework,  architecture)  have  been
approved by the  IESG.  Of course, most of those  numerous other drafts were
completed about 18 months ago, though a few of them have now come out of the
seemingly endless  "IESG reviews,  WG makes minor  change, IESG  reviews, WG
change" cycle.  

So you  can't honestly  answer Yakov by  saying "the  WG hasn't asked  us to
process  these  drafts";  the  answer   to  Yakov's  question  would  be  an
explanation of (a) why all these  prior drafts are really necessary, (b) why
it is reasonable for such a long  review cycle, and (c) why it is reasonable
to delay  starting to process the  protocol specs until the  prior specs are
already on the RFC Editor's queue.