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

[Maarten Vissers <mvissers@lucent.com>]

Ben,

In ITU-T Q.9/15 work is ongoing to develop a generic protection switching
overview document (G.gps). The first draft is available via the Q.9/15 web page:
http://ties.itu.int/u/tsg15/sg15/wp3/q9/ggps/ggps-v01-0110.doc
http://ties.itu.int/u/tsg15/sg15/wp3/q9/ggps/ggps-v01-0110.pdf

This first draft version contains the linear protection switching generic
aspects. To be added is the ring protection generic aspects (MS SPring and new
OCh SPring and ODUk SPring).

Regards,

Maarten

Ben Mack-Crane wrote:
> 
> Zhi,
> 
> A while ago there was a draft proposing a fairly comprehensive
> signaling solution for protection.  At the time, there was not
> as much support for working on protection as there is now.
> 
> There are several attributes that could be signaled in setting up
> a protection mechanism, including
> 
> - whether the path is a working or recovery path
> - what notification mechanism is used to trigger the protection mechanism
> - hold-off time
> - wait-to-restore time, and
> - revertive operation
> 
> This was an early draft, so there may be other attributes needed, or some
> simplification might be possible.  In any case, the working group must
> decide how to progress the protection work.  I don't think it is a good
> idea to take an ill-defined (and perhaps incomplete) solution to RFC.
> 
> Regards,
> Ben
> 
> Zhi-Wei Lin wrote:
> >
> > Hi,
> >
> > To further the discussion, would it be possible to add a new flag for
> > purpose of identifying whether or not a connection (secondary
> > connection) can support extra traffic. A 1:1 connection should be able
> > to support extra traffic (if secondary is not used) while a 1+1 would
> > not support extra traffic.
> >
> > Also, we may want to add a flag for whether or not a protection is
> > revertive.
> >
> > Also, current "link flags" is assumed to provide link protection. Maybe
> > we can add a new flag for either "link" or "path" protection.
> >
> > So the total is three new flags using 3 bits, out of the current 25
> > reserved bits.
> >
> > What do you think?
> > Zhi
> >
> > 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.
> > >
> > >
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