Re: [mpls-tp] CSF architecture [was: RE: [PWE3] poll on draft-he-mpls-tp-csf-03.txt]

[<[e-mail]>]

This is a distorted view Maarten....and underlying it is the assumption that AIS/FDI is a 'good thing' in all modes.  Well, it is patently not true in the cl-ps mode...go look at IP...even IEEE had the good sense to throw it out for Ethernet in 802.1ag.  It is also a mistake in the co-ps mode.  I agree we made the mistake of having AIS in ATM at least and I used to think it was a good idea in Y.1711 for MPLS with proper connections, but I have since had to change my mind as the technical arguments for NOT having it are totally compelling. 

AIS only makes sense in the co-cs mode (time dim only)...and even then only when the client/server binding is fairly permanent (ie done via MP) as we 'have to put something' in the fixed resource time-slice durations that are committed at a priori know epochs (their labels)...for SVCs done via CP signalling (eg the PSTN case you note below) then again its value is dubious.

regards, Neil

> -----Original Message-----
> From: Maarten Vissers [mailto:[e-mail]] 
> Sent: 02 December 2010 08:36
> To: Harrison,N,Neil,DKQ7 R; [e-mail]
> Subject: CSF architecture [was: RE: [mpls-tp] [PWE3] poll on 
> draft-he-mpls-tp-csf-03.txt]
> 
> Neil,
> 
> > -	the draft is not even technically accurate of its primary
> > architectural transparency violation (ie transporting a *client Y* 
> > signal fail indication by forcing the server Y/PW/MPLS 
> layer network 
> > to 'understand' the client signal symbols) ....as I noted below in 
> > section
> > 3.1 this is using a *server X* (of PW/MPLS/X) failure 
> condition to be 
> > mapped into a *client Y* (of Y/PW/MPLS) failure.  Just how bad are 
> > folks prepared to make this functional coupling of different layer 
> > networks?
> 
> Any server/client_A function has awareness of the client_CI 
> and the server_AI.
> Client_CI includes CI_SSF information. Server_AI includes 
> client mapping related OAM.
> The adaptation source function takes client_CI_SSF and maps 
> this into a server CSF OAM packet. Just very normal 
> processing for an adaptation source function and supported in 
> e.g. SDH and OTN for many years.
> 
> With respect to the creation of the client_CI_SSF signal, 
> this is done in the e.g. PHY/client adaptation sink function 
> under control of the PHY_AI_TSF signal, or any 
> PHY/client_A_Sk detected defect condition. Again, very normal 
> processing for such adaptation sink function, used many times 
> in PDH, SDH, ATM, OTN and Ethernet.
> 
> The CSF OAM starts in the server/client_A_So function and 
> terminates in the far end server/client_A_Sk function. Both 
> functions have server_AI and client_CI awareness and there is 
> no transparency violation at all... i.e.
> the client_CI_SSF information is transparently transported 
> from the client_CP on the server/client_A_So function to the 
> client_CP on the server/client_A_Sk function.
> 
> > 
> > Aside=> When a client layer network is cl-ps there is no 
> sensible way 
> > to map any server layer network connection failure (of a link 
> > connection in the client cl-ps layer topology) into a client layer 
> > failure indication.  If not obvious, then consider what indications 
> > are mapped into an IP v4 layer network from a SDH VC4 failure of a 
> > link connection in the IP layer network...the answer is 
> none (and for 
> > jolly good technical reasons!).
> 
> If an E1 link fails in a PSTN, will there be a failure 
> indication generated in each DS0 transported over that E1 
> link? The answer is 'no'. If a VC4 trail fails in a SDH 
> network, will there be a failure indication generated in each 
> VC12 transported over that VC4 trail? The answer is 'yes'.
> Similarly, if a VC4 trail carries VLANs and this VC4 fails, 
> then a failure indication is generated in each VLAN 
> transported over that VC4 trail. Once IPVPN customers would 
> like to get transport grade quality of service, we will add 
> IPVPN OAM, including IPVPN CC/CV. When an IPVPN link 
> connection fails, it would be beneficial to generate a 
> failure indication in such IPVPN to suppress the 
> consequential IPVPN Loss of Continuity alarms. And in 
> similarity with the PSTN, the INTERNET (i.e. IP Virtual 
> Public Network) will not deploy such transport OAM.
> 
> Regards,
> Maarten
> 
> > 
> > regards, Neil
> > BT Design
> > 
> 
>