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

[Jonathan Lang <jplang@calient.net>]

Ben,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com]
> Sent: Wednesday, December 12, 2001 9:12 AM
> To: Zhi-Wei Lin
> Cc: John Drake; Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> 
> 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.
I take issue with the above sentences as follows:
sentence 1 - "comprehensive" should be replaced with "complex"
sentence 2 - there was not much support for the specific proposal.  There
has always been support for working on protection & restoration.

> 
> There are several attributes that could be signaled in setting up
> a protection mechanism, including
There are hundreds of attributes that *could* be signaled for setting up a
protection mechanism.  However, it's not clear that all of them are actually
needed.

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