Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02

Mach Chen <mach.chen@huawei.com> Sat, 30 August 2014 03:32 UTC

Return-Path: <mach.chen@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904671A700C for <mpls@ietfa.amsl.com>; Fri, 29 Aug 2014 20:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.869
X-Spam-Level:
X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_8jfdrRK_6T for <mpls@ietfa.amsl.com>; Fri, 29 Aug 2014 20:32:38 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC431A700B for <mpls@ietf.org>; Fri, 29 Aug 2014 20:32:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIW61193; Sat, 30 Aug 2014 03:32:36 +0000 (GMT)
Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 30 Aug 2014 04:32:35 +0100
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Sat, 30 Aug 2014 11:32:33 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "Sam K. Aldrin" <aldrin.ietf@gmail.com>, "Nobo Akiya (nobo)" <nobo@cisco.com>
Thread-Topic: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02
Thread-Index: AQHPvOsdwjhGcp6uiEqhBQ5TeCNTy5vbARkAgABOkoCAA/otAIACKNwAgAcIvhA=
Date: Sat, 30 Aug 2014 03:32:33 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DA8EAA8@SZXEMA510-MBX.china.huawei.com>
References: <e4da58f21f34427686e7385f90354ec1@CO2PR05MB636.namprd05.prod.outlook.com> <E840F3E3-457A-4E9F-B4D4-2163BAC344C4@gmail.com> <CECE764681BE964CBE1DFF78F3CDD3943A3B4453@xmb-aln-x01.cisco.com> <BF1EA26E-3BEE-4DEC-ACAD-4200340CC17B@gmail.com> <CECE764681BE964CBE1DFF78F3CDD3943A3B7735@xmb-aln-x01.cisco.com> <BB317C04-BCEA-4403-A1EC-C431FFCD3486@gmail.com>
In-Reply-To: <BB317C04-BCEA-4403-A1EC-C431FFCD3486@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.97.72]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/RMnlpveNER_KDS8uU5A2JgVTF-g
Cc: Ross Callon <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject: Re: [mpls] Poll for Adoption draft-akiya-mpls-lsp-ping-reply-mode-simple-02
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Aug 2014 03:32:39 -0000

Hi Sam,

Some replies inline...

Sniped.

> 
> Let us take the MPLS TP with IP on every node.
> The scenario you are talking about is 'associated bidirectional' tunnel.
> Just because a 'vendor' implemented certain default method doesn't require
> new TLV support.
> For associated bidirectional tunnel with IP on every node, perform reply mode as
> IP.
> I don't think RFC4379 warrants certain default type to be fixed type for a given
> FEC.
> 
> [NOBO] What you say is true only if all operators prefer IP return path over
> control channel and reverse LSP. I am aware of operators who wants to prefer
> control channel or reverse LSP whenever available, over IP path. The preference
> really varies depending on operators. This is exactly where this extension can
> benefit.
> %sam - We discussed this before but ended up with opposite conclusion :D. If
> user want to perform return path via lsp or via IP, nothing prevents and one could
> chose either of them. The same goes for bitmap size, selector size etc.

Your assumption is that all nodes along the path support both IP and LSP return path, this may not always true.  In some mobile backhaul networks that normally have access and core network parts, the nodes in the access may only support pure MPLS-TP and not support IP forwarding; the nodes in the core part normally support IP/MPLS. Then takes the picture in A.2 as an example:

                             +----C------D----+
                           /                                   \
  A'----A------B                                   G---H---H'
                           \                                  /
                            +----E------F----+

Where A', A, H and H' only support pure MPLS-TP and do not support IP forwarding, B and G support both LSP and IP return path, it means that reply mode 2 cannot be used when perform traceroute. But when  "Reply via reverse LSP" is used, since  C, D, E and F may not have reverse LSP path but have IP return path, it still cannot traceroute the whole path. In this case, actually, any single reply mode cannot satisfy the requirement. 

The essential of the Reply Mode Order TLV is to allow multiple reply modes to be used for a specific LSP, and each responder can select its appropriate reply mode to return the echo reply.


Best regards,
Mach