Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
--On onsdag, juni 25, 2003 09:42:19 -0700 Yakov Rekhter [EMAIL PROTECTED] wrote: 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. 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
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
[EMAIL PROTECTED] (Harald Tveit Alvestrand) writes: ... nobody else rose up to refute him there on this issue. ok, i'll bite. 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. 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
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
--On onsdag, juni 25, 2003 09:00:28 -0700 Yakov Rekhter [EMAIL PROTECTED] wrote: 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... 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
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
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.
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
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. 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. 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.
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
Paul, At 10:15 AM +0200 6/18/03, Harald Tveit Alvestrand wrote: 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 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. 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.
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
Paul, At 10:15 AM +0200 6/18/03, Harald Tveit Alvestrand wrote: 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 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 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 PROTECTED] Sender: PPVPN [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: Strategy for VPN work in IETF Comments: To: [EMAIL PROTECTED] Comments: cc: [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
From: Yakov Rekhter [EMAIL PROTECTED] ... 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. 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. Vernon Schryver[EMAIL PROTECTED]
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
Melinda, 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. What makes you think that MPLS does not support connectionless packet-oriented delivery ? Yakov.
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
Pekka, [clipped...] 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. 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*). The proposed charter talks about VPLS across an IP and an MPLS-enabled IP network. Such a network does not have to be the Internet. Yakov.
RE: WG review: Layer 2 Virtual Private Networks (l2vpn)
Randy, 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. Would you please elaborate on what makes MPLS an L2. For that matter would you also explain what makes MPLS a layer on its own. randy
Re: Layering purity Re: WG review: Layer 2 Virtual Private Networks(l2vpn)
On Thu, 19 Jun 2003, grenville armitage wrote: Pekka Savola wrote: [..] 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. Oh. A layering purist. I knew something didn't seem quite right. 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. 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...) -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
On Wed, 25 Jun 2003, Yakov Rekhter wrote: 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. 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*). The proposed charter talks about VPLS across an IP and an MPLS-enabled IP network. Such a network does not have to be the Internet. Of course; but I think it is reasonable to assume that in most cases it is. Also, remember where the I in IETF comes from. That's what our main focus should be at. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
At 10:26 PM -0700 6/21/03, Alex Zinin wrote: 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. 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 --Internet Mail Consortium
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
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
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
--On onsdag, juni 18, 2003 15:31:56 -0400 Melinda Shore [EMAIL PROTECTED] wrote: 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. in case someone missed it both the L2VPN and L3VPN WGs are being proposed within the *INTERNET* area. Harald
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. 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... 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)? 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 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. Most of these providers have bought what their vendor told them to buy, but let's not go into that here. Somehow I didn't think this comment would go unnoticed. ;-) 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. 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. 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. 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 - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPvFLR6arNKXTPFCVEQJ3LgCgzDrvaeUi0j/xWKhBhPNWic9fC2oAoMEj sTC9ToVkbZP6CRHO/q1uXp64 =rSyl -END PGP SIGNATURE-
RE: WG review: Layer 2 Virtual Private Networks (l2vpn)
On Wed, 18 Jun 2003, Vach Kompella wrote: - the IETF is too large, so we shouldn't be adding more work Yes. So we should not do any new work?! We should focus on the work that is more integral to IP and the Internet. 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..) 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. 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. - 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*). 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. 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. - it is architecturally wrong: use different subnets, period -- that's 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. 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. 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? 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. I meant GRE tunneling between CPE's. :-) 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. 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. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
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 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.
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
Vach Kompella wrote: Melinda, 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. 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. Not all of PPVPN is based on MPLS. Some of us are doing real IP VPNs, using IPsec, etc. Joe
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
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 Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
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 PROTECTED] wrote: 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 Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
* * 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 * Harald, Here is one more to consider: maybe it is outside the mainstream of the Internet architecture. [Optimizing to leave IP out of the stack and do direct L2 communication certainly SOUNDS like a retrograde step to me, too. Twenty years ago I was arguing with a UCLA professor, who insisted that IP was too much overhead and that he needed to do direct LAN transmission to get adequate performance for his distributed file system. He eventually figured out the fallacy, because the product produced by his company had the IP layer in place. Have we forgotten these lessons?] There is an infinite number of variations on the technology that the IETF COULD develop, and for every one, there is some vendor or set of vendors who would love to be able to sell sanctioned boxes. That does not mean it is in the best interest of the community or the technology to develop them all. I believe that the IESG needs to say NO more often. I know that's tough, but that's why we chose such excellent members of the IESG. Bob Braden
RE: WG review: Layer 2 Virtual Private Networks (l2vpn)
Pekka, On Wed, 18 Jun 2003, Harald Tveit Alvestrand wrote: 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 Yes to both. 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 Yes. 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 Yes. So we should not do any new 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. 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..) 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. - 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*). 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. - it is architecturally wrong: use different subnets, period -- that's 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. - 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? 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. 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. 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
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
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
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
On 6/18/2003 1:18 PM, Melinda Shore wrote: We're doing it. ...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 agree. 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. Again, I agree and support.
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - we must not overload routing protocols and such infrastructure (IMHO, 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. 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... - 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*). 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. Most of these providers have bought what their vendor told them to buy, but let's not go into that here. - it is architecturally wrong: use different subnets, period -- that's 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. 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. Btw. how is this different from currently-specified GRE tunneling? It being made a service? 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. L2TPv3? Whats the advantage with this over the existing protocol that the IETF have? - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPvCyBKarNKXTPFCVEQL6DQCfSLe3xKzNpU+Me8j4lFuGJojeu+oAoKAP WdkmzQyNXqX4UfhZdIc8XX1g =iysk -END PGP SIGNATURE-
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
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. 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
RE: WG review: Layer 2 Virtual Private Networks (l2vpn)
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. 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... 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)? - 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*). 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. Most of these providers have bought what their vendor told them to buy, 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. - it is architecturally wrong: use different subnets, period -- that's 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. 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. You probably haven't read the requirements documents then. Btw. how is this different from currently-specified GRE tunneling? It being made a service? 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. L2TPv3? Whats the advantage with this over the existing protocol that the IETF have? - kurtis - -Vach
RE: WG review: Layer 2 Virtual Private Networks (l2vpn)
Paul, At 10:15 AM +0200 6/18/03, Harald Tveit Alvestrand wrote: 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 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 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. 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. 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. 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. 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. 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. An 800-pound gorilla conjures up images of one less nimble of foot. IMHO, not the right metaphor for the IETF. --Paul Hoffman, Director --VPN Consortium -Vach
RE: WG review: Layer 2 Virtual Private Networks (l2vpn)
Melinda, 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. 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. Melinda -Vach
RE: WG review: Layer 2 Virtual Private Networks (l2vpn)
At 1:31 PM -0700 6/18/03, Vach Kompella wrote: - 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. Generally agree. 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. 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. 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. 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. 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. 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. 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. 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. Are you talking PWE3 or L2VPN? Yes. There is a significant amount of spillage between the two. 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. And why should the IETF care at all about these? There are other fora for layer-2 interworking. 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. 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
RE: WG review: Layer 2 Virtual Private Networks (l2vpn)
From: Paul Hoffman / IMC [EMAIL PROTECTED] ... 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. ... And why should the IETF care at all about these? There are other fora for layer-2 interworking. 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 PROTECTED]
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
On Wed, Jun 18, 2003 03:31:56PM -0400, Melinda Shore allegedly wrote: 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. 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
RE: WG review: Layer 2 Virtual Private Networks (l2vpn)
Paul, At 1:31 PM -0700 6/18/03, Vach Kompella wrote: 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. 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 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. 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. 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. 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. 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. Are you talking PWE3 or L2VPN? Yes. There is a significant amount of spillage between the two. Not really. 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. And why should the IETF care at all about these? There are other fora 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. --Paul Hoffman, Director --Internet Mail Consortium -Vach
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
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.
RE: WG review: Layer 2 Virtual Private Networks (l2vpn)
At 6:43 PM -0700 6/18/03, Vach Kompella wrote: 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. 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. 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 unmitigated disaster would IKE have been if we had just punted it over to, say, the ITU? 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. 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. 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 --Internet Mail Consortium
