The MPLS WG Archive

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



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

GMPLS features applicable to MPLS

  • From: jeff pickering <jeffp@caspiannetworks.com>
  • Date: Thu, 21 Nov 2002 14:57:39 -0800
  • CC: David Charlap <David.Charlap@marconi.com>, IETF MPLS List <mpls@UU.NET>

Also note that there is a history of this since the hellos in rfc3209 are
not specific to rsvp-te either.
Jeff

Nabil Seddigh wrote:

> David,
>
> This is an excellent point that must surely be a source of concern
> to many! It is certainly an issue that has been raised before on
> this mailing list.
>
> For various reasons, the authors did not wish to undertake
> the effort required to change the current drafts.
>
> Unnumbered links & graceful restart are not specific to gmpls
> and I never understood the rational for rolling them into
> the gmpls drafts. IMHO, it is better to remove the content in
> 2 separate drafts.
>
> However, if this is too much work for the authors at this
> point then approach of an "MPLS-applicable" section in the
> GMPLS drafts may be a suitable compromise.
>
> Best,
> Nabil Seddigh
> nseddigh@tropicnetworks.com
>
> 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.
> >
> > Two immediately come to mind:
> >
> > 1: Support unnumbered links in explicit routes (as defined by
> > draft-ietf-mpls-rsvp-unnum-08) which requires as a prerequisite, support
> > for the IF_ID versions of the HOP and ERROR_SPEC objects (section 8)
> >
> > 2: Fault handling and restart capabilities (section 9)
> >
> > Right now, in order to provide thse features in an MPLS switch, one must
> > either use a proprietary solution, or must attempt a partial
> > implementation of GMPLS for the MPLS environment.
> >
> > What should be done about this?  I don't think it's appropriate to
> > simply tell people "use GMPLS or do without the features".
> >
> > Perhaps a section on applicability to MPLS networks can be added to the
> > relevant GMPLS drafts?  Or perhaps those sections of GMPLS that are also
> > applicable to MPLS should be broken off into separate drafts?
> >
> > Opinions?
> >
> > -- David