Subject: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Wed, 17 Jul 2013 19:22:32 +0000

Dear all,
we would like socializing the herebelow drafts that were submitted some months ago with the aim to align PSC protocol (RFC 6378) to ITU-T transport requirements. I would appreciate your comments about the proposed mechanisms and behaviours.

draft-rhd-mpls-tp-psc-priority-00
draft-cdh-mpls-tp-psc-non-revertive-00
draft-rhd-mpls-tp-psc-sd-00
draft-dj-mpls-tp-exer-psc-01 / draft-osborne-mpls-psc-alive-00

The above drafts cover most of items highlighted in ITU-T liaisons about PSC and they propose solutions in line with MPLS-TP transport requirements.
A list of main liaisons exchanged between ITU-T and IETF with the aim to align PSC behavious with ITU-T transport requirements for linear protection are given below:
https://datatracker.ietf.org/liaison/1162/  (June 2012)
https://datatracker.ietf.org/liaison/1205/<https://datatracker.ietf.org/liaison/1162/>  (October 2012)
https://datatracker.ietf.org/liaison/1229/<https://datatracker.ietf.org/liaison/1162/>   (January 2013)
https://datatracker.ietf.org/liaison/1234/<https://datatracker.ietf.org/liaison/1162/>   (February 2013)
https://datatracker.ietf.org/liaison/1256/<https://datatracker.ietf.org/liaison/1162/>   (May 2013)

Some details abou the proposed drafts for align PSC behaviour with transport requirements:

draft-rhd-mpls-tp-psc-priority-00 proposes swapping the priorities between FS and SF-P (see section 4.3.2 of rfc6378).
Among the others, behaviors that will be fixed with the proposed update are:
Use case A) At first, working path(WP) and protection path(PP) are normal. Then, Forced Switch(FS) command is issued for maintenance on the WP and the traffic moves from WP to PP.  When Signal Fail occurs on PP, service cannot recover and is interrupted. This could occur for example as a result of accidentally un-plugging a PP fiber.
Use case B) If there is an existing signal fail on a protection path (SF-P),and FS command is issued by accident  the traffic on WP will move to PP. This results in an interruption of service from which you will not automatically recover, because PSC should not have switched the traffic from WP to PP.
Discussion about this draft led to the proposal to modify RFC 4427 that was "written correctly though lacking in detail causing mis-interpretation" that led to the current PSC set of priority that the above draft is proposing to modified and to align to the required transport behavior. draft-helvoort-ccamp-fs-priority-00 has been submitted to CCAMP for clarifying the definitions related to Manual Switch and Forced Switch and their usage relative to priorities.
The way this behavior has to be incorporated into the PSC has to be discussed. The text proposes to replace the current behavior with the new one. If there is consensus to procede in that way this can bring to a simple and effective way to operate the protocol.

----------------------------------------------------------------------
draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates to RFC6378  to change non-revertive operations to behaves in the same way irrespectively of the trigger of protection switching (fault or operator command FS, MS).  Consequently an operator command, Manual Switch to Working (MS-W) a.k.a “Manual switch-over for recovery LSP/span” is also added to enable this behavior. From an operational point of view, MS to working path has also to be supported to be able to initially align at both sides in case of non-revertive switching mode. MS to working path is defined in RFC 5654, requirement 83.

The proposed MS-W command is of equal priority to the existing MS-P command, and there is text to handle the simultaneous or sequential occurrence of two equal-priority commands. This behavior, already adopted in other transport network protection switching protocol, can be used for other addition to the protocol in the future.

----------------------------------------------------------------------
draft-rhd-mpls-tp-psc-sd-00  provides extensions to the PSC state machine to handle Signal Degrade (SD).  It does not define SD or provide scope around where or how SD may be used similarly as it already happen in the draft in handling other defects like SF (Signal Failure).
In MPLS-TP survivability framework  [RFC6372], a fault condition includes both Signal Fail (SF) and  Signal Degrade (SD) that can be used to trigger protection switching.
While the standardization lack of an SD definition and detection mechanisms, the relevant behaviors in terms of protection actions may already be defined.

----------------------------------------------------------------------
draft-dj-mpls-tp-exer-psc-01 proposes adding the EXER/RR commands to test if the APS communication is operating correctly. In other words both APS process logic including state machine and APS channel on protection path, without service disruption and without affecting any protection operation, unless the protection transport entity is in use. This command is documented in R84 of [RFC5654] and it is part of ITU-T transport requirements.
An alternative proposal is documented in the Appendix B of RFC6378 that utilizes the Lockout of Protection (LO) or Forced Switch (FS) in combination of OAM functionalities. However, it has some functional limitation and has a potential risk of losing traffic as a signal failure might occur during the exercise operation. In that case, LO or FS has to be canceled to allow the PSC protocol to provide proper switching.
A further alternative proposal is documented in draft-osborne-mpls-psc-alive-00 that anyway show some functional limitations because cannot validate the PSC state machine status and probably the Local Request logic.

The authors encourage the IETF experts to comment on these drafts, eventually proposing other options/mechanisms that can satisfy the same requirements.
Best regards,
Alessandro, Huub, Jeong-dong, Taeksid
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Fri, 19 Jul 2013 17:48:03 +0000

Hi Alessandro-

 Thanks for this; the threads I started some time back seem to have died down, it's good to get them going again.
I have two things I never quite understood, can you clarify them for me?

i) can you explain EXER at a higher level?  I'm not looking for a description of the state machine changes, and I'm not looking for the one line "It allows the FSM to be tested".  We have all of that in the draft and in the equivalent ITU specs.

What I'd like to understand about EXER is where it came from.  The ITU specs that define it are pretty hard to follow, they seem to assume the reader already knows what EXER is and what problem it solves.  It feels very much like a mechanism used to catch a very specific implementation bug, back when transport gear was far less debuggable than what we have today.  

No other state machines that I'm familiar with (RSVP, LDP, BGP, OSPF, ISIS) have explicit signaling in them just to ask the neighbor whether it *would* be broken if if were, in the future, to be given a particular input.  Part of my reluctance to get behind EXER has been that I don't feel comfortable with the idea of keeping a 30-year-old workaround in a protocol.  Is there more to it than that?  Have I misread and misunderstood EXER?  Does modern transport gear ever actually detect a problem via EXER/RR that wasn't obvious to the operator using other means?

ii) Why the push to standardize the SD state changes before we've defined SD?  I certainly agree that handling signal degrade is a good idea, but coming up with a definition for it has been challenging.  What happens if we change the FSM to handle it, then come up with something more sophisticated (say, multiple levels of SD) that doesn't quite fit with the FSM changes?  

thanks!

eric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> D'Alessandro Alessandro Gerardo
> Sent: Wednesday, July 17, 2013 3:23 PM
> To: [email-masked]
> Cc: Huub helvoort ([email-masked]); [email-masked]
> Subject: [mpls] proposed drafts for aligning MPLS-TP PSC linear
> protection protocol to transport requirements
> 
> Dear all,
> we would like socializing the herebelow drafts that were submitted some
> months ago with the aim to align PSC protocol (RFC 6378) to ITU-T
> transport requirements. I would appreciate your comments about the
> proposed mechanisms and behaviours.
> 
> The above drafts cover most of items highlighted in ITU-T liaisons about
> PSC and they propose solutions in line with MPLS-TP transport
> requirements.
> A list of main liaisons exchanged between ITU-T and IETF with the aim to
> align PSC behavious with ITU-T transport requirements for linear
> protection are given below:
> https://datatracker.ietf.org/liaison/1205/
> <https://datatracker.ietf.org/liaison/1162/>   (October 2012)
> https://datatracker.ietf.org/liaison/1229/
> <https://datatracker.ietf.org/liaison/1162/>    (January 2013)
> https://datatracker.ietf.org/liaison/1234/
> <https://datatracker.ietf.org/liaison/1162/>    (February 2013)
> https://datatracker.ietf.org/liaison/1256/
> <https://datatracker.ietf.org/liaison/1162/>    (May 2013)
> 
> draft-rhd-mpls-tp-psc-priority-00 proposes swapping the priorities
> between FS and SF-P (see section 4.3.2 of rfc6378).
> Use case A) At first, working path(WP) and protection path(PP) are
> normal. Then, Forced Switch(FS) command is issued for maintenance on the
> WP and the traffic moves from WP to PP.  When Signal Fail occurs on PP,
> service cannot recover and is interrupted. This could occur for example
> as a result of accidentally un-plugging a PP fiber.
> Use case B) If there is an existing signal fail on a protection path
> (SF-P),and FS command is issued by accident  the traffic on WP will move
> to PP. This results in an interruption of service from which you will
> not automatically recover, because PSC should not have switched the
> traffic from WP to PP.
> Discussion about this draft led to the proposal to modify RFC 4427 that
> was "written correctly though lacking in detail causing mis-
> interpretation" that led to the current PSC set of priority that the
> above draft is proposing to modified and to align to the required
> transport behavior. draft-helvoort-ccamp-fs-priority-00 has been
> submitted to CCAMP for clarifying the definitions related to Manual
> Switch and Forced Switch and their usage relative to priorities.
> The way this behavior has to be incorporated into the PSC has to be
> discussed. The text proposes to replace the current behavior with the
> new one. If there is consensus to procede in that way this can bring to
> a simple and effective way to operate the protocol.
> 
> draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates to RFC6378
> to change non-revertive operations to behaves in the same way
> irrespectively of the trigger of protection switching (fault or operator
> command FS, MS).  Consequently an operator command, Manual Switch to
> Working (MS-W) a.k.a "Manual switch-over for recovery LSP/span" is also
> added to enable this behavior. From an operational point of view, MS to
> working path has also to be supported to be able to initially align at
> both sides in case of non-revertive switching mode. MS to working path
> is defined in RFC 5654, requirement 83.
> 
> The proposed MS-W command is of equal priority to the existing MS-P
> command, and there is text to handle the simultaneous or sequential
> occurrence of two equal-priority commands. This behavior, already
> adopted in other transport network protection switching protocol, can be
> used for other addition to the protocol in the future.
> 
> draft-rhd-mpls-tp-psc-sd-00  provides extensions to the PSC state
> machine to handle Signal Degrade (SD).  It does not define SD or provide
> scope around where or how SD may be used similarly as it already happen
> in the draft in handling other defects like SF (Signal Failure).
> In MPLS-TP survivability framework  [RFC6372], a fault condition
> includes both Signal Fail (SF) and  Signal Degrade (SD) that can be used
> to trigger protection switching.
> While the standardization lack of an SD definition and detection
> mechanisms, the relevant behaviors in terms of protection actions may
> already be defined.
> 
> draft-dj-mpls-tp-exer-psc-01 proposes adding the EXER/RR commands to
> test if the APS communication is operating correctly. In other words
> both APS process logic including state machine and APS channel on
> protection path, without service disruption and without affecting any
> protection operation, unless the protection transport entity is in use.
> This command is documented in R84 of [RFC5654] and it is part of ITU-T
> transport requirements.
> An alternative proposal is documented in the Appendix B of RFC6378 that
> utilizes the Lockout of Protection (LO) or Forced Switch (FS) in
> combination of OAM functionalities. However, it has some functional
> limitation and has a potential risk of losing traffic as a signal
> failure might occur during the exercise operation. In that case, LO or
> FS has to be canceled to allow the PSC protocol to provide proper
> switching.
> A further alternative proposal is documented in draft-osborne-mpls-psc-
> alive-00 that anyway show some functional limitations because cannot
> validate the PSC state machine status and probably the Local Request
> logic.
> 
> 
> The authors encourage the IETF experts to comment on these drafts,
> eventually proposing other options/mechanisms that can satisfy the same
> requirements.
> Best regards,
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente
> vietate. Qualora abbiate ricevuto questo documento per errore siete
> cortesemente pregati di darne immediata comunicazione al mittente e di
> provvedere alla sua distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may contain
> privileged information intended for the addressee(s) only.
> Dissemination, copying, printing or use by anybody else is unauthorised.
> If you are not the intended recipient, please delete this message and
> any attachments and advise the sender by return e-mail, Thanks.
> 
> rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non
> è necessario.

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Mon, 22 Jul 2013 08:14:56 +0000

Hi, Eric.

Let me answer your 2nd question on SD.

SD detection methods defined or proposed for packet transport networks can be summarized as follows:
- By OAM performance monitoring tool:
  SD is raised if packet loss ratio exceeds a threshold during a measurement period.
  Threshold value and measurement period are configured by an network operator.
  This detection method is already defined in ITU-T G.8021 (Ethernet equipment spec.)
  and the equipment spec for MPLS-TP can easily follow the same definition.
- By server layer indication:
  SD is raised if a server layer below MPLS-TP reports SD condition on its own layer.
- By CCM packet counting:
  SD is raised if the loss ratio of CCM packets exceeds a threshold during a measurement period.

Regardless of how to detect SD, any protection switching documents should describe the protection switching operation once such a SD is declared.

The proposed draft covers SD-triggered protection no matter what kinds of SD detection methods are used.

Regarding the multiple levels of SD:
It is certainly possible to define multiple levels of SD.
But, as far as the protection switching is concerned, it just needs to know if SD is signaled to protection switching process or not.
It would be a network operator's choice at what level of SD he wants his network protection to switchover.
In other words, what triggers protection switching is SD or no SD. It is yes or no decision.

SF can also be viewed as having multiple levels of SF as the network operator can also make a choice on the period/interval of CCM messages.
If CCM is disabled, AIS from a server layer can be used as a trigger for protection switching. So and so forth.
However, protection switching document does not define how to detect SF in anywhere.
Similary, protection switching document does not define how manual switch and forced switch commands
are initiated in a management system and signaled to protection switching process.

Again, in my opinion, the draft on SD protection can accommodate any SD detection methods.

Best regards,

Jeong-dong

________________________________
From : "Eric Osborne (eosborne)" <[email-masked]>
Sent : 2013-07-20 02:48:28 ( +09:00 )
To : D'Alessandro Alessandro Gerardo <[email-masked]>, [email-masked] <[email-masked]>
Cc : Huub helvoort ([email-masked]) <[email-masked]>, [email-masked] <[email-masked]>
Subject : Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements

Hi Alessandro-

thanks!

eric

> (October 2012)
> (January 2013)
> (February 2013)
> (May 2013)

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "S. Davari" <[email-masked]>
Date: Mon, 22 Jul 2013 12:05:18 +0200

Hi, 

Couple of points. The SD trigger for protection and requires you to run Performance measurement on all LSPs and PWs, which is not scalable.

Also there is no standard method defined to count CCM or BFD packets. 

Regards,
Shahram

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Mon, 22 Jul 2013 10:22:21 +0000

Hi, Shahram.

There are pros and cons for each detection method.
There have been a lot of discussions and arguements around the SD detection.
People can continue the discussions and define any additional mechanisms in any relevant standards later on.

From the viewpoint of protection switching, what matters is how to provide protection switching against SD when it occurs.

Best regards,

Jeong-dong

________________________________
From : "S. Davari" <[email-masked]>
Sent : 2013-07-22 19:06:11 ( +09:00 )
To : Ryoo, Jeong-dong <[email-masked]>
Cc : Eric Osborne (eosborne) <[email-masked]>, D'Alessandro Alessandro Gerardo <[email-masked]>, [email-masked] <[email-masked]>, Huub helvoort ([email-masked]) <[email-masked]>, [email-masked] <[email-masked]>
Subject : Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements

Hi,

Regards,
Shahram

On Jul 22, 2013, at 10:14 AM, "Ryoo, Jeong-dong" <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Eric.

Best regards,

Jeong-dong

________________________________
From : "Eric Osborne (eosborne)" <[email-masked]<mailto:[email-masked]>>
Sent : 2013-07-20 02:48:28 ( +09:00 )
To : D'Alessandro Alessandro Gerardo <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc : Huub helvoort ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject : Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements

Hi Alessandro-

thanks!

eric

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
> To: [email-masked]<mailto:[email-masked]>
> Cc: Huub helvoort ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 22 Jul 2013 13:19:29 +0200

Hello Eric,

You wrote:

> Thanks for this; the threads I started some time back seem to have
> died down, it's good to get them going again.

There was atwo week ITU-T plenary meeting, and after that I took
(and still have) a holiday.

> I have two things I never quite understood, can you clarify them

OK, I'll try. See in-line [Huub]

> i) can you explain EXER at a higher level?  I'm not looking for a
> description of the state machine changes, and I'm not looking for the
> one line "It allows the FSM to be tested".  We have all of that in
> the draft and in the equivalent ITU specs.
>
> What I'd like to understand about EXER is where it came from.  The
> ITU specs that define it are pretty hard to follow, they seem to
> assume the reader already knows what EXER is and what problem it
> solves.  It feels very much like a mechanism used to catch a very
> specific implementation bug, back when transport gear was far less
> debuggable than what we have today.

[Huub] EXER was not designed/intended to be used for bug finding
although it will detect problems with implementation.

[Huub] EXER was designed to verify that the state-machine at the
far end is able to respond to APS/PSC messages it receives from
the local end.
Even though state-machines should be tested extensively, there is
no 100% warranty. It can still have stopped due to external
circumstances, be in a deadlock due to unforseen order of events,
etc.

[Huub] note that APS/PSC should continue to operate even if no
control plane is available. The EXER is to enable an operator to
take corrective action before a protection switch request fails
and the 50ms switch time is not met.

> No other state machines that I'm familiar with (RSVP, LDP, BGP, OSPF,
> ISIS) have explicit signaling in them just to ask the neighbor
> whether it *would* be broken if if were, in the future, to be given a
> particular input.

[Huub] All these rely on a control plane, some of then include
"keepalive" messages to see if the far end responds.

> Part of my reluctance to get behind EXER has been
> that I don't feel comfortable with the idea of keeping a 30-year-old
> workaround in a protocol.

[Huub] it is NOT a workaround, it is an essential part of the
protocol.

> Is there more to it than that?  Have I
> misread and misunderstood EXER?  Does modern transport gear ever
> actually detect a problem via EXER/RR that wasn't obvious to the
> operator using other means?

[Huub] if there is no control plane I have no other means.
What means are available to verify if a state-machine that is
in a stable state is still functioning?

> ii) Why the push to standardize the SD state changes before we've
> defined SD?  I certainly agree that handling signal degrade is a good
> idea, but coming up with a definition for it has been challenging.
> What happens if we change the FSM to handle it, then come up with
> something more sophisticated (say, multiple levels of SD) that
> doesn't quite fit with the FSM changes?

[Huub] the definition of the signal degrade defect that causes the
SD event for the APS/PSC is still under discussion, but the APS/PSC
response to an SD event should be included. If we don't do it now
we have to issue another version of PSC later with all kinds of
backwards compatibility issues, additional complexity, and options
that operators do not like to have to manage.

[Huub] APS/PSC now responds to an SF event, based on detected
signal fail defects. However in the future we may extend the
signal fail defect by another probable cause. This will not
affect the existing APS/PCS.

Regards, Huub.

-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Mon, 22 Jul 2013 13:03:03 +0000

Hi,
I understand your point but I believe it is not relevant to the proposed modification to PSC to manage SD.
Actually if it is appropriate to carry out PM on all LSPs/PWs or on a subset of LSPs/PWs is a carrier decision based on costs / benefits analysis. Moreover the method that will be used for signal degrade detection (you mentiond CCM or BFD packet count) is not relevant to PSC. In fact the proposed changes only describe how the linear protection mechanism behaves when SD occurs (and not how to detect SD).

I believe there are two main points that are really important and that are relevant to PSC when we talk about SD. Those points have been highlighted in previous emails about this threat from Jeong-dong and Huub: it is important to be able to provide protection switching when signal degrade occurs if a carrier has set SD as a criteria for doing that and it is important to add now the description on how PSC protection switching protocol behaves to avoid to face with extra operational costs for carriers and with extra developing costs for vendors in adding this functionality later on to the PSC.

best regards,
Alessandro
PS sorry for being late in answering but I'm on holiday

________________________________
From: S. Davari [[email-masked]]
Sent: Monday, July 22, 2013 12:05 PM
To: Ryoo, Jeong-dong
Cc: Eric Osborne (eosborne); D'Alessandro Alessandro Gerardo; [email-masked]; Huub helvoort ([email-masked]); [email-masked]
Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements

Hi,

Regards,
Shahram

Hi, Eric.

Best regards,

Jeong-dong

Hi Alessandro-

thanks!

eric

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Jul 2013 14:12:41 +0100

> circumstances, be in a deadlock due to unforseen order of events,

Huub,

I get a terrible Heisenberg feeling when you explain this to me.

It is not clear whether or not including the EXER state and executing
it from time to time poses a greater risk than assuming that :
provided the daemon is running and the variables are as expected,
the code will execute correctly.

Stewart

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 22 Jul 2013 13:36:14 +0000

Hi Jeong-dong,

  Thanks for the reply.  Please see inline with EO#.

> From: Ryoo, Jeong-dong [mailto:[email-masked]]
> Sent: Monday, July 22, 2013 4:15 AM
> To: Eric Osborne (eosborne); D'Alessandro Alessandro Gerardo;
> [email-masked]
> Subject: RE: [mpls] proposed drafts for aligning MPLS-TP PSC linear

EO#  Where?  I'm not arguing that it's not in there, I'm just having a hard time finding it.  A search for ETH_CI_SSD doesn't yield much.  If I look for 'signal degrade' I see p. 131 which says that the algorithm is defined in G.8031.  G.8031 says ' How these defects are detected is the subject of the equipment Recommendations'.  I'm looking for something like "Signal Degrade is defined as $foo packet loss or CRC failure over $bar time"....what have I missed?

> Regardless of how to detect SD, any protection switching documents
> should describe the protection switching operation once such a SD is
> declared.
> 
...
> But, as far as the protection switching is concerned, it just needs to
> know if SD is signaled to protection switching process or not.

EO#  I am not aware of any document which suggests that a server layer SD should be treated as a client layer SD.  In the IP world, if we have SD on a transport interface that is generally used to bring the interface down (i.e. SF).  This is the sort of thing I'd like to see in more detail, as SD in the packet world is a new concept and we can't just assume that it will work the same everywhere because we define state machine points for it.

The point about CCM is a good one.  Let's say we come up with a clever SD mechanism with two thresholds, call them major and minor.  For discussion purposes they could be simple error ratios, e.g. 1:10^6 and 1:10^9.  But they could be more powerful than that (flow type, flow length, error burst size, etc).

If we want to have SD-Major and SD-Minor inputs as separate triggers for PSC, we may want them at different points.  Perhaps  (leaving out the Working path for ease of reading)

LO
FS
SF-P
SD-P-Major
MS
SD-P-Minor

This seems like a perfectly reasonable thing to want.  

Even if we don't have multi-tier SD, even the single-tier SD needs to be defined before we can decide how to respond to it.

> SF can also be viewed as having multiple levels of SF as the network
> operator can also make a choice on the period/interval of CCM messages.

EO# 
I'm not sure what that would look like.  'Fail' is a pretty binary thing.  'Degrade' is a continuous variable, as it can be anything from 'a little bad' to a 'a whole lot of bad but not quite fail'.

> protection switching. So and so forth.

EO#  AIS from the server layer only gets you SD from the first hop of the underlying server path.

eric

> To : D'Alessandro Alessandro Gerardo
> <[email-masked]>, [email-masked] <[email-masked]>
> Cc : Huub helvoort ([email-masked])
> <[email-masked]>, [email-masked]
> <[email-masked]>
> Subject : Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear
> one line "It allows the FSM to be tested". We have all of that in the
> draft and in the equivalent ITU specs.
> 
> What I'd like to understand about EXER is where it came from. The ITU
> specs that define it are pretty hard to follow, they seem to assume the
> reader already knows what EXER is and what problem it solves. It feels
> very much like a mechanism used to catch a very specific implementation
> bug, back when transport gear was far less debuggable than what we have
> today.
> 
> ISIS) have explicit signaling in them just to ask the neighbor whether
> it *would* be broken if if were, in the future, to be given a particular
> input. Part of my reluctance to get behind EXER has been that I don't
> feel comfortable with the idea of keeping a 30-year-old workaround in a
> protocol. Is there more to it than that? Have I misread and
> misunderstood EXER? Does modern transport gear ever actually detect a
> problem via EXER/RR that wasn't obvious to the operator using other
> means?
> 
> 
> idea, but coming up with a definition for it has been challenging. What
> happens if we change the FSM to handle it, then come up with something
> more sophisticated (say, multiple levels of SD) that doesn't quite fit
> with the FSM changes?
> 
> 
> 
> thanks!
> 
> 
> 
> 
> 
> eric
> 
> 
> > Among the others, behaviors that will be fixed with the proposed
> update
> > are:

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 22 Jul 2013 13:42:20 +0000

Inline with EO#, trimmed a bit.

> (and still have) a holiday.

If you're on holiday, why are you working?  I thought that was a uniquely American trait.  Is this stuff that much fun to you? :)

...

> circumstances, be in a deadlock due to unforseen order of events,

EO#  I agree with your last two statements.  To me, though, that very text is a reasonable argument against EXER.  There is no mechanism within a protocol which can guarantee that the entire state machine is 100% perfect.  A node could be able to respond to EXER/RR but be unable to process a real failure properly, either due to bug or to (as you indicate) some unforseen combination of external events.  The class of problems which EXER can catch but which will not be detectable by other means (e.g. CC/CV, see below) seems pretty small.

In the transport world, what sort of problems does EXER _actually find_?  I'm not asking about things it _could_ find, but things that it *does*.

> control plane is available. 

EO#  I agree, but this is not relevant to the discussion at hand.  Lots of work was done in TP to ensure that it would function without the ability to forward IP packets (which I think is what you mean by 'no control plane').  None of that has anything to do with the set of messages and states in PSC.

> The EXER is to enable an operator to

EO#  PSC has keepalives; see section 4.1 of rfc6378 - "The purpose of the continual messages is to verify that the PSC session is still alive."

The next sentence says "If no valid PSC message is received, over a period of several continual messages intervals, the last valid received message remains applicable."  As an implementor, what that means to me is that I time out only after the loss of a few retransmissions.  

> [Huub] it is NOT a workaround, it is an essential part of the

EO#  In a TDM world, I can see this point.  APS is carried in the frame header, so the receipt of an APS message doesn't mean that there's any intelligence behind it as it could just be the hardware repeating the last APS overhead that it sent.  If a PSC message is sent it must have been sent deliberately, as during steady state we have periodic retransmissions.  Do you agree?

> in a stable state is still functioning?

EO#  Periodic retransmission of current state by the remote side.  This performs the exact same function as a keepalive in any other protocol, and I think we agree that the keepalive function in protocols such as OSPF is sufficient to ensure the sanity of the remote end.  Many, many protocols use keepalives as a sort of belt-and-suspenders failure detection mechanism.  In the IP world these mechanisms are far, far less useful than they used to be as we now have BFD.  

That brings us to CC/CV.   Lots of work was done to ensure that it did not require IP to function.  I cannnot believe that any TP implementation would ship without some sort of CC/CV, and isn't that a strong enough mechanism to detect the failure of the remote end?

> that operators do not like to have to manage.

EO#
See my reply to Jeong-dong on this.  

eric

---

From: "Huber, Thomas J." <[email-masked]>
Date: Mon, 22 Jul 2013 14:03:36 -0500

Hi Eric,

>I'm not sure what that would look like.  'Fail' is a pretty binary thing.  'Degrade' is a continuous variable, as it can be anything from 'a little bad' to a 'a whole lot of bad but not quite fail'.

I think this may be a fundamental difference in assumptions.  While it is certainly true that degradation of a signal is a continuous variable, in the context of protection switching in the transport network, there is a particular value of that continuous variable that defines the threshold at which the Boolean variable "signal degrade (SD)" becomes true.  It is for this reason that Jeong-dong and others are suggesting that it should be possible to incorporate the behavior of the SD state into the PSC definition without needing to have a precise definition of the mechanism for measuring the degradation of a signal.  Whatever the mechanism is, it will be converted to the binary SD indication.

Best regards,
Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Osborne (eosborne)
Sent: Monday, July 22, 2013 8:36 AM
To: Ryoo, Jeong-dong; D'Alessandro Alessandro Gerardo; [email-masked]
Cc: Huub helvoort ([email-masked]); [email-masked]
Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements

Hi Jeong-dong,

...

LO
FS
SF-P
SD-P-Major
MS
SD-P-Minor

EO#

> If CCM is disabled, AIS from a server layer can be used as a trigger
> for protection switching. So and so forth.

eric

> Similary, protection switching document does not define how manual
> switch and forced switch commands are initiated in a management system
> and signaled to protection switching process.
>
> From : "Eric Osborne (eosborne)" <[email-masked]> Sent :
> 2013-07-20 02:48:28 ( +09:00 ) To : D'Alessandro Alessandro Gerardo
> <[email-masked]>, [email-masked]
> <[email-masked]> Cc : Huub helvoort ([email-masked])
> <[email-masked]> Subject : Re: [mpls] proposed drafts for
> aligning MPLS-TP PSC linear protection protocol to transport
> requirements
>
>
> Hi Alessandro-
>
> specs that define it are pretty hard to follow, they seem to assume
> the reader already knows what EXER is and what problem it solves. It
> feels very much like a mechanism used to catch a very specific
> implementation bug, back when transport gear was far less debuggable
> than what we have today.
>
> it *would* be broken if if were, in the future, to be given a
> particular input. Part of my reluctance to get behind EXER has been
> workaround in a protocol. Is there more to it than that? Have I
> something more sophisticated (say, multiple levels of SD) that doesn't
> quite fit with the FSM changes?
>
>
>
> thanks!
>
>
>
>
>
> eric
>
>
> > A list of main liaisons exchanged between ITU-T and IETF with the
> > aim
> to
> > WP and the traffic moves from WP to PP. When Signal Fail occurs on
> > PP, service cannot recover and is interrupted. This could occur for
> example
> > to PP. This results in an interruption of service from which you
> > will not automatically recover, because PSC should not have switched
> > the traffic from WP to PP.
> > discussed. The text proposes to replace the current behavior with
> > the new one. If there is consensus to procede in that way this can
> > bring
> to
> > draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates to
> > RFC6378 to change non-revertive operations to behaves in the same
> > way irrespectively of the trigger of protection switching (fault or
> operator
> > working path has also to be supported to be able to initially align
> > at both sides in case of non-revertive switching mode. MS to working
> > path is defined in RFC 5654, requirement 83.
> >
> > adopted in other transport network protection switching protocol,
> > can
> be
> > mechanisms, the relevant behaviors in terms of protection actions
> > may already be defined.
> >
> > protection path, without service disruption and without affecting
> > any protection operation, unless the protection transport entity is
> > in
> use.
> > This command is documented in R84 of [RFC5654] and it is part of
> > ITU-T transport requirements.
> > failure might occur during the exercise operation. In that case, LO
> > or FS has to be canceled to allow the PSC protocol to provide proper
> > switching.
> > Alessandro, Huub, Jeong-dong, Taeksid Questo messaggio e i suoi
> > allegati sono indirizzati esclusivamente
> alle
> > cortesemente pregati di darne immediata comunicazione al mittente e
> > di provvedere alla sua distruzione, Grazie.
> >
> > If you are not the intended recipient, please delete this message
> > and any attachments and advise the sender by return e-mail, Thanks.
> >

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 22 Jul 2013 20:12:28 +0000

Hi Tom-

  That's a good way to put it, and I think it captures the two opinions.  My concern with the boolean SD approach is that it's been a struggle to define SD at all for IP/MPLS networks.  I can echo Jeong-Dong's point here - SD could be server SD [SSD], it could be PM, it could be CCM.  Unless we actually define SD, it's not at all clear to me that IP SD will in fact be a simple yes/no thing.  What if we decide that both PM and SSD are valid, but that one of them is worse than the other?  

  Just so we're clear - I am not against the concept of SD in PSC.  I am against defining how we react to an event before we define the event itself.

eric

> From: Huber, Thomas J. [mailto:[email-masked]]
> Sent: Monday, July 22, 2013 3:04 PM
> To: Eric Osborne (eosborne); Ryoo, Jeong-dong; D'Alessandro Alessandro
> Gerardo; [email-masked]
> >I'm not sure what that would look like.  'Fail' is a pretty binary
> thing.  'Degrade' is a continuous variable, as it can be anything from
> 'a little bad' to a 'a whole lot of bad but not quite fail'.
> 
> I think this may be a fundamental difference in assumptions.  While it
> is certainly true that degradation of a signal is a continuous variable,
> in the context of protection switching in the transport network, there
> is a particular value of that continuous variable that defines the
> threshold at which the Boolean variable "signal degrade (SD)" becomes
> true.  It is for this reason that Jeong-dong and others are suggesting
> that it should be possible to incorporate the behavior of the SD state
> into the PSC definition without needing to have a precise definition of
> the mechanism for measuring the degradation of a signal.  Whatever the
> mechanism is, it will be converted to the binary SD indication.
> 
> Best regards,
> Tom
> 
> 
> Eric Osborne (eosborne)
> Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear
> EO#  Where?  I'm not arguing that it's not in there, I'm just having a
> hard time finding it.  A search for ETH_CI_SSD doesn't yield much.  If I
> look for 'signal degrade' I see p. 131 which says that the algorithm is
> defined in G.8031.  G.8031 says ' How these defects are detected is the
> subject of the equipment Recommendations'.  I'm looking for something
> like "Signal Degrade is defined as $foo packet loss or CRC failure over
> $bar time"....what have I missed?
> 
> 
> EO#  I am not aware of any document which suggests that a server layer
> SD should be treated as a client layer SD.  In the IP world, if we have
> SD on a transport interface that is generally used to bring the
> interface down (i.e. SF).  This is the sort of thing I'd like to see in
> more detail, as SD in the packet world is a new concept and we can't
> just assume that it will work the same everywhere because we define
> state machine points for it.
> 
> The point about CCM is a good one.  Let's say we come up with a clever
> SD mechanism with two thresholds, call them major and minor.  For
> discussion purposes they could be simple error ratios, e.g. 1:10^6 and
> 1:10^9.  But they could be more powerful than that (flow type, flow
> length, error burst size, etc).
> 
> If we want to have SD-Major and SD-Minor inputs as separate triggers for
> PSC, we may want them at different points.  Perhaps  (leaving out the
> Working path for ease of reading)
> 
> LO
> FS
> SF-P
> SD-P-Major
> MS
> SD-P-Minor
> 
> 
> Even if we don't have multi-tier SD, even the single-tier SD needs to be
> defined before we can decide how to respond to it.
> 
> I'm not sure what that would look like.  'Fail' is a pretty binary
> thing.  'Degrade' is a continuous variable, as it can be anything from
> 'a little bad' to a 'a whole lot of bad but not quite fail'.
>

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 23 Jul 2013 01:11:20 +0200

Hello Eric,

 > Inline with EO#, trimmed a bit.

My response inline [Huub2]

> If you're on holiday, why are you working?

[Huub2] It is too hot outside, and I had dug out my logbooks from
before 1984, I want to to return to storage as soon as possible  ^_^

>  I thought that was a uniquely American trait.

[Huub2] maybe it is infectious...

> Is this stuff that much fun to you? :)

[Huub2] my wife does not like the piles of logbooks and I like
to share my knowledge

> EO#  I agree with your last two statements.  To me, though, that
 > very text is a reasonable argument against EXER.
 > There is no mechanism within a protocol which can guarantee that
 > the entire state machine is 100% perfect.

[Huub2] indeed

> A node could be able to respond to EXER/RR but be unable to process
 > a real failure properly, either due to bug or to (as you indicate)
 > some unforseen combination of external events.

[Huub2] in the case you describe the node has to send periodical
NR _AND_ respond to the EXER while not responding to a real SF/SD,
this would be a very complex state-machine fault.

> The class of problems which EXER can catch but which will not be
 > detectable by other means (e.g. CC/CV, see below) seems pretty small.

[Huub2] the EXER will detect the most common "stuck-at" problems.

> In the transport world, what sort of problems does EXER _actually find_?
 >  I'm not asking about things it _could_ find, but things that it *does*.

[Huub2] stuck-at, deadlock

> EO#  I agree, but this is not relevant to the discussion at hand.
 > Lots of work was done in TP to ensure that it would function without
 > the ability to forward IP packets (which I think is what you mean by
 > 'no control plane').  None of that has anything to do with the set
 > of messages and states in PSC.

[Huub2] I did mean to say that the exercise request caanot be sent
via the control plane, so it should be in the dataplane. Since the
APS/PSC state-machine is exercised the EXER command should be part
of the APS/PSC protocol.

> EO#  PSC has keepalives; see section 4.1 of rfc6378 - "The purpose of
 > the continual messages is to verify that the PSC session is still alive."

[Huub2] it only proves that the state-machine can send NR priodically,
it does not prove that it wil respond to any external/remote events.
The EXER will give much more confidence of being alive.

> The next sentence says "If no valid PSC message is received, over a
 > period of several continual messages intervals, the last valid
 > received message remains applicable."  As an implementor, what that
 > means to me is that I time out only after the loss of a few
 > retransmissions.

[Huub2] yes, this is part if the PDU validation process

> EO#  In a TDM world, I can see this point.  APS is carried in the
 > frame header, so the receipt of an APS message doesn't mean that
 > there's any intelligence behind it as it could just be the hardware
 > repeating the last APS overhead that it sent.  If a PSC message is
 > sent it must have been sent deliberately, as during steady state
 > we have periodic retransmissions.  Do you agree?

[Huub2] similarly hardware (or software) can contiouously send
NR messages. So I agree that there is no difference between TDM
and packet APS/PSC.

> EO#  Periodic retransmission of current state by the remote side.
 > This performs the exact same function as a keepalive in any other
 > protocol, and I think we agree that the keepalive function in
 > protocols such as OSPF is sufficient to ensure the sanity of the
 > remote end.

[Huub2] see above for the possibilty of stuck-at repeating only
the NR message.

> Many, many protocols use keepalives as a sort of belt-and-suspenders
 > failure detection mechanism.  In the IP world these mechanisms are
 > far, far less useful than they used to be as we now have BFD.

[Huub2] I would consider the "hello" message to have the same purpose
as the EXER message: check if the remote BFD session is still up.

> That brings us to CC/CV.   Lots of work was done to ensure that it
 > did not require IP to function.  I cannnot believe that any TP
 > implementation would ship without some sort of CC/CV, and isn't
 > that a strong enough mechanism to detect the failure of the remote
 > end?

[Huub2] CC/CV only checks the conductivity and connectivity of a path
It has no relation at all with the APS/PSC state-machine other than
in case CC/CV causes a signal fail defect the resulting SF event
triggers the APS/PSC state-machine.

Regards, Huub.

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Tue, 23 Jul 2013 03:03:57 +0000

HI, Eric.

Thanks for the email.
Please see inline with [JR]

________________________________
From : "Eric Osborne (eosborne)" <[email-masked]>
Sent : 2013-07-22 22:36:21 ( +09:00 )
To : Ryoo, Jeong-dong <[email-masked]>, D'Alessandro Alessandro Gerardo <[email-masked]>, [email-masked] <[email-masked]>
Cc : Huub helvoort ([email-masked]) <[email-masked]>, [email-masked] <[email-masked]>
Subject : RE: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements

Hi Jeong-dong,

EO# Where? I'm not arguing that it's not in there, I'm just having a hard time finding it. A search for ETH_CI_SSD doesn't yield much. If I look for 'signal degrade' I see p. 131 which says that the algorithm is defined in G.8031. G.8031 says ' How these defects are detected is the subject of the equipment Recommendations'. I'm looking for something like "Signal Degrade is defined as $foo packet loss or CRC failure over $bar time"....what have I missed?
[JR] Yes, I know that it is rather difficult to find what we need from that document. In Table 6-2, defect detection and clearance for dDEG (degraded signal defect) are shown, and Clause 6.1.3.4 has detailed text description and flow chart (Figure 6-3) for detection and clearance for DEG. I guess this would be the one that you were looking for.
If you want to search further, then it will go like: dDEG --> ETH_AI_TSD --> ETH_CI_SSD.

...

LO
FS
SF-P
SD-P-Major
MS
SD-P-Minor

Even if we don't have multi-tier SD, even the single-tier SD needs to be defined before we can decide how to respond to it.
[JR] The server layer SD has been a proposal, and I have been told that there is proprietary implementation. But, this is outside the scope of PSC. What we need to care is whether SD is declared/cleared on working path and whether SD is decleared/cleared on protection path.
If any SD detection mechanism can signal this information to PSC, PSC is ready to provide the protection switching.

[JR] Regarding multi-tier SD, yes, I agree with you in principle.
Certainly, if protection againt SD-second is required, we can add anther request codepoint and priority level for it.
But, that doesn't mean we cannot define protection for the first SD.
There has been a strong demand for protection against SD.
So far, I haven't seen any demand for protection against the 2nd SD
and I cannot imagine how the protection against 2nd SD will be accepted, considering the protection against the first and only one SD is having this much difficult time.

EO#
I'm not sure what that would look like. 'Fail' is a pretty binary thing. 'Degrade' is a continuous variable, as it can be anything from 'a little bad' to a 'a whole lot of bad but not quite fail'.
[JR] Again, Eric. What we need is whether SD is declared/cleared on working path and whether SD is decleared/cleared on protection path.
It would be operator's choice at what level of degrade he wants his traffic to be switched over.

EO# AIS from the server layer only gets you SD from the first hop of the underlying server path.
[JR] It depends on where you want to put MEP for monitoring SD in the server layer.
AIS from the server layer can be propagated to client layer MEP node, which runs protection switching process, in multiple hops.

eric

> switch and forced switch commands
> From : "Eric Osborne (eosborne)"
> , [email-masked]
> , [email-masked]

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Tue, 23 Jul 2013 06:51:15 +0000

Eric,

I can understand your point, expecially the comlication around multiple choices of SD detection.

In linear protection switching, all we can do is to select one of two paths no matter how many different SD detection methods and SD levels.
There are multiple inputs/requests for protection switching, such as SF, MS, FS, etc.
What we have done so far is prioritization of those requests, and the most severe one takes one of two paths as it wants.
If there is a need for protection against multiple, more sophisticated SDs,
we can define a new request type and priority for the additional level of SD.

Currently, we are facing a demand for protection mechanism against one SD level, which has been the case for so long time since SDH.
For all the existing protection technologies including Ethernet, SD from protection point of view has always been a binary decision.
Let's work on supporting one SD level.

Best regards,

Jeong-dong

________________________________
From : "Eric Osborne (eosborne)" <[email-masked]>
Sent : 2013-07-23 05:12:35 ( +09:00 )
To : Huber, Thomas J. <[email-masked]>, Ryoo, Jeong-dong <[email-masked]>, D'Alessandro Alessandro Gerardo <[email-masked]>, [email-masked] <[email-masked]>
Cc : Huub helvoort ([email-masked]) <[email-masked]>, [email-masked] <[email-masked]>
Subject : RE: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements

Hi Tom-

eric

> > From : "Eric Osborne (eosborne)" Sent :
> > Subject : Re: [mpls] proposed drafts for

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 23 Jul 2013 12:57:50 +0200

Hello Steward,

> I get a terrible Heisenberg feeling when you explain this to me.

[Huub] I think Werner was referring to quantum mechanics...

> the code will execute correctly.

[Huub] if there is a simple way to verify that the NR messages
received periodically are not caused by a malfunctioning
state-machine, the risk of of detecting a malfunctioning
state-machine at the moment an SF/SD event occurs is reduced considerably.

Regards, Huub.

---

From: Larry <[email-masked]>
Date: Wed, 24 Jul 2013 09:46:16 +0800 (CST)

Hi all,

I agree with Tom and Jeong-dong. There are different reasons to cause SD, but the result is the transport performance degrade and it is important to let operators set a threshold to trigger protection switch. During the trouble shooting, operators need tools to do fault localization. Althought "degrade" is a continous variable behaviour, it is a "0/1" problem after defining the threshold.
Thank you!
 
*************************************************************************
Han Li, Ph.D 
China Mobile Research Institute
32 Xuanwumen West Street, Xicheng District, Beijing 100053, China 
Fax: +86 10 63135159 
MOBILE: 13501093385 
*************************************************************************

________________________________
 发件人： "Huber, Thomas J." <[email-masked]>
收件人： Eric Osborne (eosborne) <[email-masked]>; "Ryoo, Jeong-dong" <[email-masked]>; D'Alessandro Alessandro Gerardo <[email-masked]>; "[email-masked]" <[email-masked]> 
抄送： "Huub helvoort ([email-masked])" <[email-masked]>; "[email-masked]" <[email-masked]> 
发送日期： 2013年7月23日, 星期二, 3:03 上午
主题: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements

Hi Eric,

Best regards,
Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Osborne (eosborne)
Sent: Monday, July 22, 2013 8:36 AM
To: Ryoo, Jeong-dong; D'Alessandro Alessandro Gerardo; [email-masked]
Cc: Huub helvoort ([email-masked]); [email-masked]
Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements

Hi Jeong-dong,

...

LO
FS
SF-P
SD-P-Major
MS
SD-P-Minor

EO#

eric

---

From: Yaacov Weingarten <[email-masked]>
Date: Wed, 24 Jul 2013 08:20:34 +0300

Hi all,

While I personally support the idea of including the SD support in the
Linear Protection protocol, if only for compatibility with other comparable
tools, I feel there is a need to add the context that caused it to be
"downgraded" to place-holder status in PSC.

In the original draft versions of the PSC definition, we included SD
messages and described the switching operation when the system triggered an
SD situation. On the assumption that there would be a way to detect some
kind of SD. There were even some drafts that were proposed by different
members on how to define SD and detect it for MPLS. None of these latter
drafts were, however, accepted by the WG based upon the belief that SD is
not relevant at the MPLS level, it is more a system-layer or physical layer
issue and should be solved by those layers.

In addition, regarding the idea of switching the traffic from the working
to the protection path based on an SD situation on the working path was
frowned upon. This was based on the question of how do we assure that the
protection path is a better medium for the packet transport. Because even
if you could measure and identify an SD situation on the working path,
there is no way to measure it on the protection path, since it is most
probably affected by the load factors involved in the packet sizes.
Therefore, you are switching to a path that, at least in theory, could be a
worse choice!

This was the reasoning behind the downgrade of the SD signal and the note
that this is for further study.  I have not seen anyone in this discussion
address this issue, and therefore I think it is important that we hear some
justification for switching away from a working path to one that we have no
better information on! I think that the justifications given until now -
i.e. "this is the way it has always been done in physical layer systems"
- are not sufficient to add functionality that may cause poorer performance!

Hope this helps focus the discussion,
yaacov weingarten

On Wed, Jul 24, 2013 at 4:46 AM, Larry <[email-masked]> wrote:

> Hi all,
>
> I agree with Tom and Jeong-dong. There are different reasons to cause SD,
> but the result is the transport performance degrade and it is important to
> let operators set a threshold to trigger protection switch. During the
> trouble shooting, operators need tools to do fault localization. Althought
> "degrade" is a continous variable behaviour, it is a "0/1" problem after
> defining the threshold.
> Thank you!
>
>   ------------------------------
>  *发件人：* "Huber, Thomas J." <[email-masked]>
> *收件人：* Eric Osborne (eosborne) <[email-masked]>; "Ryoo, Jeong-dong" <
> [email-masked]>; D'Alessandro Alessandro Gerardo <
> [email-masked]>; "[email-masked]" <[email-masked]>
> *抄送：* "Huub helvoort ([email-masked])" <
> [email-masked]>; "[email-masked]" <
> [email-masked]>
> *发送日期：* 2013年7月23日, 星期二, 3:03 上午
> *主题:* Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear
> thing.  'Degrade' is a continuous variable, as it can be anything from 'a
> little bad' to a 'a whole lot of bad but not quite fail'.
>
> I think this may be a fundamental difference in assumptions.  While it is
> certainly true that degradation of a signal is a continuous variable, in
> the context of protection switching in the transport network, there is a
> particular value of that continuous variable that defines the threshold at
> which the Boolean variable "signal degrade (SD)" becomes true.  It is for
> this reason that Jeong-dong and others are suggesting that it should be
> possible to incorporate the behavior of the SD state into the PSC
> definition without needing to have a precise definition of the mechanism
> for measuring the degradation of a signal.  Whatever the mechanism is, it
> will be converted to the binary SD indication.
>
> Best regards,
> Tom
>
>
> subject of the equipment Recommendations'.  I'm looking for something like
> "Signal Degrade is defined as $foo packet loss or CRC failure over $bar
> time"....what have I missed?
>
>
> EO#  I am not aware of any document which suggests that a server layer SD
> should be treated as a client layer SD.  In the IP world, if we have SD on
> a transport interface that is generally used to bring the interface down
> (i.e. SF).  This is the sort of thing I'd like to see in more detail, as SD
> in the packet world is a new concept and we can't just assume that it will
> work the same everywhere because we define state machine points for it.
>
> The point about CCM is a good one.  Let's say we come up with a clever SD
> mechanism with two thresholds, call them major and minor.  For discussion
> purposes they could be simple error ratios, e.g. 1:10^6 and 1:10^9.  But
> they could be more powerful than that (flow type, flow length, error burst
> size, etc).
>
> I'm not sure what that would look like.  'Fail' is a pretty binary thing.
> 'Degrade' is a continuous variable, as it can be anything from 'a little
> bad' to a 'a whole lot of bad but not quite fail'.
>

-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*

---

From: Yaacov Weingarten <[email-masked]>
Date: Wed, 24 Jul 2013 11:05:44 +0300

Alessandro, hi

I guess I was not very clear in my presentation - my point had very little
to do with how to detect or measure SD but rather with what is the purpose
of performing a protection switch.

My understanding of the purpose is to guarantee a certain quality of
service.  Therefore, in the case of SF you switch to the protection path
that is working to continue the service.  The question in the SD case is
(and was back when it was first discussed) - how do I know that the
protection path will give a better quality of service when I switch over?
Could I be switching to a path that is providing lower quality? And if so,
why am I performing the switchover?

Hope this clarifies,
yaacov

On Wed, Jul 24, 2013 at 10:11 AM, D'Alessandro Alessandro Gerardo <
[email-masked]> wrote:

>  Dear Yacov,
> I understand your points but we are again moving the discussion to the
> problems in defining sd and the method to detect sd neglecting the costs
> that carriers have to face with in introducing such functionality later on
> in the network.
> Best regards
> Alessandro
>
>
> Inviato da Samsung Mobile
>
>
>
> -------- Messaggio originale --------
> Oggetto:Re: [mpls] 回复： proposed drafts for aligning MPLS-TP PSC linear
> Da:Yaacov Weingarten <[email-masked]>
> A:"[email-masked]" <[email-masked]>
> Cc:"Eric Osborne (eosborne)" <[email-masked]>,"Ryoo, Jeong-dong" <
> [email-masked]>,D'Alessandro Alessandro Gerardo <
> [email-masked]>,"Huub helvoort (
> [email-masked])" <[email-masked]>
>
>
>
>  Hi all,
>
>>  I agree with Tom and Jeong-dong. There are different reasons to cause
>> SD, but the result is the transport performance degrade and it is important
>> to let operators set a threshold to trigger protection switch. During the
>     Questo messaggio e i suoi allegati sono indirizzati esclusivamente
> alle persone indicate. La diffusione, copia o qualsiasi altra azione
> *This e-mail and any attachments** is **confidential and may contain
> privileged information intended for the addressee(s) only. Dissemination,
> copying, printing or use by anybody else is unauthorised. If you are not
> the intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks.*
> *Rispetta l'ambiente. Non stampare questa
> mail se non è necessario.*
>
>

-- 
Thanx and BR,
yaacov

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Wed, 24 Jul 2013 08:07:03 +0000

Yaacov, how are you?

I understand your technical concerns on the SD situation on the working path while the protection path is in fact worse.
I am not trying to resolve the issue here, but what we can have is that any entity or function that detects SD and signals the SD event to PSC process can transform the continuous SD values on both working and transport paths into a binary decision, and signals the result to PSC process. For example, if SD on working is worse than SD on protection, it can only send SD-W to PSC process.
Also, we need to duplicate the traffic to both paths in this case, so that both paths can be monitored with the same traffic condition.
However, this hasty and clumsy idea of mine is outside the scope of protection switching.

Best regards,

Jeong-dong

________________________________
From : "Yaacov Weingarten" <[email-masked]>
Sent : 2013-07-24 14:20:40 ( +09:00 )
To : [email-masked] <[email-masked]>
Cc : Eric Osborne (eosborne) <[email-masked]>, Ryoo, Jeong-dong <[email-masked]>, D'Alessandro Alessandro Gerardo <[email-masked]>, Huub helvoort ([email-masked]) <[email-masked]>
Subject : Re: [mpls] 回复： proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements

Hi all,

While I personally support the idea of including the SD support in the Linear Protection protocol, if only for compatibility with other comparable tools, I feel there is a need to add the context that caused it to be "downgraded" to place-holder status in PSC.

In the original draft versions of the PSC definition, we included SD messages and described the switching operation when the system triggered an SD situation. On the assumption that there would be a way to detect some kind of SD. There were even some drafts that were proposed by different members on how to define SD and detect it for MPLS. None of these latter drafts were, however, accepted by the WG based upon the belief that SD is not relevant at the MPLS level, it is more a system-layer or physical layer issue and should be solved by those layers.

In addition, regarding the idea of switching the traffic from the working to the protection path based on an SD situation on the working path was frowned upon. This was based on the question of how do we assure that the protection path is a better medium for the packet transport. Because even if you could measure and identify an SD situation on the working path, there is no way to measure it on the protection path, since it is most probably affected by the load factors involved in the packet sizes.  Therefore, you are switching to a path that, at least in theory, could be a worse choice!

This was the reasoning behind the downgrade of the SD signal and the note that this is for further study.  I have not seen anyone in this discussion address this issue, and therefore I think it is important that we hear some justification for switching away from a working path to one that we have no better information on! I think that the justifications given until now - i.e. "this is the way it has always been done in physical layer systems" - are not sufficient to add functionality that may cause poorer performance!

On Wed, Jul 24, 2013 at 4:46 AM, Larry <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

*************************************************************************
Han Li, Ph.D
China Mobile Research Institute
32 Xuanwumen West Street, Xicheng District, Beijing 100053, China
Fax: +86 10 63135159<tel:%2B86%2010%2063135159>
MOBILE: 13501093385
*************************************************************************
________________________________
发件人： "Huber, Thomas J." <[email-masked]<mailto:[email-masked]>>
收件人： Eric Osborne (eosborne) <[email-masked]<mailto:[email-masked]>>; "Ryoo, Jeong-dong" <[email-masked]<mailto:[email-masked]>>; D'Alessandro Alessandro Gerardo <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
抄送： "Huub helvoort ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
发送日期： 2013年7月23日, 星期二, 3:03 上午
主题: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements

Hi Eric,

Best regards,
Tom

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Osborne (eosborne)
Sent: Monday, July 22, 2013 8:36 AM
To: Ryoo, Jeong-dong; D'Alessandro Alessandro Gerardo; [email-masked]<mailto:[email-masked]>
Cc: Huub helvoort ([email-masked]<mailto:[email-masked]>); [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements

Hi Jeong-dong,

> From: Ryoo, Jeong-dong [mailto:[email-masked]<mailto:[email-masked]>]

...

LO
FS
SF-P
SD-P-Major
MS
SD-P-Minor

EO#

eric

> From : "Eric Osborne (eosborne)" <[email-masked]<mailto:[email-masked]>> Sent :
> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>> Cc : Huub helvoort ([email-masked]<mailto:[email-masked]>)
> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>> Subject : Re: [mpls] proposed drafts for
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of
> > Cc: Huub helvoort ([email-masked]<mailto:[email-masked]>);
> > [email-masked]<mailto:[email-masked]>

--
Thanx and BR,
yaacov

Still looking for new opportunity

---

From: [email-masked]
Date: Wed, 24 Jul 2013 11:14:25 -0400

Hi all,

I agree for the reasons stated by Tom, Jeong-dong and Han, also this 
approach aligns the behaviour of MPL:S-TP linear protection with the 
behaviour of other (SDH, OTN, Ethernet) linear protection switching 
already deployed in the network.  As stated in some previous liaison 
statements from the ITU alignment with existing APS schemes is a key 
objective.

Regards,

Malcolm

Larry <[email-masked]> 
Sent by: [email-masked]
23/07/2013 09:46 PM
Please respond to
Larry <[email-masked]>

To
"Huber, Thomas J." <[email-masked]>, "Eric Osborne \(eosborne\)" 
<[email-masked]>, "Ryoo, Jeong-dong" <[email-masked]>, D'Alessandro 
Alessandro Gerardo <[email-masked]>, 
"[email-masked]" <[email-masked]>
cc
"Huub helvoort \([email-masked]\)" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>
Subject
[mpls] 回复：  proposed drafts for aligning MPLS-TP PSC linear protection 
protocol to transport requirements

Hi all,

*************************************************************************
Han Li, Ph.D 
China Mobile Research Institute
32 Xuanwumen West Street, Xicheng District, Beijing 100053, China 
Fax: +86 10 63135159 
MOBILE: 13501093385 
*************************************************************************
发件人： "Huber, Thomas J." <[email-masked]>
收件人： Eric Osborne (eosborne) <[email-masked]>; "Ryoo, Jeong-dong" 
<[email-masked]>; D'Alessandro Alessandro Gerardo 
<[email-masked]>; "[email-masked]" <[email-masked]> 

抄送： "Huub helvoort ([email-masked])" 
<[email-masked]>; "[email-masked]" 
<[email-masked]> 
发送日期： 2013年7月23日, 星期二, 3:03 上午
主题: Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear 
protection protocol to transport requirements

Hi Eric,

Best regards,
Tom

-----Original Message-----

Hi Jeong-dong,

...

EO#  I am not aware of any document which suggests that a server layer SD 
should be treated as a client layer SD.  In the IP world, if we have SD on 
a transport interface that is generally used to bring the interface down 
(i.e. SF).  This is the sort of thing I'd like to see in more detail, as 
SD in the packet world is a new concept and we can't just assume that it 
will work the same everywhere because we define state machine points for 
it.

LO
FS
SF-P
SD-P-Major
MS
SD-P-Minor

EO#

> for protection switching. So and so forth.

EO#  AIS from the server layer only gets you SD from the first hop of the 
underlying server path.

eric

---

From: [email-masked]
Date: Wed, 24 Jul 2013 11:22:33 -0400

Hi all,

I agree with the points raised by Huub. One further consideration, in a 
typical network without the exerciser the APS will essentially sit in an 
idle state sending "keep alive" messages for years, until a fault is 
detected on the working path.  At this time APS must "wake up" and execute 
a switch to protection. The purpose of the exerciser is to verify that the 
APS state machine has not suffered some obscure fault condition which 
otherwise would remain undetected until a second fault occurs.  It is 
these "silent failures" cause service outages.

Regards,

Malcolm

Huub van Helvoort <[email-masked]> 
Sent by: [email-masked]
22/07/2013 07:11 PM
Please respond to
[email-masked]

To
"Eric Osborne (eosborne)" <[email-masked]>
cc
"Huub helvoort \([email-masked]\)" 
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject
Re: [mpls] proposed drafts for aligning MPLS-TP PSC linear protection 
protocol to transport requirements

Hello Eric,

[Huub2] indeed

Regards, Huub.