From: Cavazzoni Carlo <carlo.cavazzoni@telecomitalia.it>
To: "Eric Osborne (eosborne)" <eosborne@cisco.com>,
 "mpls@ietf.org" <mpls@ietf.org>
Date: Tue, 14 May 2013 17:08:27 +0200
Thread-Topic: PSC: draft-rhd-mpls-tp-psc-priority-00
Thread-Index: Ac47ZD1tB/jb+CaKQqOehjxMIOgzIgVT6XFA
Message-ID: <05540BD841BBD643BB51404C4C9171521518059A97@GRFMBX703BA020.griffon.local>
References: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com>
In-Reply-To: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00
Precedence: list

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 si=
mple practical example.

For the execution of a programmed maintenance activity on one or more secti=
ons of a MPLS-TP ring, all the connections routed on those sections have be=
en moved to the protection paths with a FS-P command for a defined maintena=
nce window timeframe. The maintenance work is typically done by a team diff=
erent from that managing the MPLS-TP network: let's imagine maintenance peo=
ple complete the work well in advance with respect to the planned maintenan=
ce window.
Unfortunately a failure (SF-P) happens before the end of the planned mainte=
nance window timeframe, what happens?

a)      If SF-P has higher priority than FS-P then PSC moves the traffic ba=
ck 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 t=
he 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 maint=
enance window): it seems that only a manual (and slow) reconfiguration of b=
oth protection endpoints from the management system could recover the norma=
l 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
+39 011 2285732
+39 335 7854045
Fax: +39 06 91861099
carlo.cavazzoni@telecomitalia.it


-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri=
c Osborne (eosborne)
Sent: mercoled=EC 17 aprile 2013 14:16
To: mpls@ietf.org
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 sectio=
n 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 intro=
ductory email but I'll chime in when discussion starts.





eric
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne 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, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.