The MPLS WG Archive

["Sandeep B" <san_101@hotmail.com>]

There are few other things - e.g. L3PID. GMPLS explicitly defines that for 
Lsps that carry a certain type of traffic it needs to signal that using GPID 
e.g IP lsp should set certain GPID and L2VPN-MPLS lsps a certain other GPID. 
But there is no such defination in classic RSVP-TE. Such a case what should 
be the criteria. Do we follow GMPLS RSVP-TE or classic??

Particular to this question - Do we have finally decided what should L2VPN 
lsps signal as their L3PID????

http://cell.onecall.net/mhonarc/mpls/2002-Apr/msg00163.html



GMPLS def ==>>

   The G-PID parameter is normally only examined at the egress.  If the
   indicated G-PID cannot be supported then the egress MUST generate a
   PathErr message, with a "Routing problem/Unsupported L3PID"
   indication.  In the case of PSC and when penultimate hop popping
   (PHP) is requested, the penultimate hop also examines the (stored) G-
   PID during the processing of the Resv message.  In this case if the
   G-PID is not supported, then the penultimate hop MUST generate a
   ResvErr message with a "Routing problem/Unacceptable label value"
   indication.  The generated ResvErr message MAY include an Acceptable
   Label Set, see Section 4.1.


>
>Ping,
>
>You make a good point. This discussion is about document organization.
>Nothing earth shattering. This would not be important except that
>in some ways the world has changed.
>
>No longer do we have only a handful of implementations
>of a particular protocol - all being done by folks who work
>in 2 or 3 companies. Protocols are being implemented by
>an increasing number of companies with development in many parts
>of the world other than North America.
>
>Having well organized content simply makes lives easier for
>future developers. In this particular case, it also has clear
>implications on $ and code creep - see my previous email.
>
>Ideally, the Hitless Restart content & Unnumbered Links content
>should have remained separate content applicable to MPLS.
>Otherwise the next best compromise is an applicability
>statement draft.
>
>Best,
>Nabil
>
>Ping Pan wrote:
> >
> > Hmmm... have to bite now. Who is confused here? The carriers? Don't
> > think so. They know exactly which feature to have in their networks. The
> > developers? Don't think so either. They know what can and cannot be
> > implemented. So if we have enough solutions floating around in various
> > drafts and RFC's. Why write more document?
> >
> > - Ping


_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus