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