IETF Logo Mail Archive

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

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Sun, 21 April 2013 15:45 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
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 3F3A321F8D6A for <mpls@ietfa.amsl.com>; Sun, 21 Apr 2013 08:45:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level:
X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, UNPARSEABLE_RELAY=0.001]
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 AI5pw8hAakjz for <mpls@ietfa.amsl.com>; Sun, 21 Apr 2013 08:45:43 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.152]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0C621F8C1A for <mpls@ietf.org>; Sun, 21 Apr 2013 08:45:40 -0700 (PDT)
Received: from [85.158.139.211:63290] by server-16.bemta-5.messagelabs.com id 2C/0F-02543-89904715; Sun, 21 Apr 2013 15:45:28 +0000
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1366559127!19460713!2
X-Originating-IP: [147.234.242.234]
X-StarScan-Received:
X-StarScan-Version: 6.8.6.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27442 invoked from network); 21 Apr 2013 15:45:28 -0000
Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Apr 2013 15:45:28 -0000
X-AuditID: 93eaf2e7-b7f2e6d000002815-9f-51740996ed48
Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 7C.30.10261.69904715; Sun, 21 Apr 2013 18:45:27 +0300 (IDT)
Received: from ILPTWPVEXCA01.ecitele.com (172.31.244.224) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Sun, 21 Apr 2013 18:45:26 +0300
Received: from ILPTWPVEXMB02.ecitele.com ([fe80::5979:ca8d:419f:56df]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.02.0328.009; Sun, 21 Apr 2013 18:45:26 +0300
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "Eric Osborne (eosborne)" <eosborne@cisco.com>
Thread-Topic: PSC: draft-rhd-mpls-tp-psc-sd-00
Thread-Index: Ac47ZjCR0vbHo3uJROyqNlG6qZXPnwDP/26g
Date: Sun, 21 Apr 2013 15:45:25 +0000
Message-ID: <F9336571731ADE42A5397FC831CEAA0212303FA6@ILPTWPVEXMB02.ecitele.com>
References: <20ECF67871905846A80F77F8F4A27572101502B9@xmb-rcd-x09.cisco.com>
In-Reply-To: <20ECF67871905846A80F77F8F4A27572101502B9@xmb-rcd-x09.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.4.33.32]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA3VTbUgUURTl7azrrDn6WjXfLlHjWCtka24WGLUWhKiQpRQU9aOm3dfu1O7s tDNaRj+UMMigEtlSqaywMhUqDVIrNu1TpQ8qsaQySAo/IFujMrKacdSEaH6d+85559x53EsS hqJQE8nxEvbxrJvRhWnLBoJfLCf0Um7y7UEytef8pZBVILO6elSTAzYXghUsz3slVsK0A4t2 G5Pj4/JZewFDcw4bY2Vowc3asQfzko1hBQHzDiYtjP7nWyHLOJ7GvN3r4Hinjclav86Smrp0 mcXKpJnjrSnLwza4OJHGFg/LuWkPFkXWiWn5ZNs1wnX8WDsQOiP3fhvuJwpBU3gJ0JMILkGf x66GqngWevr2sq4EhJEGGADo5J06oBZNAI09eDZR3APoUOcHoFzRQRtqqHujU3A0XIyOXg9o FBEBuwEKPvipUYgomIRayt5rVdEi9LrmEZi8cLrzZkgJIEktnI9etBqVYwrmoIP3i8flBrgG 1dceGPfXw2zU2/p7HAO51W8d9eP2BIxFPX1VGvUXIKq++YRQcQzqf/8rRMVzUN9dP6HqF6Iz N4I6FSeiC2cHCTV3Jmqv6JvItaCOhyUTnkbUWvNSewwYK6fFVU6zqpxmVTnN6gzQ1oIYzi1I 2z3OZGsStnMSduMku9fTANSZ+dgEflTNawOQBEw4JXz35RpC2HyxwNMGjKSGiaHEUCnXELHd 6yhwsaJrqy/PjcU2gEiCiabW6GSOcrAF+7DPO0mly49ZSphm2L3ydPLS1pTk5P8XTCx1sXDj OgN0yrO5C2MB+yZ9ZpMkgyg/KUfM9GEn3ruDc0t/aQ2pV9oIl9uoUzSUKLAekXOqfAewkDWN /YPAoOW9PDbFUg2KCCoiVx4/5TO5OQMgVn6AKKpRUYXLezXlNCCHaOSQkRm7lRB5h6YoUyFo ZzKKzK/K1z5Oyx7TV+QOPYV9zUdPsXFF77Z83RSZ3hsMBs75/c3mjIquw/tLXS1XyRpvy/Py H/GfupqWb2se3Xdg+G7WhcY497XMK4Q5kHg9ISLTPLpzXs+etpHAo+fG2o/dWfTi4nO3hlI7 VjbvF4L+6N6E1W8WHEmYa4KjYxsYrehirQsIn8j+AZ8n7bYUBAAA
Cc: "mpls@ietf.org" <mpls@ietf.org>, Shell Nakash <Shell.Nakash@ecitele.com>, Gideon Agmon <Gideon.Agmon@ecitele.com>
Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-sd-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: Sun, 21 Apr 2013 15:45:44 -0000

Eric, and all,
The issue has been discussed actively in the past.

I can only re-state my position during these discussions, namely that there is no way to define a reasonable analog of Signal Degrade (SD) in MPLS and, by implication, in the MPLS-TP data plane. By "reasonable" here I mean a method that does not depend on the actual traffic going thru the LSP.

The fact that we could not reach any consensus for such a definition in the past is not, of course, a mathematical proof of non-existence of SD.
But it is a good indication of a fundamental problem IMO.

As a consequence, IMHO and FWIW, there is no need in defining SD-related state transitions, behavior etc.

My 2c,
     Sasha

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eric
> Osborne (eosborne)
> Sent: Wednesday, April 17, 2013 3:26 PM
> To: mpls@ietf.org
> Subject: [mpls] PSC: draft-rhd-mpls-tp-psc-sd-00
> 
> This thread is for discussing draft-rhd-mpls-tp-psc-sd-00.  The draft provided
> 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.  There are
> some expired drafts that touch on the definition and use of SD, including:
> 
> draft-zhl-mpls-tp-sd-03
> draft-rkhd-mpls-tp-sd-03
> 
> (this is not an exhaustive list.  It's the top two google hits.)
> 
> 
> The questions I think are relevant are:
> 
> - do we need an SD mechanism in MPLS-TP?
> - if so, is it reasonable to define state transitions for it before we have defined
> SD itself?
> - if yes to both of the above, does this draft provide the right behavior?  Are
> there alternative approaches?
> 
> but of course any and all discussion is welcome.
> 
> 
> 
> eric
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls


This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

v2.28.0 | Report a Bug | By Email | System Status