Subject: [Mpls-interop] Local and Remote

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 6 May 2009 13:16:17 +0100

I know that Malcolm and Huub are going to work on the definition of local 
and remote.

Huub usefully typed during the meeting yesterday that "remote" might be 
better stated as "non-local."

Watching some emails this morning, I wonder whether part of the confusion 
arises from
- where the fault is detected
- where the fault exists

A node can (IMHO) only be detected locally. That is local to the point of 
detection.

A fault may be reported (to the management plane) from the node of detection 
(a local report), or may be signaled to another node (through the OAM or 
control plane) and reported (to the management plane) from that other node 
(a remote report).

The fault that is detected may be in the detecting node, or in a resource 
directly connected to that node (such as a link). This is a local fault.

But the fault may also exist in a node or resource that is not local to the 
detecting node. This is a remote fault.

If an LSP continuity check fails, the fault is detected by an end point 
(local detection), but the fault might be somewhere out in the network 
(remote fault).

When a server layer provides a connection that is used as a link in the 
client layer, a server layer fault (that is remote in the server layer) may 
be reported to the client layer as a fault in the client layer link (that is 
local in the client layer). The client layer does not know about the route 
or resources used in the server layer (we MUST assume clean layer 
separation) so the client layer does not need to know about the location of 
the server layer remote fault. If the client layer requests the server layer 
to repair the client layer link (i.e. to repair the server layer connection) 
the server layer may need to consider the location of the server layer 
fault.

Am I wrong?
Is this really so complicated?

Thanks,
Adrian

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 6 May 2009 14:57:31 +0200

Hi,

Thanks for the great clarification.

I am sorry for bothering but I still have some questions:

*         We have a requirement in the document for "Remote Defect
Indication" and it specifies that "The MPLS-TP OAM toolset MUST provide
a function to enable an End Point to notify its associated End Point of
the detection of a fault or defect that it detects on a PW, LSP or
Section between them." I.e. in the requirement refers to remote as to
the associated endpoint at the same layer!

*         I would like to refer to the last paragraph in your e-mail: ""
When a server layer provides a connection that is used as a link in the
client layer, a server layer fault (that is remote in the server layer)
may be reported to the client layer as a fault in the client layer link
(that is local in the client layer)...." Assuming that we have an LSP
that traversed nodes A-B-C-D-E-F-G and we have a fault in the link
between D and E. according to the above the server layer needs to notify
the client layer. Is it to the client layer in nodes D and E or to the
endpoints of the client layers, i.e. nodes A and G? If it is node D and
E (this is local) they need now to notify nodes A and G, but according
to the requirement document and to the framework they may be MIPs of the
LSPs but they cannot initiate OAM messages. Therefore, it seems that the
endpoint of the server layer needs to notify the endpoint of the client
layers of the fault (remote). And IMO we need to be clear about the
requirement. And also to extend the definition in the first bullet for
remote (not necessarily endpoint). 

*         Assuming that the failure is in the first (server) link. As a
result we have loss of continuity in the LSPs that transmit over this
failed link and in the PWs that are attached to these LSPs. As I
understand from your definition, as these fault are detected by the
endpoint (to which the link is attached), all these faults are
considered locals!. Is there still a requirement to distinguish between
these failures? Note that all of these are now local. 

I'll appreciate your further clarification.

Best regards,

Nurit

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Adrian Farrel
Sent: Wednesday, May 06, 2009 3:16 PM
To: [email-masked]
Subject: [Mpls-interop] Local and Remote

I know that Malcolm and Huub are going to work on the definition of
local 

and remote.

Watching some emails this morning, I wonder whether part of the
confusion 

arises from

- where the fault exists

A node can (IMHO) only be detected locally. That is local to the point
of 

detection.

A fault may be reported (to the management plane) from the node of
detection 

control plane) and reported (to the management plane) from that other
node 

(a remote report).

The fault that is detected may be in the detecting node, or in a
resource 

But the fault may also exist in a node or resource that is not local to
the 

(remote fault).

client layer, a server layer fault (that is remote in the server layer)
may 

be reported to the client layer as a fault in the client layer link
(that is 

local in the client layer). The client layer does not know about the
route 

separation) so the client layer does not need to know about the location
of 

the server layer remote fault. If the client layer requests the server
layer 

to repair the client layer link (i.e. to repair the server layer
connection) 

fault.

Am I wrong?

Thanks,

Adrian 

_______________________________________________

Mpls-interop mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 06 May 2009 15:42:50 +0200

Hi Nurit,

> I am sorry for bothering but I still have some questions:

[hvh] OK.

> · We have a requirement in the document for "Remote Defect 
> Indication" and it specifies that "The MPLS-TP OAM toolset MUST 
> provide a function to enable an *End Point to notify its associated 
> End Point* of the detection of a fault or defect that it detects *on 
> a PW, LSP or Section* *between them*." I.e. in the requirement refers
>  to remote as to the associated endpoint *at the same layer*!

[hvh] in the example: A-B=C=D-E-F-G if the sink MEP in node G detects
a service affecting defect it informs the co-located source MEP and
the source MEP in node G transmits RDI towards node A. The RDI is
detected by the sink MEP in node A and will interpret this as node
G has detected a service affecting defect. For the sink MEP in node
A the sink MEP in node G is the */_remote_/*.

> · I would like to refer to the last paragraph in your e-mail: "" When
>  a server layer provides a connection that is used as a link in the 
> client layer, a server layer fault (that is remote in the server 
> layer) may be reported to the client layer *as a fault in the client 
> layer link* (that is local in the client layer)…." Assuming that we 
> have an LSP that traversed nodes A-B-C-D-E-F-G and we have a fault in
>  the link between D and E. according to the above the server layer 
> needs to notify the client layer. Is it to the client layer in nodes 
> D and E or to the endpoints of the client layers, i.e. nodes A and G?
> 
[hvh] you did not indicate where the server layer starts and ends,
I have assumed between D and E.

[hvh] the end points (i.e. the sink MEPs) in A and G have to be
notified. How this is done is a solution.

> If it is node D and E (this is local) they need now to notify nodes A
>  and G,

[hvh] I assume the you mean the link failure is in both directions,
and the server layer is betwen D and E.
In that case E has to inform G for traffic flowing from A to G, and
D has to inform A for traffic flowing from G to A.

> but according to the requirement document and to the framework they
> may be MIPs of the LSPs but they cannot initiate OAM messages.

[hvh] if my assumptions above are right there are (server) MEPs in
D and E.
If my assumptio is wrong and you are referring to s single LSP, a
link fault between D and E will be detected by G: loss of CC without
a notification from a server.

> Therefore, it seems that the endpoint of the server layer needs to 
> notify the endpoint of the client layers of the fault (remote).

[hvh] and how that is achieved is a solution.

> And IMO we need to be clear about the requirement. And also to extend
> the definition in the first bullet for remote (not necessarily
> endpoint).

[hvh] I hope the explanation above makes clear what the purpose
is of RDI and where it is generated.

> · Assuming that the failure is in the first (server) link. As
> a result we have loss of continuity in the LSPs that transmit over 
> this failed link and in the PWs that are attached to these LSPs. As I
> considered locals!. Is there still a requirement to distinguish 
> between these failures? Note that all of these are now local.

[hvh] if the first link (A-B) is a server link, then in A there are
two MEPs: one for the LSP and one for the server trail.
The MEP in the server trail will detect the defect and will inform
the MEP of the LSP, according to the requirement.
For the MEP in the server trail the defect is local, for the MEP in
the LSp the defect is remote.

> I'll appreciate your further clarification.

[hvh] I hope the above helped   ;-)

Kind regards, Huub.

> -----Original Message----- From: [email-masked] 
>  Sent: Wednesday, May 06, 2009 3:16 PM To: [email-masked] 
> ------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________ Mpls-interop mailing 
> list [email-masked] 

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 6 May 2009 16:06:02 +0200

Huub,

<NS> Right. 

<NS> but we have a requirement to notify them! We need to specify this
requirement exactly as we specified RDI. Please refer to my proposal. 

and the server layer is between D and E.

<NS> so as said above we have a requirement to notify the endpoints. As
this "pass on the wire" is should be specified, it is not done by a
magic. The requirement is from the endpoints of the server layer to
notify the endpoint of the clients.....again please refer to my
proposal.

Best regards,

NUrit

 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Huub van
Helvoort
Sent: Wednesday, May 06, 2009 4:43 PM
To: [email-masked]
Subject: Re: [Mpls-interop] Local and Remote

Hi Nurit,

[hvh] OK.

> * I would like to refer to the last paragraph in your e-mail: "" When

> layer link* (that is local in the client layer)...." Assuming that we 

D and E.

> * Assuming that the failure is in the first (server) link. As

Kind regards, Huub.

> Huub usefully typed during the meeting yesterday that "remote" might 

> be

> A node can (IMHO) only be detected locally. That is local to the 

> point of

> (a local report), or may be signaled to another node (through the OAM

>  or

> directly connected to that node (such as a link). This is a local 

> But the fault may also exist in a node or resource that is not local 

> to the

> If an LSP continuity check fails, the fault is detected by an end 

> point

> (local detection), but the fault might be somewhere out in the 

> network

> When a server layer provides a connection that is used as a link in 

> layer) may

> separation) so the client layer does not need to know about the 

> location of

> the server layer remote fault. If the client layer requests the 

> server layer

> the server layer may need to consider the location of the server 

-- 

[email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 6 May 2009 15:18:17 +0100

Hi,

> Indication" and it specifies that "The MPLS-TP OAM toolset
> MUST provide a function to enable an End Point to notify its
> associated End Point of the detection of a fault or defect that
> it detects on a PW, LSP or Section between them." I.e. in the
> requirement refers to remote as to the associated endpoint at
> the same layer!

Why the exclamation point?

The associated end-point at the same layer is certainly not local. Not local 
= remote.

The defect indication comes from somewhere else (not local). That means it 
is a remote indication.

> *  I would like to refer to the last paragraph in your e-mail:
>> When a server layer provides a connection that is used as
>> a link in the client layer, a server layer fault (that is remote
>> in the server layer) may be reported to the client layer as
>> a fault in the client layer link (that is local in the client
>> layer)
> Assuming that we have an LSP that traversed nodes
> A-B-C-D-E-F-G and we have a fault in the link
> between D and E. According to the above the server
> layer needs to notify the client layer.

Well, I said "may," but I agree it would be useful.

> Is it to the client layer in nodes D and E or to the
> endpoints of the client layers, i.e. nodes A and G?

To D and E.
The server layer is only providing connectivity between D and E.
It has (and should have) no knowledge of the client services carried over 
the connection.
As far as the server layer is concerned, it provides a connection from D to 
E.
The client layer decides to use this connection as the link D-E in the 
client layer, and decides to route the LSP AG over that link.

> If it is node D and E (this is local) they need now to notify
> nodes A and G

First question is "why?"

It may help to think of the client layer network as a single layer network 
and resolve the issues there first.

Let us suppose that the fault was in the client layer at node D. How would A 
and G find out about the fault?

Now suppose that the fault is in the client layer link D-E. How would A and 
G find out about the fault?

Now we can come back to your question. The fault is in the server layer 
between D and E. It is reported to D and E. D and E map this to a client 
layer fault on the link D-E. How would A and G find out about the fault?

> but according to the requirement document
> and to the framework they may be MIPs of the
> LSPs but they cannot initiate OAM messages. Therefore, it seems
> that the endpoint of the server layer needs to notify the endpoint
> of the client layers of the fault (remote). And IMO we need to be
> clear about the requirement. And also to extend the definition in
> the first bullet for remote (not necessarily endpoint).

The answer is that the end points of the link (in the client layer) or the 
connection (in the server layer) may be MEPs. When they detect faults they 
raise alarms to their management systems.

When the fault is detected by the end points (as surely it will be) they can 
perform fault localisation to isolate the fault. That is, the MEPs can 
consult the MIPs and (since the MIPs are allowed to respond) determine where 
the fault is.

If, in the opinion of the deployer, the end points of an LSP need to know 
about the location of a fault at detection time (I have serious doubts about 
this) then he can designate every node along the path as a MEP.

> considered locals!

No.
Please read again.

The fault is local if the fault exists in a resource that is local (in the 
layer that is detecting the fault).

In your example, G detects a fault in the LSP, but G does not defect a fault 
in the link FG or at the node G. Therefore the fault is not local.

Still in your example, E detects a fault in the server connection DE (say 
DxyzE).
- If the fault is in E or in the link zE, the fault is local in the server 
layer
- If the fault is not in E or in the link zE, the fault is not local in the 
server layer
In *both* cases, once the fault has been reported to the client layer, the 
fault is local in the client layer (it is a failure of the link DE).

May help you to note that local and remote are relative terms. I.e. "local 
to E" is not the same as "local to G".

> Is there still a requirement to distinguish between

Yes, there is a requirement to distinguish.
No, they are not all local.

I would just like to point out that we are now very far into implementation 
and not standardisation. It is not the job of the IETF (in my personal 
opinion) to tell people how to build boxes.

Thanks,
Adrian

-----Original Message-----

and remote.

confusion arises from

of detection.

(remote fault).

fault.

Am I wrong?

Thanks,

Adrian

[email-masked]

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 6 May 2009 21:03:36 +0200

Hi,

Thanks you Adrian for the great explanation. It really clarifies many of
the issues very well. 

I can agree to your definitions. And it is good to finally have them. 

Please see inline some comments.

The main questions that I have now are as follows:

*         Why do we need to specify in the OAM document a requirement to
distinguish between local and remote faults? Does it require any tool
that is not already required in the document? Does it require any
protocol definition and interoperability between network elements? We
have a requirement to detect loss of continuity (in each layer). We have
a requirement to send indication of a fault detected by the peer. We
have a requirement for connectivity verification, etc. what do we miss? 

*         If we have a requirement to distinguish between remote and
local alarms, don't we need a requirement to distinguish between remote
alarms happen at the same layer network and remote alarms happen at the
server layers? This is actually what is needed if we want the endpoint
of the LSPs for example to have the capability to suppress alarms that
result form a remote defect at the server layer. We would probably not
like to suppress alarms that result at a specific LSP for example as a
result of mis-connectivity in a specific node along the path. Consider
an LSP that transmit over A-B-C-D-E-F-G and there is a failure at the
server link D-E. The endpoints of the server layer are D and E. Consider
that D notifies its client layer of the fault, the fault becomes local
to the client layer at node D. In order to be able suppress alarms at
node A for all LSPs which all LSPs that start at node A and transmit
over the failed server layer, node A needs to identify that this is a
remote failure. But this is not enough to suppress alarms, because maybe
the fault is a result of mis-connectivity and not a failure of the
server layer. Fault localization is required at the same layer and since
the failure is now considered in node D as a local failure also at the
LSP layer (as the server layer notified it about the failure), how can
we distinguish between the cases given the list of functions we require?

Again I am sorry for all these exchanges, but I believe that if we do
not resolve it now, and if we try to "color" the real requirement, we
will get into these discussions in last call when we get comments from
the ITU-T (and I'll not be the one that will issue them)..  

Best regards,

Nurit

-----Original Message-----
From: ext Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, May 06, 2009 5:18 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]
Subject: Re: [Mpls-interop] Local and Remote

Hi,

<NS> Because we call the function REMOTE fault indication but ask for a
notification only for faults that are detected by the peer endpoint at
the same layer. maybe we should change the name of the function to
reflect better the specific functionality that is required. 

The associated end-point at the same layer is certainly not local. Not
local 

= remote.

<NS> Right. But in this case the remote is in the same layer. 

The defect indication comes from somewhere else (not local). That means
it 

is a remote indication.

<NS> Correct

To D and E.

<NS> Right. BUT if you refer to the e-mails from Huub and to the
discussions with Malcolm last night they want the endpoints of the
client (e.g. LSPs, PWs) to identify failures that happened remotely at
the server layer! How can the endpoints know about such failures if
there is no requirement for someone to notify it about such a failure? 

It has (and should have) no knowledge of the client services carried
over 

the connection.

<NS> Correct. This is exactly the problem I am referring (or at least
try to refer to). 

As far as the server layer is concerned, it provides a connection from D
to 

E.

<NS> Correct. 

NS> to be more specific, in transport it is the management station or
the Ingress node which calculate the route and make this decision. 

First question is "why?"

<NS> Because this is the requirement that was written in the revised
document (at least I read it) and that was specified in the mail
exchanges with Huub and Malcolm (at least as I understood it). I do not
remember the exact words but it was something like that the endpoints of
LSP, PW MUST indicate if the fault causing loss of continuity is local
(i.e. within the node containing the end point) or remote. How can the
endpoints know about REMOTE failures if no one notifies them about it? 

It may help to think of the client layer network as a single layer
network 

Let us suppose that the fault was in the client layer at node D. How
would A 

<NS> Exactly. That is the point. If they need to know about it as stated
in the requirement above, then someone needs to notify them about remote
failures. 

Now suppose that the fault is in the client layer link D-E. How would A
and 

<NS> This is exactly the issue I have with the requirement that was
specified in the revised document. If the endpoints of an LSP need to
distinguish between local and remote faults, someone needs to notify
them about it. Otherwise they can not know it. 

> the first bullet for remote (not necessarily endpoint).

The answer is that the end points of the link (in the client layer) or
the 

connection (in the server layer) may be MEPs. When they detect faults
they 

When the fault is detected by the end points (as surely it will be) they
can 

consult the MIPs and (since the MIPs are allowed to respond) determine
where 

the fault is.

<NS> > All this is correct. But in order to understand that this is a
remote failure you do not need to know the location of the fault. You
just need to know that it is a remote failure. In such a case all LSPs
need to consult with their immediate MIPS to understand be able to
distinguish between the faults. 

Why do we need at all to specify a requirement for the endpoints to
distinguish between local and remote failures? Does it require any
interoperation between network elements? 

If, in the opinion of the deployer, the end points of an LSP need to
know 

about the location of a fault at detection time (I have serious doubts
about 

<NS> According to the definition, a MEP is an endpoint of LSP, or PW. If
you designate any node along a path as a MEP you have many concatenated
LSPs.  

No.

Please read again.

The fault is local if the fault exists in a resource that is local (in
the 

<NS> OK. 

In your example, G detects a fault in the LSP, but G does not defect a
fault 

Still in your example, E detects a fault in the server connection DE
(say 

DxyzE).

- If the fault is in E or in the link zE, the fault is local in the
server 

layer

- If the fault is not in E or in the link zE, the fault is not local in
the 

server layer

In *both* cases, once the fault has been reported to the client layer,
the 

<NS> OK

May help you to note that local and remote are relative terms. I.e.
"local 

<NS> Why do we need to specify it in the document? Does it require any
development of a protocol? 

 

I would just like to point out that we are now very far into
implementation 

Thanks,

Adrian

-----Original Message-----

 

local

and remote.

 

confusion arises from

- where the fault exists

of detection.

(a remote report).

 

(remote fault).

may

(that is

route

of

layer

connection)

fault.

Am I wrong?

 

Thanks,

Adrian

 

[email-masked]

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 7 May 2009 11:39:29 -0400

All, first apologies for my behaviour on the MEAD team call on Tuesday,
showing frustration is not an acceptable way of holding a technical
discussion.

Looking at the chain of email I see signs of convergence but no easy way
to simple text.  I saw a comment from Sasha on the network management
requirements draft:

"Section 5.5.2 deals with alarm suppression and defined a MUST
requirement to suppress "superfluous alarms". However, the notion of the
superfluous alarm" is not defined (neither directly in the draft nor by
reference to other sources). Taking into account that there are more
than 50 messages discussing AIS/FDI on this list, it seems that the
superfluosity of an alarm is in the eye of the beholder..."

That triggered a thought that perhaps we have better way to describe the
problem:

Since we have very different backgrounds first some basic definitions:

Fault:  An unintended event that impacts a network.  Examples: hardware
failure; software bug; configuration error.

Defect:  The observed perturbation of a signal. e.g. Loss of CC
messages:  Loss of light (following a cable cut fault).

Primary defect:  The first defect that is observed as the result of a
fault.

Consequential defect:  Any other defect that is caused by the same
fault.

As an example consider a node that has a 40G OTN interface carrying
4xODU2, one ODU2 carrying GFP mapped MPLS-TP LSPs,  some MPLS-TP LSPs
transit a switch/crossconnect function and leave the node; Others
terminate locally on a PW end point. 

If the fiber carrying the 40G signal is cut adjacent to the node:

The primary defect would be Loss of optical signal.  
Loss of OTU frame, loss of ODU, loss of CC messages on the terminated
LSP, loss of CC messages on the terminated PW are all be consequential
defects observed in this "local" node.

At some (remote) node the LSP's and the PW's that transited the node
adjacent to the fiber cut will be terminated.  Assuming no
recovery/repair action has taken place, then a loss of CC defect will be
observed for both the LSP and PW at this (remote) node.  These are
consequential defects.

So perhaps we could (in the OAM requirements document) include a
requirement that states:

It MUST be possible to differentiate between primary and consequential
defects.  The OAM toolkit MUST support mechanisms to support this
differentiation.

Comments:
1) This includes an implicit requirement that defect information is
passed from a server layer to a client layer within a node.
2) The (simple) example about is only to illustrate the concepts, many
other scenarios will need to be analyzed to determine if a proposed
solution adequately addresses the requirement.
3) If we take this approach do we need definitions for fault,
primary/consequential defect.

In the NM requirements we could state:

It MUST be possible to suppress alarms that result from consequential
defects.

Hope this helps.

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, May 06, 2009 10:18 AM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]
Subject: Re: [Mpls-interop] Local and Remote

Hi,

> * We have a requirement in the document for "Remote Defect Indication"

> and it specifies that "The MPLS-TP OAM toolset MUST provide a function

> to enable an End Point to notify its associated End Point of the 
> detection of a fault or defect that it detects on a PW, LSP or Section

> between them." I.e. in the requirement refers to remote as to the 
> associated endpoint at the same layer!

local = remote.

The defect indication comes from somewhere else (not local). That means
it is a remote indication.

>> the client layer, a server layer fault (that is remote in the server 
>> layer) may be reported to the client layer as a fault in the client 
>> layer link (that is local in the client
>> layer)
> Assuming that we have an LSP that traversed nodes A-B-C-D-E-F-G and we

> have a fault in the link between D and E. According to the above the 
> server layer needs to notify the client layer.

> Is it to the client layer in nodes D and E or to the endpoints of the 
> client layers, i.e. nodes A and G?

To D and E.
over the connection.
to E.

> and G

First question is "why?"

It may help to think of the client layer network as a single layer
network and resolve the issues there first.

Let us suppose that the fault was in the client layer at node D. How
would A and G find out about the fault?

> notify the endpoint of the client layers of the fault (remote). And 
> IMO we need to be clear about the requirement. And also to extend the 
> definition in the first bullet for remote (not necessarily endpoint).

The answer is that the end points of the link (in the client layer) or
the connection (in the server layer) may be MEPs. When they detect
faults they raise alarms to their management systems.

When the fault is detected by the end points (as surely it will be) they
can perform fault localisation to isolate the fault. That is, the MEPs
can consult the MIPs and (since the MIPs are allowed to respond)
determine where the fault is.

If, in the opinion of the deployer, the end points of an LSP need to
know about the location of a fault at detection time (I have serious
doubts about
this) then he can designate every node along the path as a MEP.

> * Assuming that the failure is in the first (server) link. As a result

> we have loss of continuity in the LSPs that transmit over this failed 
> link and in the PWs that are attached to these LSPs. As I understand 
> from your definition, as these fault are detected by the endpoint (to 
> which the link is attached), all these faults are considered locals!

No.
Please read again.

The fault is local if the fault exists in a resource that is local (in
the layer that is detecting the fault).

In your example, G detects a fault in the LSP, but G does not defect a
fault in the link FG or at the node G. Therefore the fault is not local.

Still in your example, E detects a fault in the server connection DE
(say DxyzE).
- If the fault is in E or in the link zE, the fault is local in the
server layer
- If the fault is not in E or in the link zE, the fault is not local in
the server layer In *both* cases, once the fault has been reported to
the client layer, the fault is local in the client layer (it is a
failure of the link DE).

May help you to note that local and remote are relative terms. I.e.
"local to E" is not the same as "local to G".

> Is there still a requirement to distinguish between these failures? 
> Note that all of these are now local.

I would just like to point out that we are now very far into
implementation and not standardisation. It is not the job of the IETF
(in my personal
opinion) to tell people how to build boxes.

Thanks,
Adrian

-----Original Message-----

and remote.

A fault may be reported (to the management plane) from the node of
detection (a local report), or may be signaled to another node (through
the OAM or control plane) and reported (to the management plane) from
that other node (a remote report).

The fault that is detected may be in the detecting node, or in a
resource directly connected to that node (such as a link). This is a
local fault.

But the fault may also exist in a node or resource that is not local to
the detecting node. This is a remote fault.

(remote fault).

fault.

Am I wrong?

Thanks,

Adrian

[email-masked]

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Thu, 7 May 2009 15:18:19 -0500

Malcolm,

I agree in general with your approach.

Please see inline below.

Regards,

Kam

> From: [email-masked]
[mailto:[email-masked]]

> On Behalf Of Malcolm Betts

> Sent: Thursday, May 07, 2009 11:39 AM

> To: Adrian Farrel; Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls-

> [email-masked]

[Lam, Hing-Kam (Kam)] G.806 already has the definitions for Fault and
Defect. We should reuse (base on) them as much as possible. The key
point here is the differentiation of primary and consequential.

> differentiation.

[Lam, Hing-Kam (Kam)] Agree.

> passed from a server layer to a client layer within a node.

[Lam, Hing-Kam (Kam)] Agree. The challenge here is, e.g. how the client
layer MIP further passes the information to the client MEP.

> primary/consequential defect.

[Lam, Hing-Kam (Kam)] Define primary/consequential defects, but based on
the G.806 definitions of fault and defect. 

> defects.

[Lam, Hing-Kam (Kam)] Agree to have such a requirement in the NM
requirement document. However, if the OAM tookit supports mechanisms to
support this differentiation and suppression in the DP, that will make
the life of the MP much easier. Otherwise the poor MP will need to
perform root cause analysis to find out which/where is primary (root
cause) and which are consequential.

> > * We have a requirement in the document for "Remote Defect
Indication"

> > * Assuming that the failure is in the first (server) link. As a
result

be

to

point

the

layer)

> separation) so the client layer does not need to know about the
location

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 08 May 2009 00:11:36 +0200

Hi Kam,

You wrote;

> */Malcolm,/*
>
> */I agree in general with your approach./*

This is indeed a good approach.
Note that the draft rosetta stone already contains the
definitions for (primary) defect, fault and failure.
These are in line with the definitions in G.806.

So only consequential defect needs to be defined.

Regards, Huub.

> */Please see inline below./*
> 
> */Regards,/*
> 
> */Kam/*
>  
> 
>>  From: [email-masked] [mailto:[email-masked]]
> */[Lam, Hing-Kam (Kam)] G.806 already has the definitions for Fault and 
> point here is the differentiation of primary and consequential./* 
> 
>>  It MUST be possible to differentiate between primary and consequentia
> */[Lam, Hing-Kam (Kam)] Agree./*
> 
>>  Comments:
> */[Lam, Hing-Kam (Kam)] Agree. The challenge here is, e.g. how the 
> client layer MIP further passes the information to the client MEP./*
> 
> */[Lam, Hing-Kam (Kam)] Define primary/consequential defects, but based 
> on the G.806 definitions of fault and defect. /*
> 
> */[Lam, Hing-Kam (Kam)] Agree to have such a requirement in the NM 
> cause) and which are consequential./*>
>
>>  Hope this helps.
>>
>>  Malcolm Betts
>>  Nortel Networks