Re: [mpls] working group lastcallondraft-ietf-mpls-tp-mip-mep-map

<hideki.endo.es@hitachi.com> Wed, 05 December 2012 00:58 UTC

Return-Path: <hideki.endo.es@hitachi.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9D221F8BBB for <mpls@ietfa.amsl.com>; Tue, 4 Dec 2012 16:58:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.49
X-Spam-Level:
X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zx4BmG7pVVB for <mpls@ietfa.amsl.com>; Tue, 4 Dec 2012 16:58:11 -0800 (PST)
Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0C08921F8A8B for <mpls@ietf.org>; Tue, 4 Dec 2012 16:58:11 -0800 (PST)
Received: from mlsv5.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 0DB7637AC3; Wed, 5 Dec 2012 09:58:10 +0900 (JST)
Received: from mfilter04.hitachi.co.jp by mlsv5.hitachi.co.jp (8.13.1/8.13.1) id qB50wAsA006903; Wed, 5 Dec 2012 09:58:10 +0900
Received: from vshuts02.hitachi.co.jp (vshuts02.hitachi.co.jp [10.201.6.84]) by mfilter04.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id qB50w9vF022310; Wed, 5 Dec 2012 09:58:09 +0900
Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts02.hitachi.co.jp (Postfix) with ESMTP id EEEC0490059; Wed, 5 Dec 2012 09:58:08 +0900 (JST)
Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id qB50w8e8286286; Wed, 5 Dec 2012 09:58:08 +0900
Message-Type: Multiple Part
MIME-Version: 1.0
Message-ID: <XNM1$7$0$0$$6$1$2$A$5003765U50be9be5@hitachi.com>
Content-Type: text/plain; charset="us-ascii"
To: davari@broadcom.com
From: hideki.endo.es@hitachi.com
Date: Wed, 05 Dec 2012 09:57:53 +0900
References: <5098CF68.2000105@pi.nu> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <B5CDD7D1-CBD7-4E74-ADE6-0DEBE26E3757@broadcom.com> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <XNM1$7$0$0$$6$1$2$A$5003751U50bd483f@hitachi.com> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa> <XNM1$7$0$0$$6$1$2$A$5003753U50bd5093@hitachi.com> <63293273-A276-4F9F-AD24-27A70977E445@yahoo.com> <B3B28804-C35E-42DC-8062-D0E7A858D2CE@broadcom.com> <XNM1$7$0$0$$6$1$2$A$5003763U50bdba91@hitachi.com> <B392FF00-C186-4630-B136-415D08685B1D@broadcom.com> <XNM1$7$0$0$$6$1$2$A$5003764U50bde31f@hitachi.com> <175D51A2-5876-4EEE-9D36-AEE78017A99D@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD39C6A@SJEXCHMB12.corp.ad.broa>
Priority: normal
Importance: normal
X400-Content-Identifier: X50BE9BE500000M
X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28121205095709SPM]
Content-Transfer-Encoding: 7bit
Cc: mpls@ietf.org
Subject: Re: [mpls] working group lastcallondraft-ietf-mpls-tp-mip-mep-map
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 05 Dec 2012 00:58:12 -0000

Shahram,

I think that your summarize is misleading.
Our draft does NOT require MIP ID to be parse by the HW. It depends on your implementation.
As Rolf replied to you, we have several options, i.e., a TTL-expired OAM frame can simply be
copied and forwarded to the out-MIPs where, if the frame is not intended for them, 
it can safely be dropped. 
Although you have concern about losing some resources of an OAM processor due to unnecessary
OAM packets, even your proposal using ACH header have low effectiveness in case of P2MP tree
having many leaves as you said below and I pointed out in other email.

Thanks,
Hideki Endo

> Hi MPLS WG,
>
>I would like to summarize our discussion and let the WG decide.
>
>1) The draft requires MIPID to be used by the HW in the Ingress port to select whether an OAM packet should be sent to CPU for processing or be forwarded to egress port(s). 
>
>2) The draft requires MIPID to be used by the HW in Egress port to select whether an OAM packet should be sent to CPU for processing or dropped.
>
>3) The draft solution applies to P2P and P2MP MPLS, and is efficient, meaning that it sends OAM packets only to the CPUs that need to be used for processing. And does not overload CPUs that don't need to receive an OAM packet.
>
>4) The draft solution requires parsing the OAM packets to get to the MIPID TLV. There are many types of OAM messages with different format (BFD, LSP-Ping, APS, RFC6374, etc.) and the TLV can be anywhere in the packet. This makes the draft solution not practical to implement in HW, and therefore not widely deployed.
>
>------------------------------------------------
>
>5) My proposal  is to use a single bit in the ACH to indicate whether the OAM packet is for in-MIP or out-MIP.  This single bit is used by HW in the ingress port to select whether an OAM packet should be sent to CPU for processing or be forwarded to egress port(s). When packet is sent to CPU, then the MIPID can be used by CPU to double check that it has received the expected OAM packet.
>
>6) My proposal is for an egress port to send the OAM packet to CPU, if a MIP is configured on that port, (otherwise drop it in HW. When packet is sent to CPU, then the MIPID can be used by CPU to double check that it has received the expected OAM packet.
>
>7) My solution applies to P2P MPLS (which is more than  95% of the LSPs, PWs) efficiently, meaning that it sends OAM packets only to the CPUs that need to be used for processing. And does not overload CPUs that don't need to receive an OAM packet.
>
>8) My solution applies to P2MP MPLS (which is less than  5% of the LSPs, PWs) but NOT efficiently, meaning that it sends OAM packets to the CPUs that don't need to process the OAM and overloads some CPUs that don't need to receive an OAM packet.
>
>
>The question in front of the WG is which solution to pick. My argument is that although the draft solution is a theoretically a perfect solution but is not practical and may never get implemented widely.  While my solution is perfect for more than 95% of the LSPs (P2P LSPs) and is in-efficient for less than 5% of the LSPs (P2MP LSPs). However it is simple and trivial to implement in HW.
>
>You choose !
>
>This is my last argument email justifying my proposed solution.
>
>Thanks,
>Shahram
>
>
>_______________________________________________
>mpls mailing list
>mpls@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls
>