Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00

["Ryoo, Jeong-dong" <[e-mail]>]

Pablo,

FS command is usually issued before a network operator performs any network maintenance jobs for the working path, such as replacing a cable, any components of a switch, or the switch itself on the working path. After the maintenance job, the traffic can go back to the working path and protection domain can return to normal by the network operator's clear command.

If MS is issued and a cable is pulled off, then SF-W will occur.
Now, this SF-W will be the top priority request on the protection domain and will dominate any following protection actions, such as running WTR timer, traffic reversion after WTR timer exprires, or entering DNR, etc.

MS and FS are different regardless of SD.

Best regards,

Jeong-dong





________________________________
From : "Pablo Frank" <[e-mail]>
Sent : 2013-05-17 22:52:32 ( +09:00 )
To : Cavazzoni Carlo <[e-mail]>
Cc : [e-mail] <[e-mail]>
Subject : Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00

Hi Carlo,

Why wouldn't the network operator in your example use a manual switch to protection instead of a forced switch?  It gives exactly the desired behaviour for your scenario, does it not?

Consider this counter-example to your scenario:  what if the maintenance activity that is occurring on the working path is *not* complete?  Suppose that the working path is technically up but the maintenance team is running a long-term service activation test that can take several hours.  From the perspective of BFD and PSC, the working path is 'up' but from the operator's perspective, it's not ready for use (they're still testing and stressing the new transport path).  A SF-P suddenly pushing the traffic back to the path that is under test may be undesirable and in the worst case, could cause problems for other transport paths especially in a packet-switched network.  We're now pretty clearly in the murky world of double failures and I imagine different operators have different policies for how they want to handle this.  I can see why Eric claims that some operators have asked for this change.

One of the things that troubles me about making the proposed change in priority is that we end up with no practicable difference between FS-P and MS-P.  If I refer back to G.8031, one of the differences between FS-P and MS-P is that MS-P will be overridden by a Signal Degrade but FS-P will not.  There seems to be a strong sense on the list that SD is not a meaningful condition that we can define for packet switched networks.  So assuming that holds and we make this change, we'll end up with literally no difference in behaviour between FS-P and MS-P.

I understand the implications that the ITU-T has pointed out that a FS could lead to a broken network but so could Lockout-of-Protection.  It seems to me that in either case of LO or FS, you've made a conscious choice to run unprotected for some period of time.  So buyer beware.  If that was not your intent, then use MS.  Am I missing something here?

regards,
Pablo


On Tue, May 14, 2013 at 11:08 AM, Cavazzoni Carlo <[e-mail]<mailto:[e-mail]>> wrote:
Eric,

in order to clarify, from a network operator point of view, why I think the SF-P must have higher priority than the FS-P I would make the following simple practical example.

For the execution of a programmed maintenance activity on one or more sections of a MPLS-TP ring, all the connections routed on those sections have been moved to the protection paths with a FS-P command for a defined maintenance window timeframe. The maintenance work is typically done by a team different from that managing the MPLS-TP network: let's imagine maintenance people complete the work well in advance with respect to the planned maintenance window.
Unfortunately a failure (SF-P) happens before the end of the planned maintenance window timeframe, what happens?

a)      If SF-P has higher priority than FS-P then PSC moves the traffic back to the working path so recovering the connectivity in a short protection switching time;
b)      If FS-P has higher priority than SF-P then the traffic remains on the broken connection and it will continue to be lost even when the working  path is up and running (i.e. at the latest at the end of the planned maintenance window): it seems that only a manual (and slow) reconfiguration of both protection endpoints from the management system could recover the normal working state.

Why do we have to define case b) as the standard behavior?
Are there use cases that suggest case b) as the preferred choice?

Hope this can help.

Regards,

Carlo

------------------------------------------------------------------
Telecom Italia
Carlo Cavazzoni
Transport Innovation
Via G. Reiss Romoli, 274 10148 Torino
[phone]<tel:%2B39%20011%202285732>
[phone]<tel:%2B39%20335%207854045>
Fax: [phone]<tel:%2B39%2006%2091861099>
[e-mail]<mailto:[e-mail]>


-----Original Message-----
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Eric Osborne (eosborne)
Sent: mercoledì 17 aprile 2013 14:16
To: [e-mail]<mailto:[e-mail]>
Subject: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00

This thread is for discussing draft-rhd-mpls-tp-psc-priority-00.  In brief, the draft proposes swapping the priorities between FS and SF-P (see section 4.3.2 of rfc6378).  This proposed swap has a long history, dating back to when PSC was an ID.  For some history, see

http://datatracker.ietf.org/liaison/1229/
and
http://datatracker.ietf.org/liaison/1234/

The questions that I think are relevant here are:

- is it appropriate to make this priority swap?
  - are there alternative approaches?
  - what do we need to change?  rfc5654?  rfc4427?
- if we don't make the change, does this expose implementation to problems?
- if we do make the change, how do we go about it?

but of course any and all discussion is welcome.

As with the other threads I'm going to leave my two cents out of this introductory email but I'll chime in when discussion starts.





eric
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls

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.

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