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

[Jonathan Lang <jplang@calient.net>]

Ben,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com]
> Sent: Wednesday, December 12, 2001 8:56 AM
> To: John Drake
> Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> 
> 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.
> 
For 1+1 path protection, both working/recovery paths are carrying user data
traffic and it is an endpoint decision as to which path is actually the
working/recovery path.  At a transit node, both paths need to be treated as
primary, as the resources are currently being used and obviously can't be
used for Extra Traffic.