At 09:54 AM 1/4/01 -0500, Curtis Villamizar wrote:
>Despite the negative comments recently about MPLS from Fred and IESG
>members, MPLS/TE solves real problems and is seen as easily
>deployable, particularly relative to such things as Nimrod.
I'm sorry you see me as anti-mpls and anti traffic engineering. I'm not.
What I am anti, if anything, is discarding IP routing in favor of MPLS.
Yes, you see MPLS LSPs as extending IP routing, and bully for you. If you
attended the CEOT BOF or the IPO BOF, you got a flavor of what I'm dealing
with on other fronts. If a service provider wants to use MPLS to accomplish
goals like traffic engineering or VPNs, I'm all for that.
But on the one hand I have a short list of folks who have deployed MPLS,
and a long list of folks who don't want to - they want the same goals met
in IP routing. On the telco and research side, I also have a long list of
folks who are saying "well, if I can't make the world be ATM in the ITU,
I'll call it MPLS and make the world be ATM in the IETF."
The IETF may someday decide to go there, but I'm sufficiently narrow-minded
that it won't do so on my watch. Of course, my watch ends in a couple of
months :^)
Further, I also worry about people deciding that "MPLS is the answer, now
what was your question?" To pick on one pet peeve, some bunch of jerks,
probably from my company, are promulgating the belief that MPLS has
something to do with QoS. You and I know it doesn't. Traffic engineering is
a way to reduce the total cost of a network by maximizing the use of the
individual links. What it ensures, if anything, is a slightly longer path
for the average route (instead of taking the overloaded direct link from
here to there, use the underutilized paths from here to over-thar, and then
from over-thar to there). Neither increasing the mean traffic rate on a
link nor increasing the total number of interfaces that a message must
cross is a recipe for making delay more constant or reducing it. MPLS can
certainly be used *with* bandwidth allocation to engineer peak rates (and
therefore queue depths) so that delay is minimized and stabilized, and it
can certainly be used *with* other QoS technologies to accomplish QoS
goals. But it is not in and of itself a QoS solution: it is the antithesis.
For example, there is rather a largeish set of people who like IPSEC
tunnels running over IP networks for certain classes of solutions. Is there
a reason they should be forced into doing something with MPLS? Can the IETF
be open-minded enough to keep that model in view rather than focusing all
of its energies on MPLS?
What I said rather a bunch of times at the IETF was that I was interested
in the Internet Engineering Task Force being used as a venue to engineer
solutions for the Internet. I said that I was willing to look at sub-ip
technologies (mpls traffic engineering being an example) to the extent that
they are useful for IP; I was not interested in going the extra twelve
steps to taking on the general interworking problem that the ITU loves
(make it be native voice on IP here, native ATM voice there, and native
circuit switch voice somewhere else), or to try to put the ITU out of
business. If we can make IP work on optics, perhaps using adapted MPLS
technologies, fine. If voice-on-optics can use exactly the same technology
to accomplish its goals, fine by me. But voice-on-optics is a non-goal; if
it won't work, use voice-on-IP on Optics, or go somewhere else and engineer
an appropriate solution. I was pretty frustrated to hear people instantly
say "so I don't understand you, you're being ambiguous". I view that as
intentional non-understanding - there is none so difficult to explain
something to as someone who has decided that he doesn't like what you're
saying is has therefore stopped listening.
MPLS, by the way, is not a routing technology, nor is it normally
interdomain. What on God's green earth does your view of MPLS and traffic
engineering have to do with getting a better interdomain routing technology
out there?
Also, by the way, I know that the MPLS working group has been whining about
the RFC Editor holding up its documents waiting for normative references,
and has been blaming the delay on anti-MPLS bias in the IESG. If you check
with George Swallow, you'll find that I have been banging around his ears
trying to get the normative references cleared up. The instant they were,
the documents were published.
I don't do well with whining...
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT