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