-----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-----