Re: GMPLS Last Calls

[Yakov Rekhter <yakov@juniper.net>]

Anonymous,

> I agree with you whole heartedly.  We must have the inputs from the carriers
> and not from the vendors alone.  Some vendors are pushing MPLS, GMPLS now,
> like this are the best ideas since sliced bread.  But others (Global
> Crossing's Plonka, and Ananth, etc.) have pointed out in different forums the
> problems with MPLS.
>
> Issues that we have found relate to -
>
> 1.  MPLS is not for QoS (See first paragraph of Chapter 6 of Yakov Rekhter's
> book: MPLS - TECHNOLOGY AND APPLICATIONS, MK Publisher), Yakov says, " To
> many people, QoS is the driving factor behind MPLS.  This is actually
> something of a misconception......QoS is not a very strong reason to deploy
> MPLS..."

The above seems like quoting out of context. To put it in the proper
context here is the full sentence:

   Compared to other factors, such as traffic engineering and Virtual
   Private Network support, QoS is not a very strong reason to deploy
   MPLS.

So, what you seem to be missing is that it is *relative* to other
applications, such as TE and VPN, that "QoS is not a very strong reason
to deploy MPLS".

And while on the subject of QoS and MPLS, further in the first section 
of Chapter 6 (page 148):

  ..there are some novel QoS capabilities that can be supported across
  a provider network using MPLS that, while not being truly end-to-end,
  nevertheless may prove very useful. One of these, guaranteed bandwidth
  LSPs, is discussed in Section 7.5.2.
  
> 2.  To do VPN with MPLS with extensions is a bad idea also since BGP is a
> routing protocol that changes state quite often and to use it for VPN with
> MPLS tags is not really a very smart solution as a recent comm related
> magazine article points out (I don't have it here but I can provide it if 
> you are interested),

At best whether "to do VPN with MPLS with extensions" is "a bad idea"
is a matter of opinion. However, since at the beginning of you message
you suggested to get inputs from the carriers, you may look at the
list of authors of draft-rosen-rfc2547bis-03.txt, as this list may
give you a hint of what carriers think about this technology.
 
> 2.  If not for QoS, then is it for TE?  As others have said on this MPLS
> thread, you can easily do TE with a host of network management tools
> available out there - if not real-time, for sure, near-real-time.

First of all, there is a difference between "said" and "done". So,
while other "have said.. you can easily do TE with a host of network
management tools", one could ask whether they actually done this.
And if yes, then the next question would be to compare results with
TE based on MPLS Constraint-based routing.
 
> 3.  Other issues pertaining to MPLS are - scalability: explicit path, RSVP,
> CSFP, all found not scalable from the dawn of these technologies (see Nortel
> site slides on MPLS for one confirmation), and finally

Since you quoted from "MPLS: Technology and Application" before,
I'd like to suggest to look at Section 7.6.2 of this book for the
discussion of alledged scalability problem with RSVP, when used in
conjunction with MPLS Constraint-based routing. 

Yakov.