Subject: Re: [mpls-tp] Comments on draft-ietf-mpls-tp-fault-01

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Jul 2010 08:07:41 -0400

... 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

---

From: "Rafi Ram" <[email-masked]>
Date: Wed, 14 Jul 2010 16:21:12 +0300

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: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 14, 2010 3:08 PM
To: Rafi Ram
Cc: [email-masked]
Subject: Re: [mpls-tp] Comments on draft-ietf-mpls-tp-fault-01 

"Rafi Ram" writes:

but is still very low.  

FEC errors show up.

in OAM would not.

Curtis