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

[John Drake <jdrake@calient.net>]

Maarten,

That's fine, however it's beside the point.  The semantics of
Primary/Secondary refer to the control plane and whether the node
establishing a given LSP is planning to use it at the time it's established
or at a later time.  As I indicated in an earlier note, 1+1 transport plane
protection would be accomplished in the control plane by establishing two
LSPs of type Primary.  The control plane really doesn't care which LSP the
transport plane is using as Working and which as Protect, although that
information is available to the control plane at the LSP endpoints.

Thanks,

John  

-----Original Message-----
From: Maarten Vissers [mailto:mvissers@lucent.com]
Sent: Thursday, December 13, 2001 12:15 AM
To: ccamp@ops.ietf.org
Subject: Re: Moving right along ... generalized-signaling-06


There exist well defined protection terminology in ITU-T for the transport
plane. "Working" and "Protection" are being used and not primary/secondary.
E.g.
a 1+1 architecture has one working connection, one protection connection and
a
permanent bridge.

Besides working/protection indication for the transport entity, there is 
- "active" and "standby" to indicate if the signal is selected from the
working
or protection transport entity; i.e. if selector selects from working, the
working is active and protection is standby, if the selector selects from
protection the working is standby and the protection is active.
- "normal" and "extra traffic" signal. The normal signal is protected.

Regards,

Maarten




neil.2.harrison@bt.com wrote:
> 
> Jonathan....review the text below....I think the problem is 1:1.
> 
> neil
> 
> > -----Original Message-----
> > From: Jonathan Lang [mailto:jplang@calient.net]
> > Sent: 12 December 2001 17:46
> > To: 'Ben Mack-Crane'; John Drake
> > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org
> > Subject: RE: Moving right along ... generalized-signaling-06
> >
> >
> > 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.
> >