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