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

Maarten Vissers <maarten.vissers@huawei.com> Thu, 02 December 2010 08:49 UTC

Return-Path: <maarten.vissers@huawei.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C4E3A68C6 for <mpls-tp@core3.amsl.com>; Thu, 2 Dec 2010 00:49:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.345
X-Spam-Level:
X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAZ-nabT5Buy for <mpls-tp@core3.amsl.com>; Thu, 2 Dec 2010 00:49:15 -0800 (PST)
Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 717313A6816 for <mpls-tp@ietf.org>; Thu, 2 Dec 2010 00:49:15 -0800 (PST)
Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCS006XOL6UNG@usaga02-in.huawei.com> for mpls-tp@ietf.org; Thu, 02 Dec 2010 00:35:19 -0800 (PST)
Received: from m00900002 ([10.202.112.101]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCS007JOL6S99@usaga02-in.huawei.com> for mpls-tp@ietf.org; Thu, 02 Dec 2010 00:35:18 -0800 (PST)
Date: Thu, 02 Dec 2010 09:35:45 +0100
From: Maarten Vissers <maarten.vissers@huawei.com>
In-reply-to: <6D3D47CB84BDE349BC23BF1C94E316E440039D60C6@EMV62-UKRD.domain1.systemhost.net>
To: neil.2.harrison@bt.com, mpls-tp@ietf.org
Message-id: <000f01cb91fb$eac63c30$c052b490$%vissers@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset=us-ascii
Content-language: en-gb
Content-transfer-encoding: 7BIT
Thread-index: AcuHF6dUywX6oeqGTMCmvLNz9LOmyAACqhrQArPhTjAAAV7z4A==
References: <4CE51469.2020105@pi.nu> <6D3D47CB84BDE349BC23BF1C94E316E4400202675B@EMV62-UKRD.domain1.systemhost.net> <6D3D47CB84BDE349BC23BF1C94E316E440039D60C6@EMV62-UKRD.domain1.systemhost.net>
Subject: [mpls-tp] CSF architecture [was: RE: [PWE3] poll on draft-he-mpls-tp-csf-03.txt]
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Dec 2010 08:49:16 -0000

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
>