The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Nov> msg00183



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

GMPLS features applicable to MPLS

  • From: Emmanuel.Dotaro@alcatel.fr
  • Date: Mon, 25 Nov 2002 17:30:00 +0100
  • CC: David Charlap <David.Charlap@marconi.com>
  • Organization: Alcatel
  • X-MIME-Autoconverted: from quoted-printable to 8bit by cell.onecall.net id gAPGOS315160
  • X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at11/25/2002 17:29:58,Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at11/25/2002 17:29:59
  • X-Virus-Scanned: by amavisd-milter (http://amavis.org/)

Hi all,
I support the idea that by definition GMPLS is a superset of MPLS.
It makes sense to have a document that clarify the applicability of GMPLS for
Packet LSPs (and also for L2LSPs –ATM/FR/Eth…- ?).
We may also consider their future integration.

regards

Emmanuel

Rohit Dube a écrit :

> On Fri, 22 Nov 2002 10:02:28 -0500 David Charlap writes:
> [snip]
> =>Any one of these would be fine for me.  My main concern here is that
> =>MPLS vendors will start implementing those features, and some may ignore
> =>the GMPLS approach, thinking that those drafts are not applicable to
> =>non-generalized MPLS.  This may lead to interop issues.
> =>
> =>Of course, vendors often ignore drafts anyway, but at least this way
> =>they'll know that there is something out there that they can choose to
> =>implement or ignore.  And those that need to pull pieces of GMPLS into
> =>their MPLS implementations will know how much must be pulled in to
> =>properly support the features under development.
>
> Excellent points David. And in fact this is what happened with the
> "bidirectional lsps for classical mpls" draft that I presented at the
> IETF.
>
> A quick solution is needed for this class of problems!
>
> Regards,
> --rohit.