[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: GMPLS Last Calls



Yakov Rekhter wrote 04 June 2001 15:48
<snipped>
> >
> > 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.

NH=> MPLS has the potential to become very important and have a key role on
QoS issues (and it should not be confused with GMPLS see 'note' at
end).....but to get there we need to recognise these points:
-	LDP is to me an IP routing adjunct.....its main role as I see it is
to provde address partitioning (or a 'hierachy of routing' as I think you
described it in your book Yakov....which, if anyone has not read it, I can
strongly recommend);
-	LDP induced LSPs do not really create a layer network.....since they
allow merging, and this in itself causes some hard QoS problems....like how
does one define availability in a mpt-pt tree?  [Its the old issue of 'no
free lunch'...if you push down a problem in 1 dimension (eg scalability), it
creates a problem somewhere else (eg measuing availability in VPNs say)];
-	Explicitly routed LSPs on the other hand do form true layer
networks....since they need to be signalled they exist as true trail objects
in their own right.
And it was these apsects that our OAM paper tried to address for
MPLS....that is, to attack the QoS problem (wrt operational processes and
measurements) one needs to first define the defects (and MPLS does have the
potential to introduce new ones) and the consequent actions...and from this
we can define availability of the LSPs which in turn is a pre-requisite to
measuring QoS (since QoS is only relevant to the up-state of the LSP).

However.....we have had a 'hard time' from a few on this (maybe there is a
silent majority that support this work?)....and this relates to Eric Gray's
prior mail on why people don't speak up.....besides the fear of ridicule or
abuse, one can only try so many tmes before giving up and going elsewhere.
So maybe there is a deep-seated culture problem that needs addressing?

Note - MPLS introduces a new user-plane technology....the shim header.  By
definition, and as noted above, operators need to manage this in an
OAM/performance sense.  MPLS has the ability to be extended to end
systems....I know this is not currently on the agenda of many, but it has
that *potential* (ie so that applications could choose a priori the transfer
mode, co or cnls).  The arguments for a single control-plane across MPLS and
IP (or to be more precise the 'addressing facet' of the control-plane) is
important if ever MPLS was extended to end systems.....this was the real
problem with ATM and IP unification, ie disjoint addressing.
GMPLS on the other hand does not introduce a new user-plane.  It is about
re-using control-plane facets for different layer networks.  In principle
this is a laudable aim, but its actual embodiment has many technical and
commercial implications that are too deep to go into here and we (ie I and
colleagues in BT) are addressing these elsewhere.
So all I wanted to say here is that one should not compare MPLS and GMPLS
like they are same thing.
>
<snipped to end>