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

[Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>]

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.
> >
> >