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

[Pablo Frank <[e-mail]>]

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]> 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]
> [phone]
> Fax: [phone]
> [e-mail]
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Eric Osborne (eosborne)
> Sent: mercoledì 17 aprile 2013 14:16
> To: [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]
> 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]
> https://www.ietf.org/mailman/listinfo/mpls
>