RE: IETF58 - Network Facts
Well I was one satisfied customer :-) ---In other news-- (Think Red Cross, don't think Power Company) I had six people come up to me on Thursday to let me know that their wireless connection was acceptable (they used words like great, and no problems). I hope that more people would take the time to document their positive experiences. This will give us more perspective on the total experience and it is the only payment these volunteers get from this community. Except for some initial hiccups on Monday, and one location (hotel lobby by the reception desk, where I think the hotel was supposed to have turned off their APs, but clearly didn't), I had pretty near flawless connectivity. Regrettably, I was using an OS not known for its reliability. I had built-in wireless too, which I wasn't sure was going to work because of reception issues at another conference. At this point, we know the issues, we know the complaints. Right now, it would be nice to hear where the network did work, and some positive comments. A message to [EMAIL PROTECTED] would be great. I am going silent on this list for a while, don't want to stir things up too much. Responses will be made privately if warranted. --Brett -Vach
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)
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)
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: a personal opinion on what to do about the sub-ip area
Let's also let the VRRP WG decide on the fate of SIP WG documents, the CALSCH WG decide on the fate of OSPF WG docs... Let's particularly ignore the fact that the folks closest to the issues have the most interest in getting the best possible outcome. You might not think that's a fair analogy, but it's really the constituents who are most impacted by the decision, not the IETF as a whole. I'm not sure why the other IETF WGs or areas would as a whole care about SUBIP, except on principle. And it's not like they don't have a voice (this mailing list and particularly the plenaries). I think the request for comments might be targeted at a slightly larger audience (other WGs in the Routing Area, Transport Area, Operations Area, perhaps) whose, since not everyone subscribes to the spam abatement, er, ietf mailing list. -Vach -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Joe Touch Sent: Monday, December 09, 2002 10:34 AM To: Scott Bradner Cc: [EMAIL PROTECTED] Subject: Re: a personal opinion on what to do about the sub-ip area Scott Bradner wrote: for what it's worth here is my personal opionion on what we should do in the question of the sub-ip area I think we should go with the status quo (with the IESG selecting two volunteers to manage the area next March) I do not think that we can make a reasoned decision to do otherwise in the next week. Before Atlanta I was of the opinion that moving the WGs into other areas was the right thing to do, not because of any particular event, but more because we had said this was a temporary area and it was getting to be a long temporary (but I suppose we should note that the last temporary area (ipng) lasted 4 years) But the feedback we got in Atlanta has convinced me that this is not reason enough to make a change. I'll add that most of the attendees at this meeting in Atlanta were from the WGs themselves. It is unsurprising that the overwhelming position of that group is to maintain the status quo. Moving them is definitely seen as unwelcome change from within the groups themselves. It would be useful to hear from the community at large regarding this issue, rather than letting the group decide (essentially) for itself. FWIW, I have yet to see a substantive justification for the _creation_ of a new area yet. I, and others, have pointed out that the 'status quo' here is to let the area dissolve on schedule. Joe
RE: a personal opinion on what to do about the sub-ip area
Here's my personal opinion. I think we have two suck^H^H^H^Hvolunteers :-) I think the area's WGs need ADs who have been close enough to keep the continuity of relations with other standards bodies, the past work, etc. Regarding whether there is a need for an area long-term, it would depend on how we foresee the charter of each WG developing. ccamp: no opinion, since I haven't been keeping pace gsmp: their work is nearly done (according to my interpretation of Avri's comments) ipo: no opinion, since I haven't been keeping pace mpls: long-term ppvpn: possibly long-term tewg: their work is nearly done too (from the tewg minutes posted by Jim Boyle) We don't have visibility into the next year, so we should keep the area as is, which would allow the greatest progress in those WGs that are close to done. We will also know better what to do with the remaining WGs. If at that point, there's still work to be done, but not enough long-term WGs to warrant an area, I am perfectly happy to close the area, and move ccamp and mpls to RTG and ppvpn to (TSV | RTG). -Vach -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott Bradner Sent: Monday, December 09, 2002 8:28 AM To: [EMAIL PROTECTED] Subject: a personal opinion on what to do about the sub-ip area for what it's worth here is my personal opionion on what we should do in the question of the sub-ip area I think we should go with the status quo (with the IESG selecting two suck^H^H^H^Hvolunteers to manage the area next March) I do not think that we can make a reasoned decision to do otherwise in the next week. Before Atlanta I was of the opinion that moving the WGs into other areas was the right thing to do, not because of any particular event, but more because we had said this was a temporary area and it was getting to be a long temporary (but I suppose we should note that the last temporary area (ipng) lasted 4 years) But the feedback we got in Atlanta has convinced me that this is not reason enough to make a change. temporary area (ipng) lasted 4 years) But the feedback we got in Atlanta has convinced me that this is not reason enough to make a change. And any move at this time to move the WGs would be seen as a slap in the face of the quite strong (even if in a limited venue) opinion expressed in Atlanta. Right after Atlanta I was convinced that we should follow the consensus and ask the nomcom to find a AD but upon refection I'm not sure that is the right thing either - partially because as Randy has pointed out, we do not have a clear mission statement for such an area but mostly because enough of the WGs are close enough to finishing up that we whould have a quite small area in 6 months to a year and an area with only 2 or 3 working groups seems a bit of a waste. But if there is a long-term future for sub-IP work in the IETF then aditional working groups may be in the offering. We need the time to reflect on what that future should be. So I think we should continue as-is until: 1/ the WGs which will finish soon finish 2/ we (the IESG, IAB ietf community) figure out what role sub-ip should play in the IETF in the long term but it would be good to hear from more of you both to the IETF list and to the IESG directly Scott
RE: a personal opinion on what to do about the sub-ip area
You normally don't get to last call without having gotten the WG's opinion on whether it should even go to the IESG. I think the IESG expects that due diligence from the WG. It has been pointed out that the sub-ip area meeting had an majority that wished the area to continue, at least for the time being. I don't want that to be ignored, or dismissed as just the choir's opinion. The general solicitation of input on the ietf mailing list (and, as I suggested in my email, we should probably have included other RTG and TSV working groups - not just those involved in SUB-IP related work), is like the last call. I've aleady posted my personal opinion on where I think we should go with sub-ip. To clarify, in terms of the three options given, it's option 3 (status quo). I am of the opinion that if the target for 3 WGs (ipo, tewg, gsmp) is to close soon, then keeping the area (with the same ADs) open temporarily long enough for the continuity needed to bring stuff to closure is also good management-101. I'm not very bullish on ppvpn closing on schedule. I don't think ccamp and mpls will close that soon. So, I would expect that these two would go into RTG and ppvpn (because of its affinity to pwe3) would go into TSV, but perhaps it may end up in RTG. -Vach -Original Message- From: Fred Baker [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 12:31 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: a personal opinion on what to do about the sub-ip area At 11:15 AM 12/9/2002 -0800, Vach Kompella wrote: Let's also let the VRRP WG decide on the fate of SIP WG documents, the CALSCH WG decide on the fate of OSPF WG docs... Let's particularly ignore the fact that the folks closest to the issues have the most interest in getting the best possible outcome. AFAIK, we're not discussing document status; we're discussing working groups and the area that contains them. The documents will be published. And by the way, what do you think a last call is? We *do* in fact ask folks to comment on drafts being published outside their immediate area of concern. As presented, we are discussing six working groups (ccamp, gsmp, ipo, mpls, ppvpn, and tewg), down from an original nine if memory serves, and of which four are likely to complete their work and dissolve during the coming year anyway. So we're really talking about two working groups: ccamp and mpls. The comparison is to Transport (27 working groups, up from a year ago) or Security (17 working groups), and User Services (now closed, with both of its working groups). If there were new working groups spawning here, one might be able to argue that there is work justifying asking one or two people to dedicate their time as area directors to managing the working groups. It seems to me that moving the two continuing-to-be-active working groups to an active home when the others close is just good-management-101. If we're going to keep the area open, there needs to be a solid justification for doing so, and it's not there.
RE: a personal opinion on what to do about the sub-ip area
And is that because members of the larger community were not allowed to participate in those WGs whose decisions adversely impacted their interests? Because, by your assertion, if they had participated, they would have been part of making the WG decision, which would therefore not have been in the interest of that remaining larger community :-) -Vach -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 11:55 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: a personal opinion on what to do about the sub-ip area Let's particularly ignore the fact that the folks closest to the issues have the most interest in getting the best possible outcome. increasingly often I find WGs whose definition of the best possible outcome is inconsistent with, and in some cases almost diametrically opposed to, the interests of the larger community. Keith
