Re: [Mpls-interop] Local and Remote

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:adrian@olddog.co.uk] 
Sent: Wednesday, May 06, 2009 5:18 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); mpls-interop@ietf.org
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!

Why the exclamation point?

<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

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

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

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.

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

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

> nodes A and G

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 

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?

<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 

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?

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

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

<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 

this) then he can designate every node along the path as a MEP.

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

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

<NS> OK. 

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

<NS> OK

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.

Yes, there is a requirement to distinguish.

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

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

From: mpls-interop-bounces@ietf.org

[mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Adrian Farrel

Sent: Wednesday, May 06, 2009 3:16 PM

To: mpls-interop@ietf.org

Subject: [Mpls-interop] Local and Remote

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

_______________________________________________

Mpls-interop mailing list

Mpls-interop@ietf.org

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