Re: [mpls-tp] [mpls] [PWE3] [AHMPLS-TP] Re: pollondraft-he-mpls-tp-csf-03.txt

[<[e-mail]>]

Ben (and others) please do not overlook the other key points here.....

This can only apply to the PW layer network and clients of that layer network (as IP does not need this and sublayered LSPs do not need this).

Ignoring the fact that a transport network should treat all clients alike and thus PWs should not appear in MPLS-TP, we still have these 3 important observations:

1	One does not fix an OAM deficiency in a client layer network by creating a functional coupling to a server layer network....so that is a general architectural statement that says the draft is just plain technically wrong;

2	One should not map *server* layer defects *below the MPLS and PW layer networks* at either end into some CSF OAM function in the PW layer network and then onwards into the client (of the PW) layer network.....this further mistake is stated in section 3.1 of the draft.

3	Assuming we do all this anyway it is still essentially a pointless and unnecessary exercise.  Why?  Because if the client layer network X say of the PW layer network is NOT a Top-of-Stack (TOS) layer network then it must, by definition, have a higher layer network (somewhere above it, if not immediately above it) that is a TOS layer network.  This TOS layer network provides the true E2E networking span between the external message/file/stream applications that must exist in all networking cases.  It is thus obviously not sufficient simply to map the PW CSF function to the client layer network X, if the client layer network X cannot then map this CSF function it its client layer network Y...and so on recursively up the stack until we hit the true TOS layer network (which is most often IP anyway and does not need this!).


My colleague Andy Reid also summed the above up succinctly (if in a slightly more obscure way) when he said:
==>
"something happened, notify everybody who might want to know" 

How do you (the server layer) know who wants to know and how do you address them?
I made this point some considerable time ago in relation to AIS.
<==

Quite......and this is also why AIS makes absolutely no sense to (i) a cl-ps layer network like IP or Ethernet or (ii) SVC co-cs/ps layer networks as it requires a permanent binding of the client and the server....but it's also easy to show that AIS is not even needed on PVC co-ps mode layer networks.  AIS only has a required role in the traditional regular time-sliced and fixed PVC hierarchy co-cs layer networks of PDH and SDH.  

regards, Neil

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Benjamin Niven-Jenkins
> Sent: 04 December 2010 08:12
> To: Jiang Yuanlong
> Cc: MPLS-TP ad hoc team; [e-mail]; [e-mail]; 
> [e-mail]
> Subject: Re: [mpls-tp] [mpls] [PWE3] [AHMPLS-TP] Re: 
> pollondraft-he-mpls-tp-csf-03.txt
> 
> Yuanlong,
> 
> On 3 Dec 2010, at 14:46, Jiang Yuanlong wrote:
> > From: "Ben Niven-Jenkins" <[e-mail]>
> > 
> > The CSF draft covers two cases:
> > - PWs
> > - LSPs (and by implication the three clients supported by 
> LSPs, namely 
> > IP, PWs and other LSPs)
> > 
> > PWs have a mechanism already and the CSF draft acknowledges that.
> > 
> > LSPs have BFD and other tools to detect failures.
> > 
> > IP has a bunch of mechanisms e.g. IGP hellos if you're 
> building an IP network or various keepalive mechanisms if 
> you're layering IP tunnels on something else.
> > 
> > The premise of the draft is "This document defines such a 
> MPLS-TP OAM tool as Client Signal Fail indication (CSF) to 
> propagate client failures and their clearance across a 
> MPLS-TP domain" based on the fact that "the client layer OAM 
> functionality does not provide an alarm 
> notification/propagation functionality"
> > 
> > For the three possible clients of MPLS-TP, the second 
> sentence I quote above does not hold true and therefore the 
> draft is not needed.
> > 
> > [JYL] IGP hello is not so fast, maybe BFD is also needed 
> for such a use case.
> > In fact, there is also VCCV BFD available in PW, so do we 
> need any more PW OAM mapping in 
> draft-ietf-pwe3-static-pw-status (except bits defined for the 
> PW redundancy )?
> > 
> 
> The draft states that CSF is required for client technologies 
> that can not detect faults themselves. You are now stating 
> the purpose to be to compensate for client technologies where 
> fault detection is not fast enough. That is a different use case.
> 
> In the case that IGP hello is not fast enough (and the timers 
> can always be tuned) detecting the fault is only part of the 
> time it takes for the network to reconverge. 
> 
> It is still not clear to me why MPLS-TP requires CSF for IP 
> clients when other server technologies that IP runs over do 
> not provide it and IP networks have operated fine
> 
> > However, if I am wrong and the draft really is needed it 
> should be straightforward for someone to post a description 
> of a practical deployment use case where the existing IP 
> mechanisms are insufficient and the CSF functionality is 
> required in MPLS-TP to proxy for the lack of client level 
> functionality.
> 
> Ben
> 
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>