Re: [mpls-tp] Comments on draft-ietf-mpls-tp-fault-01
Curtis Villamizar <curtis@occnc.com> Wed, 14 July 2010 12:07 UTC
Return-Path: <curtis@occnc.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 A90AA3A6980 for <mpls-tp@core3.amsl.com>;
Wed, 14 Jul 2010 05:07:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.055
X-Spam-Level:
X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=-1.056,
BAYES_50=0.001]
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 RRsQkYZxNy4j for
<mpls-tp@core3.amsl.com>; Wed, 14 Jul 2010 05:07:34 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com
[173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 7CC043A6825 for
<mpls-tp@ietf.org>; Wed, 14 Jul 2010 05:07:34 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com
[173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id
o6EC7fpe041698; Wed, 14 Jul 2010 08:07:42 -0400 (EDT) (envelope-from
curtis@harbor.orleans.occnc.com)
Message-Id: <201007141207.o6EC7fpe041698@harbor.orleans.occnc.com>
To: "Rafi Ram" <RafiR@orckit.com>
From: Curtis Villamizar <curtis@occnc.com>
In-reply-to: Your message of "Thu, 24 Jun 2010 11:45:02 +0300."
<45A67426326F814AAC27DBEC3FC7EEC2037F0D30@tlvmail1>
Date: Wed, 14 Jul 2010 08:07:41 -0400
Sender: curtis@occnc.com
Cc: 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
Reply-To: curtis@occnc.com
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 12:07:37 -0000
... 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