In message <5.0.2.1.2.20010108230839.00a77ec0@flipper.cisco.com>, Fred Baker wr
ites:
> 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?
If its any consolation I'm with you on almost all points. I did not
call MPLS an interdomain routing technology I just said it solved some
problems and was deployable. I also think that MPLS will be useful in
the long term in providing QoS capability but that is a sidebar to
this discussion so not worth pursuing here and now. I'm aware of the
former-ITU crowd's influence and the nonsense in IPO. CEOT is more
benign IMHO, an architecturally ugly way to provide legacy services
over a backbone that is doing MPLS, which would be only slightly less
ugly if it were over IP with the option to put the IP over MPLS.
> 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.
If this is the case, an occasional note to the MPLS WG describing the
status of the documents (or any WG which had a document held up) would
greatly improve the image of the IESG.
> I don't do well with whining...
I didn't think I was whining in pointing out that a lot of negative
comments have come from the IESG and at the last IETF from you. If
your comments were justified, you do not need to throw around insults
when defending them. If you successfully defend your comments, then
you are better respected for it. You did a pretty good job in listing
your objections to "MPLS hype" which is much better than I can say for
those who have so far tried to defend the decision to stop MPLS ICMP
extensions (but thats off topic and perhaps I'm whining again).
Regards,
Curtis
ps - no offense taken and none intended.
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT