At 3:19 PM +0000 9/9/04, Charles Cthulhu Riley wrote:
>I feel like I am in a Python skit...sans dead parrot.
MPLS isn't dead...it's merely resting. For that matter, it is
incubating the GMPLS  egg.
But, since you bring it up, I will have to admit it is not pining for
the fjords. The Norwegian Blue (beautiful plumage, innit?) may not be
the right skit. Perhaps relevant to traffic engineering are
questions about the laden and unladen velocities of various swallow
 implementations. "What is your quest" seems to deal well with
 Seriously, Generalized MPLS, which other vendors seem to emphasize more
than Cisco, is a very useful idea, and understanding it may even help in
basic MPLS understanding. Remember that basic MPLS is fundamentally a
packet forwarding technology.
GMPLS extends the path setup aspect, often the least often explained
part of MPLS, to non-packet forwarding. Specifically, it has methods
for setting up optical wavelength/lambda paths, for TDM paths, and for
paths associated with ports on cross-connects. The advantage in looking
at GMPLS is that you are forced to get away from what I consider a
Cisco documentation/courseware overemphasis on packet forwarding and
deal with the really fundamental aspects of path creation and traffic
One of the things often forgotten about path creation is that RSVP-TE
builds on a topology established by IP routing. There is a hopefully
declining erroneous assumption that MPLS somehow replaces IP routing
protocols. Actually, it depends on them but also complements them.
 Any resemblance to George Swallow, one of Cisco's ATM/MPLS gurus, is
>This seems like a good time to confess...I'd rather shove a hot poker in my
>ear than read IETF drafts. I mean, don't get me wrong, I'll read the cool
>ones, like 1918, and that one about the Ethernet thing, but for the most
>part, they read like they were written by repressed accountants suffering
There is a trick to reading protocol RFCs. First, if there is an
applicability document as well as a protocol specification, read the
applicability document first. It will be much more tutorial, and, in
some cases, all you need.
Second, when reading a standards track RFC, typically the first few
sections are somewhat tutorial, stating the problem. The document
then jumps into protocol mechanisms, which can be hard to follow
unless you are a protocol programmer. If you are a protocol problem,
they still can be hard to follow (especially in cases like the
obsolete BGP RFC 1771, which contains outright errors).
It is worth skipping to any appendices. These are sometimes obscure
parts of the standards mechanisms, but they also may very well have
application examples, or practical recommendations about things that
are not formally standardized.
>Not that I am not grateful for the replies, but I was really hoping to get
>some feedback on materials that others have used to prepare for the
>exam...even it if is an IETF RFC.
>I am sure MPLS is hotter than Upton Sinclair at a butcher shop,
:-) Great image -- wonder how many people will get it? Far fewer, I
am afraid, than Howard Stern.
>wouldn't know that from the lack of credible and interesting info about it.
>HCB is right...it is an immature technology...it would be the technology
>that calls into Larry King to scream "Howard Stern rules.".
I'd rephrase that a little. There are very useful service provider
pieces of MPLS. I have yet to see a really good reason for
enterprises to use MPLS, unless they are large and essentially act as
a service provider to their divisions. In my experience, at least
telco providers prefer to give L2 user interfaces like frame or
private line to their customers, because their craft technicians
generally do not understand L3 or sub-IP.
> wrote in message
>> Quoting Chuck Whose Road is Ever Shorter :
>> > ""Charles Cthulhu Riley"" wrote in message
>> > news:200409070113.i871DOV5022981@xxxxxxxxxxxxxxxxx
>> > > Hi, all,
>> > >
>> > > I am chasing my CCIP on my way to CCIE...the path is similar to that
>> > > drunk fly.
>> > Me too, but not on the way to CCIE. I've decided just to collect as
>> > initials as I can.
>> A, B, C, D, E...repeat as necessary.
>> > >
>> > > I got the Cisco Press book by those two guys with the long names, but
>> > > book is quite sketchy...in fact, I know now personally, it's not
>> > > pass. Neither are the Boson practice tests.
>> > Dare I mention the cheat sites? :-O
>> Dare I mention the RFCs and Internet-Drafts? I have a pretty decent
>> of MPLS, but I can't say that I've learned much of it from other than the
>> direct sources.
>> There also are various industry forums such as www.mplsforum.com, which
>> merger of new MPLS work as well as the former ATM and Frame Relay forums.
>> > >
>> > > Are there are whitepapers, or other books with good coverage of MPLS?
>> > > Links
>> > > to what works on Cisco would be helpful...not sure what's good and
>> > > outdated...this is just for exam preparation purposes only. A more
>> > > practical application will come later when I start exploring whether
>> > > would serve my organization.
>> There is a subtle problem here. MPLS, and Cisco MPLS, are evolving fairly
>> quickly, and it is probably safe to say that Cisco is being responsive to
>> it sees as customer (primarily carrier) expressed needs and where it sees
>> driving the market. As is typical in the carrier space, things may be
>> out in limited-distribution releases, and possibly supported only on the
>> high-end carrier-grade routers and switches.
>> Is Cisco education and certification keeping pace in a controlled way, or
>> they playing catch-up as there are bursts of new products? I don't truly
>> But given that these organizations are lagging, how likely it is that
>> be study materials? I'm afraid that there may be no way of getting
>> least a thorough study of the IETF architecture/framework documents. The
>> recovery framework, incidentally, is full of outstanding ideas, and
>> if complex definitions, of high availability in general.
>> > Perhaps going through the books in conjunction with labs? I am told
>> > MPLS, like BGP, is scarier when you have never touched it. Do you have
>> > access to the Cisco Partner Connection practice labs?
>> Or is there a point where a sexy new technology is simply not ready for
>> general certification market, which expects practice materials?
>> > As far as whether MPLS will serve your organization, all the telcos are
>> > building new IP backbones and pushing MPLS to their customers. So MPLS
>> > soon serve your org whether you want it to or not ;->
>> The question, in part, is whether being served by MPLS means a direct
>> interface, or that the carriers will talk about it but the enterprise
>> still see primarily L3VPN or L2VPN? The latter, incidentally, is the
>> many vendors other than Cisco. I don't think Cisco has articulated well
>> view of whether enterprises will use MPLS directly to a large extent.
>> Think of the more complex features of BGP, and ask what kind of
>> really likely to need them. When I wrote my book _Building Service
>> Networks_, I wrote a couple of chapters' worth of IP/BGP/MPLS
>> this was intended more as guidance for carriers than as certification
>> materials. Would I have liked to have written something, a couple of
>> to serve the larger certification market? From my personal economic
>> naturally! But at the time, there wasn't even a SP oriented
>> program of any depth. Ironically, even CCIE/SP doesn't explore complex
>> other than from a weird command standpoint -- versus understanding. MPLS
>> newer and less mature.
Message Posted at:
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html