Subject: [mpls] I-D Action: draft-ietf-mpls-tp-fault-06.txt

From: [email-masked]
Date: Mon, 15 Aug 2011 12:02:21 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title           : MPLS Fault Management OAM
	Author(s)       : George Swallow
                          Annamaria Fulignoli
                          Martin Vigoureux
                          Sami Boutros
                          David Ward
	Filename        : draft-ietf-mpls-tp-fault-06.txt
	Pages           : 16
	Date            : 2011-08-15

   This draft specifies OAM messages to indicate service disruptive
   conditions for MPLS based Transport Network Label Switched Paths
   (LSPs).  The notification mechanism employs a generic method for a
   service disruptive condition to be communicated to a Maintenance End
   Point (MEP).  An MPLS Operation, Administration, and Maintenance
   (OAM) channel is defined along with messages to communicate various
   types of service disruptive conditions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-fault-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-fault-06.txt

---

From: Maarten vissers <[email-masked]>
Date: Thu, 18 Aug 2011 09:35:45 +0000

My comment on the use of the terms Fault and Defect in version -05: 
---------------
   1.  Defect: the situation in which the density of anomalies has
       reached a level where the ability to perform a required function
       has been interrupted.
<..>
   Within the Defect class, a further category, Fault is identified.  A
   fault is the inability of a function to perform a required action.  A
   fault is a persistent defect.
-----------------
has resulted in a swapping of the terms Fault and Defect in version -06:
-----------------
   1.  Fault: the situation in which the density of anomalies has
       reached a level where the ability to perform a required function
       has been interrupted.
<..>
   Within the Fault class, a further category, Defect is identified.  A
   defect is the inability of a function to perform a required action.
   A defect is a persistent fault.
-----------------

It was not my intention to simply see these two terms being swapped. I suggested to introduce a third term (which is not present today in G.806), so that we would get the following three terms: 
- Fault
- Defect
- Fatal Defect

Most likely my original comment has been lacking some examples to illustrate what a Fault is in terms of G.806. A Fault represents a problem in the network. Some examples of Faults are: 
1) a broken fiber, 
2) a removed matrix connection, 
3) a wrong matrix connection, 
4) a failed optical transmitter which does not generate light, 
5) an optical transmitter which operates at e.g. 10% of its required optical power, 
6) a dirty optical connector which causes too much optical attenuation. 

To detect the presence of a Fault, transport equipment is equipped with 'Defect detectors'. You find those Defect detector processes illustrated in Figures 6-1 an 6-2 of G.806 http://www.itu.int/rec/T-REC-G.806/en and in the atomic function figures in G.798, G.8021, G.8121. 

Faults number 1 and 4 result in of loss of optical power and detection of a LOS defect. 
Fault number 2 results in either loss of optical power (OCh layer) and detection of LOS defect, or the loss of frames/packets or presence of frames with a default value and detection of LOC/UNEQ/OCI defect (depending on the technology).
Fault number 3 results in delivering frames/packets to the wrong destination and detection of TIM/MMG defect (depending on the technology).
Faults number 5,6 result in reduction of optical power, mistakes in the recovery of the '0' and '1' bit values and detection of DEG defect.

Figures 6-1 and 6-2/G.806 also illustrate that the output of those Defect detector processes control the Consequent Actions (AIS, RDI, TSF, TSD, SSF generation).

At the moment the L-flag is unknown in the G.806 fault management process and will have to be added. To add the L-Flag consequent action (e.g. as 'aLDI') it will be necessary to introduce an additional state 'aLDI' in the process for each client connection. This additional state 'aLDI' controls the setting of the L-flag in the AIS message. If 'aLDI' is set, the L-flag is set to '1' in each generated AIS message. If 'aLDI' is cleared, the L-flag is set to '0' in each generated AIS message.

'aLDI' is cleared ('0') if:
- the connection (LSP, PW) is either a working or protection connection and neither working or protection connection is in a Signal Fail condition and external commands are not preventing the protection switch to perform a switch
- the connection (LSP, PW) is unprotected in this node and is possibly protected in an upstream node and there has not been a signal fail condition for some time T1; default value for T1 is 100 ms

'aLDI' is set ('1') if:
- the unprotected connection (LSP, PW) is in a signal fail condition for some time T2; default value for T2 is 100 ms (i.e. either no upstream protection present, or upstream protection failed)
- the working [protection] connection (LSP, PW) is in a signal fail condition for some time T3 and the protection switch process did not select the traffic from the protection [working] connection (i.e. protection failed); default value for T3 is 100 ms
- the protection switch process is forced into selecting traffic from working or protection connection (i.e. unable to protect a future fault)
- the protection switch process is selecting traffic from working [protection] due to the presence of a signal fail condition on protection [working] (i.e. unable to protect a second fault)

I will present enhanced text in a separate email to limit the size of this email.

Regards,
Maarten

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 15 August 2011 21:02
> To: [email-masked]
> Cc: [email-masked]
> Subject: [mpls] I-D Action: draft-ietf-mpls-tp-fault-06.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Multiprotocol Label
> Switching Working Group of the IETF.
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls