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

Jiang Yuanlong <yljiang@huawei.com> Fri, 03 December 2010 14:45 UTC

Return-Path: <yljiang@huawei.com>
X-Original-To: pwe3@core3.amsl.com
Delivered-To: pwe3@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED4428C11E; Fri, 3 Dec 2010 06:45:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 AtLCMOuvOEbH; Fri, 3 Dec 2010 06:45:00 -0800 (PST)
Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id C313B28C0EB; Fri, 3 Dec 2010 06:45:00 -0800 (PST)
Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCU005GJX16TS@usaga01-in.huawei.com>; Fri, 03 Dec 2010 06:46:18 -0800 (PST)
Received: from LIGHT (74.30.35.121.broad.sz.gd.dynamic.163data.com.cn [121.35.30.74]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCU001D1X11M7@usaga01-in.huawei.com>; Fri, 03 Dec 2010 06:46:17 -0800 (PST)
Date: Fri, 03 Dec 2010 22:46:08 +0800
From: Jiang Yuanlong <yljiang@huawei.com>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Message-id: <009001cb92f8$d51096d0$6401a8c0@LIGHT>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <4CE51469.2020105@pi.nu> <00c201cb9137$0e7b1fd0$6428460a@china.huawei.com> <5E893DB832F57341992548CDBB33316398C53F6CF1@EMBX01-HQ.jnpr.net> <077E41CFFD002C4CAB7DFA4386A532640301C477@DEMUEXC014.nsn-intra.net> <5E893DB832F57341992548CDBB33316398C53F6D0C@EMBX01-HQ.jnpr.net> <006701cb91be$e5b529a0$6428460a@china.huawei.com> <D29E470202D67745B61059870F433B5403A8A274@XMB-RCD-202.cisco.com> <014401cb91de$6aa64580$6428460a@china.huawei.com> <C61C2514-C4B7-4E4C-A0FC-626D72A4FAF2@niven-jenkins.co.uk>
Cc: MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, "Eric Osborne (eosborne)" <eosborne@cisco.com>, mpls@ietf.org, mpls-tp@ietf.org, pwe3@ietf.org
Subject: Re: [PWE3] [mpls-tp] [mpls] [AHMPLS-TP] Re: pollondraft-he-mpls-tp-csf-03.txt
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Jiang Yuanlong <yljiang@huawei.com>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Dec 2010 14:45:21 -0000

Hi Ben,

Thanks for your feedback, please see my comments inline.

Regards
Yuanlong

----- Original Message ----- 
From: "Ben Niven-Jenkins" <ben@niven-jenkins.co.uk>
To: "Yuanlong Jiang" <yljiang@huawei.com>
Cc: "Eric Osborne (eosborne)" <eosborne@cisco.com>; "John E Drake" <jdrake@juniper.net>; "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com>; "Loa Andersson" <loa@pi.nu>; <mpls@ietf.org>; <mpls-tp@ietf.org>; <pwe3@ietf.org>; "MPLS-TP ad hoc team" <ahmpls-tp@lists.itu.int>
Sent: Friday, December 03, 2010 9:02 AM
Subject: Re: [mpls-tp] [mpls] [PWE3] [AHMPLS-TP] Re: pollondraft-he-mpls-tp-csf-03.txt



On 2 Dec 2010, at 05:04, Yuanlong Jiang wrote:
> ----- Original Message ----- From: "Eric Osborne (eosborne)" <eosborne@cisco.com>
>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf
> Of
>> Yuanlong Jiang
>> 
>> Typically, IP will only detect a failure in a time scale of minutes.
> 
> I must not understand the point you're making.  For one thing, BFD is
> quite often configured to detect failures in significantly less than a
> minute.
> [JYL] The question is: Can we assume BFD is universally deployed for IP and PW?
> If the answer is yes, then CSF is not needed, even for the PW application.
> 
>> That is one reason why MPLS-TP OAM and Protection & Switching is
> needed.
> 
> What are others?
> [JYL] Maybe you'd better refer to RFC 5654 for a comprehensive reqs :)
> 

Let's take a step back for a moment. Your original premise is wrong IMO. The need for OAM, protection & switching is MPLS-TP is not predicated on the fact that IP networks can't re-converge quickly enough.
[JYL] Sorry I am misled by the following statements which are extracted from RFC 5860, that MPLS-TP OAM:
   o  the reduction of operational complexity and costs, by allowing for
      efficient and automatic detection, localization, and handling and
      diagnosis of defects, as well as by minimizing service
      interruptions and operational repair times.

   o  the enhancement of network availability, by ensuring that defects
      (for example, those resulting in misdirected customer traffic) and
      faults are detected, diagnosed, and dealt with before a customer
      reports the problem.
There is no any comparison with IP indeed, but your comments make me wonder what is the value of MPLS-TP OAM to routers.
Does this mean it only apply to the transport equipments?


>> I am not sure which mechanism in MPLS provides the CSF-like
> capability,
>> could you give more hints?
> 
> Even regular IGP/LDP hellos (no special tuning, no BFD) very frequently
> are configured to detect failures in far less than "minutes".
> [JYL] Not sure this can be used to indicate the failure of  IP service.
> Even so, do we need to firstly determine what protocol is carried and then decide which mechanism could be used?


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

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