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

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

John,

You describe a bit that indicates whether or not the path
should be connected.  Perhaps we could call such a bit the "reserve/connect"
bit.  Calling it Secondary is not in line with the normal use of that
term, and is thus misleading.

It is useful to have a bit which identifies whether the path
is the working or recovery path (thus the name "Secondary")
so I think we should keep that meaning for this bit.

Regards,
Ben


John Drake wrote:
> 
> Steven,
> 
> The basic idea is that if a connection is of type 'secondary', then other
> LSPs of type 'primary' between the same or different source/destination
> pairs MAY use its resources in intermediate nodes, until that LSP is
> converted into a 'primary' with a subsequent Path/Resv flow.  At this point,
> other LSPs that were using its resources may get pre-empted.  Think of the
> primary/secondary mechanism as a way to ensure temporal priority while
> allowing network resources to be re-used; i.e., an LSP of type 'secondary'
> is carrying no data.
> 
> So in the 1:1 case the protect LSP could be established either as a primary
> or secondary LSP, while in the 1:N case the protect LSP would be established
> as a secondary.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> Sent: Thursday, December 13, 2001 12:15 PM
> To: John Drake
> Cc: Maarten Vissers; ccamp@ops.ietf.org
> Subject: Re: Moving right along ... generalized-signaling-06
> 
> John,
> It would seem from this standpoint, ANY transport plane protection
> must use "primary" for all trails. You have already made this argument
> for the 1+1 case to carry the permanently bridged copy of the payload.
> 
> In 1:1 or 1:n, when protection is not being used to carry one/any of
> the normal traffic signals, it may either carry a null signal (no bridge)
> or transport plane extra traffic. Even if the transport plane has only
> a null signal on protection, the control plane cannot itself place extra
> traffic on any portion of the end-to-end protection channel as this is
> where the APS protocol is carried to coordinate the 1:1 or 1:n protection.
> The protection channel overhead is chosen to carry the APS since it is
> necessary to exchange APS bytes to complete a switch when working channels
> are failed. If the protection channel has failed and APS cannot be
> exchanged,
> normal traffic signals will not be selected from protection.
> Regards,
> Steve
> 
> John Drake wrote:
> >
> > Maarten,
> >
> > That's fine, however it's beside the point.  The semantics of
> > Primary/Secondary refer to the control plane and whether the node
> > establishing a given LSP is planning to use it at the time it's
> established
> > or at a later time.  As I indicated in an earlier note, 1+1 transport
> plane
> > protection would be accomplished in the control plane by establishing two
> > LSPs of type Primary.  The control plane really doesn't care which LSP the
> > transport plane is using as Working and which as Protect, although that
> > information is available to the control plane at the LSP endpoints.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Maarten Vissers [mailto:mvissers@lucent.com]
> > Sent: Thursday, December 13, 2001 12:15 AM
> > To: ccamp@ops.ietf.org
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> > 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.
> > > >