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

[Stephen Trowbridge <[e-mail]>]

Zhi,
We have been trying to work some consistency into this terminology over time.

Working and Protection are terms that we are trying to use only between the
ends of the protected domain.
Normal traffic is the traffic that is carried over Working (sections, trails,
whatever) in the absence of a failure or other switch cause.
Extra traffic may be carried over Protection (sections, trails, ...) when
they are not needed to carry Normal traffic.
Active and Standby have normally been used with respect to 1+1 arrangements,
although could make sense to use these terms in 1:n without extra traffic
as well. An active (trail, section,...) is the one from which a normal traffic
signal is currently selected, where a standby (trail, section) is one from
which normal traffic is not currently selected. I am not entirely happy
with use of the word "standby" to describe something that is currently
carrying extra traffic.
Regards,
Steve

Zhi-Wei Lin wrote:
> 
> Hi,
> 
> I think active/standby and extra-traffic/normal-traffic are also two
> separate descriptors. Extra traffic may be carried on a standby
> connection (but a standby connection does not necessarily have extra
> traffic on it).
> 
> How do we define normal traffic? Is this user traffic carried by working
> path (when working is active), or also carried by recovery path (when
> recovery is active)?
> 
> And once you defined these, I think you still may need to specify
> whether a connection is revertive or non-revertive.
> 
> For example, take the case of 1+1. One operator may decide to use
> non-revertive (because both paths are "equivalent") so avoid a switching
> hit on the traffic (order of milliseconds?), while another operator may
> decide to use revertive (because the recovery path is much longer/more
> hops). Could these decisions be made per protected LSP basis? If yes,
> then would tail-end need to know which mode it is operating/to use (the
> intermediate nodes don't need to know this)?
> 
> Zhi
> 
> Ben Mack-Crane wrote:
> 
> > Maarten,
> >
> > In the work on a recovery framework for mpls (draft-ietf-mpls-recovery-frmwrk-03.txt)
> > we chose "working path" and "recovery path."  We used "recovery" instead of "protection"
> > because it seemed a more neutral term given that we were including both protection
> > switching and reroute recovery mechanisms.
> >
> > We did not address the state (active/standby).  We use the terms "extra traffic" and
> > "working traffic" (perhaps the latter could be changed to "normal traffic").
> >
> > It would be useful in moving forward in CCAMP if we could try to adopt terms
> > that are consistent with those in current use elsewhere.
> >
> > Regards,
> > Ben
> >
> > Maarten Vissers wrote:
> >
> >>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
> >>
> >>[e-mail] wrote:
> >>
> >>>Jonathan....review the text below....I think the problem is 1:1.
> >>>
> >>>neil
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Jonathan Lang [mailto:[e-mail]]
> >>>>Sent: 12 December 2001 17:46
> >>>>To: 'Ben Mack-Crane'; John Drake
> >>>>Cc: Lou Berger; Kireeti Kompella; [e-mail]
> >>>>Subject: RE: Moving right along ... generalized-signaling-06
> >>>>
> >>>>
> >>>>Ben,
> >>>>  Please see inline.
> >>>>
> >>>>Thanks,
> >>>>Jonathan
> >>>>
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: Ben Mack-Crane [mailto:[e-mail]]
> >>>>>Sent: Wednesday, December 12, 2001 8:56 AM
> >>>>>To: John Drake
> >>>>>Cc: Lou Berger; Kireeti Kompella; [e-mail]
> >>>>>Subject: Re: Moving right along ... generalized-signaling-06
> >>>>>
> >>>>>
> >>>>>See comment below.
> >>>>>
> >>>>>Regards,
> >>>>>Ben
> >>>>>
> >>>>>John Drake wrote:
> >>>>>
> >>>>>>Snipped
> >>>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: Ben Mack-Crane [mailto:[e-mail]]
> >>>>>>Sent: Tuesday, December 11, 2001 6:38 AM
> >>>>>>To: Lou Berger
> >>>>>>Cc: Kireeti Kompella; [e-mail]
> >>>>>>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.
> >>>>
> >>>>
> >