Re: Moving right along ... generalized-signaling-06

[Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>]

See comment below.

Regards,
Ben 

John Drake wrote:
> 
> Snipped
> 
> -----Original Message-----
> From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com]
> Sent: Tuesday, December 11, 2001 6:38 AM
> To: Lou Berger
> Cc: Kireeti Kompella; ccamp@ops.ietf.org
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> >
> > >
> > >7) In Protection Information it states "The resources allocated for a
> > >    secondary LSP MAY be used by other LSPs until the primary LSP fails
> > >    over to the secondary LSP."  This may not always be the case.  An
> > >    explicit flag indicating whether or not extra traffic may use the
> > >    secondary path resources is needed.
> >
> > ??? This is the purpose of this bit.
> 
> This is not clear from the definition.  The bit is defined as indicating
> the LSP is a secondary (or protecting) LSP and in 1+1 protection the
> secondary LSP may not be used for extra traffic.
> 
> Perhaps the problem here is that protection features are being defined
> before the protection framework and requirements are done.  Is this
> presupposing some particular outcome of the recovery work in CAMP?
> 
> JD:  I think the definition of the bit is fine.  For both 1+1 and 1:1
> protection, there would be a pair of Primary LSPs between the source
> and destination, rather than a Primary and a Secondary.

This is an unusual use of terms.  I have never encountered a case
where both the working and recovery paths are call "primary."

This is not consistent with either draft-mpls-recovery-framework
or with draft-lang-ccamp-recovery.  I think this is a sign that the
protection work is immature and not ready for progressing to RFC.