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

Cavazzoni Carlo <carlo.cavazzoni@telecomitalia.it> Tue, 14 May 2013 15:08 UTC

Return-Path: <carlo.cavazzoni@telecomitalia.it>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6AB21F854E for <mpls@ietfa.amsl.com>; Tue, 14 May 2013 08:08:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.719
X-Spam-Level:
X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+oe8RidJnet for <mpls@ietfa.amsl.com>; Tue, 14 May 2013 08:08:38 -0700 (PDT)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 00BA821F9128 for <mpls@ietf.org>; Tue, 14 May 2013 08:08:34 -0700 (PDT)
Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 14 May 2013 17:08:29 +0200
Received: from GRFMBX703BA020.griffon.local ([10.188.101.13]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Tue, 14 May 2013 17:08:28 +0200
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
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ti-disclaimer: Disclaimer1
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
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 May 2013 15:08:42 -0000

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
+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 Eric Osborne (eosborne)
Sent: mercoledì 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 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
mpls@ietf.org
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.