Re: protection and restoration [was: Re: Moving right along ... generalized-signaling-06]

[Maarten Vissers <mvissers@lucent.com>]

Eric,

You keep amazing me... I ask a simple technical question concerning a
requirement for fast restoration, which I would have expected a Yes/No answer
for. I then asked as second technical question concerning the the interpretation
of fast protection, which also could have been answered by Yes/No. Then assuming
a Yes on the second answer I ask a third technical question on the scope of fast
restoration, which could also be answered by Yes or No. Instead of 3 simple
Yes/No answers I received an email with several accusations :-( ... I still hope
I will receive answers on my simple questions. Would be appreciated.

Regards,

Maarten

"Mannie, Eric" wrote:
> 
> Maarten,
> 
> This is too big this time, usually you are more subtle :-)
> 
> Last attempt to convince everybody that GMPLS is for pre-OTN only and G.ASON
> for OTN ?
> 
> So that GMPLS becomes a secondary and temporary control plane until we have
> a G.ASON based ITU-T control plane that will be used for everything (and
> that we will have in several years) :-)))
> 
> I liked your speech during the IESG plenary when you said that the "GMPLS
> work just started in CCAMP" and when you presented G.ASON as almost
> finished. From an honest perspective, it is exactly the opposite.
> 
> Since one cannot stop GMPLS, let's try to reduce the scope :-)))
> 
> You complained so many times that nobody is actively proposing GMPLS at the
> ITU-T. If you could have spent the same energy that you are spending here
> against GMPLS, rather proposing GMPLS at the ITU-T... The entire community
> could have saved a lot of time and energy (or at least people on this
> mailing list :-)))
> 
> Rgds,
> 
> Eric
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:mvissers@lucent.com]
> Sent: Wednesday, December 19, 2001 2:25 PM
> To: Mannie, Eric
> Cc: ccamp@ops.ietf.org
> Subject: protection and restoration [was: Re: Moving right along ...
> generalized-signaling-06]
> 
> Eric,
> 
> One of the requirements we have to meet is that traffic of user A is not
> delivered to user B. Also during recovery from a failed connection (either
> by
> means of protection swithcing, or restoration) we have to guarantee that
> user A
> traffic is not delivered to user B. This adds additional requirements to the
> operation of the 1:1/ET (with extra traffic), 1:n, 1:n/ET, etc
> architectures;
> these have a potential to temporarily connect A to B.
> 
> In protection switching this is guaranteed by means of the combination of
> protection architecture and protection switching protocol type (1-phase,
> 2-phase, 3-phase protocols).
> The tail end normal output #i of the protected domain will never select from
> the
> protection connection until it is guaranteed that normal input #i at the
> head
> end is bridged onto this protection connection. And vice versa, the tail end
> will deselect the protection connection before the head end will put a
> different
> signal onto that protection connection.
> 
> I assume that for the case of restoration and fast restoration, the same
> requirement is applicable. Has this requirement been considered in the work
> on
> fast restoration?
> 
> It looks like "fast restoration" is a control plane based protection
> switching.
> Is my understanding correct?
> 
> If so, with transport plane based protection switching build into SDH/SONET
> and
> OTN, is fast restoration being a pre-OTN feature? I assume there is no need
> to
> replace SDH/SONET/OTN transport plane based protection switching by control
> plane based protection switching.
> As pre-OTN (STM/OC-N or GE over WDM) doesn't have any protection switching
> defined in the transport plane, pre-OTN has no alternative to control plane
> based protection.
> 
> Regards,
> 
> Maarten
> 
> "Mannie, Eric" wrote:
> >
> > Hello Stephen,
> >
> > John refers to fast restoration schemes that are being studied at the
> IETF.
> > Such schemes are widely implemented in the new classes of optical/TDM
> > equipments.
> >
> > The wording of the text just need to use the terms "working" LSP and
> > "protecting" LSP, instead of primary and secondary. That's just an editing
> > modification.
> >
> > The bit itself is useful to qualify the LSP being established.
> >
> > The mechanisms to be applied to this qualification will be detailed in
> other
> > documents.
> >
> > In the mean time, I guess that this bit can be used by implementations for
> a
> > simple restoration scheme (e.g. first establish working and protecting
> LSPs,
> > resources of protecting LSP may be "soft reserved", i.e. for
> extra-traffic,
> > when a fault occur send an RSVP-TE rapid failure notification to the
> source,
> > send Path with bit set to "working" on protecting LSP, this kills all LSPs
> > using these resources, when acked switch to this LSP).
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> > Sent: Tuesday, December 18, 2001 7:38 PM
> > To: John Drake
> > Cc: Maarten Vissers; ccamp@ops.ietf.org
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> > John,
> > The problem here is that this is not compatible with transport plane
> > protection.
> > Assume you do 1:n MSP protection according to ITU Rec. G.841. The
> operation
> > of
> > the protection group is controlled by exchange of the K1, K2 bytes in the
> > MSOH of the PROTECTION MS. If the control plane reuses the protection MS
> at
> > for a different LSP at a time when the state of the protection group is
> > "No Request" (assuming no extra traffic carried on the protection section
> in
> > the
> > transport plane), this disables the protection since the endpoints of the
> > protection group are no longer able to exchange K1, K2 over the protection
> > channel. Even though the payload is unused and irrelevant to the transport
> > plane at this point, the exchange of overhead is essential to proper
> > operation
> > of the protection group.
> > Regards,
> > Steve
> >
> > 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.
> > > > > >
begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard