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

[Lou Berger <lberger@movaz.com>]

Zhi, Ben,

         Most (if not all) of the flags in this object have been there from 
day one of the GMPLS draft.  They have been presented, discussed, and 
agreed to in multiple WG sessions.  The WG also decided (maybe in 
summer'00?) to defer other, more detailed/complex protection until we 
completed these drafts.  Time to move on...

Lou

At 12:36 PM 12/12/2001, Zhi-Wei Lin wrote:

>Hi Ben,
>
>Yes I agree. Maybe given the status of protection and complexities that
>it would introduce, can we treat it as a separate "function" of GMPLS
>and pull it out of the current document and into a new document that
>deals exclusively with protection?
>
>It would be a (relatively) simple task:
>
>(1) Remove section 7 of gmpls-sig doc
>(2) Remove section 6 of gmpls-rsvpte doc
>(3) Remove section 6 of gmpls-crldp doc
>
>and put these sections under a new document called gmpls-recovery (or
>gmpls-protection) and then start work on this separately.
>
>Zhi
>
>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>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.
> >>>
> >>>
> >>>