Re: [Mpls-interop] Local and Remote

[Huub van Helvoort <[e-mail]>]

Hi Nurit,

You replied:

> Thanks for the great clarification.
> 
> 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
> 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.

[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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of ext Adrian Farrel
>  Sent: Wednesday, May 06, 2009 3:16 PM To: [e-mail] 
> 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
> 
> [e-mail]
> 
> https://www.ietf.org/mailman/listinfo/mpls-interop
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________ Mpls-interop mailing 
> list [e-mail] 
> https://www.ietf.org/mailman/listinfo/mpls-interop

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