Re: [mpls-tp] Comments on draft-ietf-mpls-tp-fault-01
"Rafi Ram" <RafiR@orckit.com> Wed, 14 July 2010 13:21 UTC
Return-Path: <RafiR@orckit.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id 64D013A6934 for <mpls-tp@core3.amsl.com>;
Wed, 14 Jul 2010 06:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.795
X-Spam-Level:
X-Spam-Status: No, score=-0.795 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, LONGWORDS=1.803]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uCNYtYB4XkV for
<mpls-tp@core3.amsl.com>; Wed, 14 Jul 2010 06:21:11 -0700 (PDT)
Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by
core3.amsl.com (Postfix) with ESMTP id B47D43A6877 for <mpls-tp@ietf.org>;
Wed, 14 Jul 2010 06:21:10 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01CB2357.71AEFA74"
Date: Wed, 14 Jul 2010 16:21:12 +0300
Message-ID: <45A67426326F814AAC27DBEC3FC7EEC20385A6B0@tlvmail1>
In-reply-to: <201007141207.o6EC7fpe041698@harbor.orleans.occnc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mpls-tp] Comments on draft-ietf-mpls-tp-fault-01
Thread-Index: AcsjTSxcfQ/k9pfhQlqCBEOB4jQtowAB1SKg
References: Your message of "Thu, 24 Jun 2010 11:45:02 +0300."
<45A67426326F814AAC27DBEC3FC7EEC2037F0D30@tlvmail1>
<201007141207.o6EC7fpe041698@harbor.orleans.occnc.com>
From: "Rafi Ram" <RafiR@orckit.com>
To: <curtis@occnc.com>
Cc: ms-daikoku@kddi.com, mpls-tp@ietf.org
Subject: Re: [mpls-tp] Comments on draft-ietf-mpls-tp-fault-01
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>,
<mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>,
<mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jul 2010 13:21:18 -0000
Dear Curtis, Thank you for your detailed answer. SD detection based on CRC is problematic due to the difficulty in determining the threshold since it heavily depends on traffic frame length and rate. With that respect, I would like to suggest reviewing http://tools.ietf.org/html/draft-rkhd-mpls-tp-sd-00.html as proposal for SD detection guide lines. The reaction to link congestion indication is vendor specific, and could be based on dynamic excess traffic shaping. Similar congestion handling techniques which avoid oscillations are specific in IEEE 802.17. Carriers prefer to have the packet transport network provide survivability functionalities similar to ones available in traditional circuit based deployments. In SONET/SDH networks, an SD condition triggers automatic protection switching without requiring operator manual intervention. I agree that the main motivation is SD condition notification for APS triggering, while "Link is congested" and "Link rate is reduced" are "nice to have" features. Best regards, Rafi -----Original Message----- From: curtis@occnc.com [mailto:curtis@occnc.com] Sent: Wednesday, July 14, 2010 3:08 PM To: Rafi Ram Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Comments on draft-ietf-mpls-tp-fault-01 ... sorry, responding to old mail but saw no other response. In message <45A67426326F814AAC27DBEC3FC7EEC2037F0D30@tlvmail1> "Rafi Ram" writes: > > I would like to propose addition of a new message type "Link Condition > Indication" (LCI). > > The LCI message can have the following impairment flags (in the spirit > of draft-dunbar-so-mpls-detect-impair-mplsping-01 > <http://tools.ietf.org/html/draft-dunbar-so-mpls-detect-impair-mplsping- > 01.txt> ) : > > (1) Link performance is reduced (i.e. signal degraded) A low rate of correctable FEC errors is normal in ULH. Sometimes action can be taken when the rate of correctable FEC errors reaches a threshhold, or the rate of uncorrectable FEC errors becomes non-zero but is still very low. Because FEC can reduce bit error rate by 2-3 orders of magnitude, there are plenty of correctable FEC errors long before uncorrectable FEC errors show up. It is CRC bases FCS that are uncorrectable right from the first error. These are more typically seen in metro situations, such as 10km-40km Ethernet over WDM rather than in LH where OTN FEC is used. > (2) Link is congested Can cause oscillation. Traffic moves elsewhere. Congestion moves elsewhere. Traffic moves back. Repeat forever. Traffic degredation is made much worse. Therefore this "Link is congested" either should *NOT* be provided or should be reported but not acted on. > (3) Link rate is reduced > > A possible motivation for this message may be based on signal degrade > detection at LSR (e.g. based on SONET/SDH/OTN link FEC indications), and > relay of this condition to the LSP protection state machine (APS). The usual way to handle this is to set thresholds on FEC errors and either record errors for NMS to pick up, raise alarms, or declare the link down, according to operator preference. Link rate reduction is handled today through preemption, preferably soft-preemption, and a change in the advertised reservable bandwidth (the second requires that a control plane is used). If preemption alone is used, protection resources could be used. Preemption allows the reaction to "reduced rate" to be appropriately sized to the reduction in rate, where just reporting a rate reduction in OAM would not. > Using the existing LDI message for conveying SD may have the following > drawbacks : > > 1. It does not allow the flexibility to report of various impairment > conditions > > 2. Need to differentiate between "link down" condition (equivalent to > SF) and "link reduced" (equivalent to SD), since for APS state machine > SF has higher priority than SD > > Best regards, > > Rafi If anything, this leaves only your indication #1, which could simply be encoded as "signal degraded" (SD) when a low rate of errors is detected (operator chosen threshhold). An SD path can then be prioritized over a fault. Curtis