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

[John Drake <jdrake@calient.net>]

-----Original Message-----
From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com]
Sent: Wednesday, December 12, 2001 10:10 AM
To: Jonathan Lang
Cc: John Drake; Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org
Subject: Re: Moving right along ... generalized-signaling-06


Jonathan,

I agree that both the working and recovery paths must be connected
and carrying traffic (except at the egress).  It is a problem that 
the term "primary" is being overloaded to indicate both "working"
and "connected in transit nodes".

JD:  The fact that you don't understand the semantics of the
Primary/Secondary
bit doesn't necessarily mean that they're incorrect

If it is an endpoint decision as to which is the working and which
is the recovery path, this seems to add more complexity to the
operator's job in setting up protected paths.

JD:  Assertion

It would seem quite
reasonable to signal which path is which.

JD:  And why would the intermediate nodes care?

Regards,
Ben

Jonathan Lang wrote:
> 
> 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.