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
