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

[Maarten Vissers <mvissers@lucent.com>]

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.
> >
begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard