The MPLS WG Archive

[Nabil Seddigh <nseddigh@tropicnetworks.com>]

Lou, 

In theory, GMPLS is supposed to encompass MPLS and packet-based
devices as well. In practise, there appears to be a clear 
demarcation between MPLS & GMPLS. This is further confirmed
by industry usage of GMPLS for application to optical systems.

The best approach would have been to denote the lowest common 
denominator objects as part of MPLS and other extensions as GMPLS. 
This I believe was David's point wrt to Hitless Restart and 
Unnumbered Links which could be used with the packet MPLS 
defined today. Not doing so causes some confusion.

Let me try to illustrate with one example. Using 3rd party stack 
source vendors is becoming more and more commonplace. Such vendors 
would offer GMPLS & MPLS as separate code offerings. In order to 
implement a packet-based MPLS device that supports Hitless Restart
& Unnum Links, they would need to purchase and integrate an
entire GMPLS stack which their device does not otherwise
require.

Best,
Nabil Seddigh


Lou Berger wrote:
> 
> GMPLS applies to packets as well.  It seems that all that is need here is
> an explanation (app note) of how to use gmpls with packets.  This should be
> a short document...
> 
> (it just takes using the new label request and label object...)
> 
> Lou
> 
> At 09:12 PM 11/21/2002, Loa Andersson wrote:
> >All,
> >
> >let me see if I understand this correctly.
> >
> >I think that the general problem is -given the definitions by Kireeti
> >below - that:
> >
> >- something specified in a ccamp spec makes perfect sense
> >   for something in vanilla ;) mpls (using signaling type B)
> >
> >- the ccamp spec specifies more than what is needed (makes sense) for
> >   the vanilla mpls that has to be implemented to comply to the with the
> >   spec
> >
> >Then the issue is, how do we handle this?
> >
> >Is this the background for the question? If so, I can see several
> >ways of doing things
> >
> >- split documents, one mpls and another ccamp one, where the ccamp
> >   include the mpls doc (by reference)
> >- do it by applicability statements, from the mpls side saying "what is
> >   specified in the ccamp if doc is a great idea, but if you apply it to
> >   packet mpls you don need to implement ..."
> >- include info in the ccamp doc on what is needed in packet mpls
> >
> >/Loa
> >
> >Kireeti Kompella wrote:
> >>Hi David,
> >>On Thu, 21 Nov 2002, David Charlap wrote:
> >>
> >>>During the course of development, I have noticed that there are several
> >>>features of generalized-RSVP (draft-ietf-mpls-generalized-rsvp-te-09)
> >>>that are applicable to non-generalized MPLS networks.
> >>
> >>There are those who refer to generalized and non-generalized MPLS
> >>networks, those who talk about GMPLS and classical MPLS, etc.
> >>I would prefer to view this at two levels:
> >>   o (A) generalized signaling and (B) non-generalized/classical signaling
> >>   o (i) non-packet and (ii) packet LSPs (or MPLS networks)
> >>(A) can be used for both (i) and (ii)
> >>(B) can be used for (ii), but does rather poorly for (i)
> >>If an applicability statement is needed to say this, so be it.
> >>Kireeti.
> >
> >
> >--
> >     /Loa
> >
> >
> >     Loa Andersson
> >     Utfors AB
> >     Råsundavägen 12
> >     Box 525, 169 29 Solna
> >     Mobile          +46 70 848 5038
> >     Email           loa.andersson@utfors.se
> >