Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Eric C Rosen <erosen@juniper.net> Fri, 24 July 2015 15:09 UTC

Return-Path: <erosen@juniper.net>
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 3E5731B30BF for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 08:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level:
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 blnI63EbUktP for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 08:09:40 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92D41B30BE for <mpls@ietf.org>; Fri, 24 Jul 2015 08:09:39 -0700 (PDT)
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;
Received: from [172.29.32.141] (66.129.241.14) by BY1PR0501MB1096.namprd05.prod.outlook.com (10.160.103.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 24 Jul 2015 15:09:36 +0000
To: Andrew Qu <andrew.qu@mediatek.com>, Loa Andersson <loa@pi.nu>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Stewart Bryant <stbryant@cisco.com>, "Andrew G. Malis" <agmalis@gmail.com>, "S. Davari" <davarish@yahoo.com>
References: <DB3PR03MB078098C91E8D3C7DCDCCF8C39D840@DB3PR03MB0780.eurprd03.prod.outlook.com> <EA360A7AB9D90D4B9E9173B6D27C371EE3F6038F@MTKMBS61N1.mediatek.inc> <55B11D6D.2040102@pi.nu> <EA360A7AB9D90D4B9E9173B6D27C371EE3F607FB@MTKMBS61N1.mediatek.inc>
From: Eric C Rosen <erosen@juniper.net>
Message-ID: <55B2552A.80702@juniper.net>
Date: Fri, 24 Jul 2015 11:09:30 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <EA360A7AB9D90D4B9E9173B6D27C371EE3F607FB@MTKMBS61N1.mediatek.inc>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [66.129.241.14]
X-ClientProxiedBy: BN1PR12CA0016.namprd12.prod.outlook.com (25.160.77.26) To BY1PR0501MB1096.namprd05.prod.outlook.com (25.160.103.142)
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 2:Uw4qHoXcsKebFn9QdU9ugscvAqBsjtMMVlFtR+5M3zhGTKyXlp+7JW2ZBT7shPxiK0KAwqMsq16cof2q5BIgst69NuZURZN6rDbcVr+KOL39PclWbGZZSpDyprXweCURxO7pXQ0Pz5+CVhhQMcj+VTBUe+nsRYAzqeODu6LbPrY=; 3:eLcuHzfxoIfc6Q8nbFWcjylcqmTxavJB5B0oU1OghfkB2hW43Vy5W8kbXW27IGz8wDAKFIYj6eB4dOIEHtPSv5FLHWg11TWbgp5XzdimkZgippYRr0yDje0KQdXbNKG0Fb2EW0xF0JMWIMfEJSIFFA==; 25:H+MSUKr30VR0jRFhNHm7xeOmN3tJjnBdnMyzSY/heirgNWrrxY09w4+buFRFMl6TKiKx6sSXj81TPKGW3o9Qi7iB+Opn2yK7anlH1AgYZUz8DLnRiNBQP5ZSVeKUgA5566F3v92up65nKdnDTBhla+6fRaSnPGtS7qu+zmDdddpmx6fXMYO+LgnoZ6eLB2WKSAbdBINzNkif4ZgUa9oCQlVaET3hmcCS+Q/sld6TtJ0U1Z9GIL+J116IG9LPCtOegLgzO5HUeGEwHxinTSkrWA==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1096;
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 20:yZ3Jh4A5bLRuc4tIQkgsX+u+GUNDwDAwsvLE2XrDM71S/rxFBm5xSNZyiCFnvaXH9niOubduCehj0BvZTqIS8OU3o/O350uzSSw+1SoxNUxfar/Ed9ujkg9BXjMqUPnQ2tsc99JrVmzyFdYRHlKvGwUq1+hrWUkwh5Ny3oXCgIR670LIcK4wHZmy/sxrCXDYsBpYq2O1O6NLIFdO20xOz5uOj1Z2HfWwU5I8nUa+ln8N/QtWMEZ7Oat8uUeAL7GohJSh7c77GYJh7operNnWS7Ffv0KDrKdVdR9q9hcc+cy5cWM9Czcjahssro0bgAYR64q06dkGvOfYLxTFEGxIOA2wShUioyj6bz1RyGCTKdXL3CBlUZvz3dAbt8o/EYMYNe+5sWJUubbIwtEv84NWl/X6z09XTu2yRWp/De/Tk2DpPMVRXLWk68tk78DdwCkpdZcerspujAawN9cYjYvDkd3U6kv3iRwnKT7sPFLN1SE6IB1LWX9oNjkA4uMDZxPB; 4:YDm3qYqQMcRD2HdkPCG2dO/53Ebao00UHOh3I7xV1h9k6bBXnWCpUtbhKa6E+OlrGiFdHOzA6zZqewpN42SMF24VY1IiW1AymR379wEVzStZsTLCyCeOG7u5kwyGVxQmTQktR4VNck1B5yUHfjlpiZ1ASh1Jmm2bR499xJr36ShH2eCi8a7hdK+C7563Tts6wx8k6dxBH00c3rXE5HKStuZ0vLdZ+Vg/XU60xV85brYkZgKbn+LIX+SEsEjvLNY2hzxul7B48A3aEDVyOloauTgajnLC+DInHK4rF+TjBeQ=
BY1PR0501MB1096: X-MS-Exchange-Organization-RulesExecuted
X-Microsoft-Antispam-PRVS: <BY1PR0501MB1096AE089566C3949F8A53FAD4810@BY1PR0501MB1096.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY1PR0501MB1096; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1096;
X-Forefront-PRVS: 0647963F84
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(85654002)(54356999)(86362001)(42186005)(87976001)(50986999)(65816999)(5001960100002)(77096005)(76176999)(46102003)(65806001)(64126003)(66066001)(83506001)(65956001)(230783001)(23746002)(93886004)(2521001)(47776003)(2950100001)(92566002)(4001350100001)(189998001)(50466002)(33656002)(122386002)(5001770100001)(40100003)(62966003)(77156002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1096; H:[172.29.32.141]; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 23:BtWHhGdhG1cqo3Ix18FzD6aQIetEVIjyDKXy/RRO1VVy2IyTGm4GbXGFkMsYHfUtH8oQdTwB6vDU90JPK7eYsQYTcaMLl8ITRPeJc+ZMwMqsR+cO1OXzFo+IR3YmVCoXJQLh3QfXWNaKaWslwOsimWxqONJ8tMWuAA03BAPC9I3paub2S/UwbtNnnsMmxk2bBW1sxhtxbVUsXFZltvEiM0B4k8SeiqOEucr8I6Ni7yZ8+p/IpLHhCNarqJodqe2WpjRXX2SNFb4BvChbtOsSkJPLN77ARI9DMSXQRYWgt3wiIlmYJBF9DMqmvj/A5hgc+71cYCa4YSgviDz0bWLkeWZLWnPBmBbnW6BGw78O45T5LUHT/6S9XJf7qqRlt/X1fFNJOqomlBDEuR7OYbMpoyX8tQdbuBsMzlMYM9PXnQwRZlFI0XwzeSyMAI4ANxeAL0D01/f2K8n64mCO9TzrMSlnvhHiftYFteUeb9Ufk2DoIQVL5EAYpKt1XB7Sw47TwSL/mlEkA1A0aXcNnYT9kNaaFrsqBMng7CO6mGRwE61OEoMo4Fr8LTDoAm8cokiB9qg3HuqWW2bqY1dlCKax0IbfbLBUSM3QLPC0FklPVIxsW/X0TVlah3QynnsEHTsE8bNIZZzheAj+CnNCqgBQSTSNSMij9wof7/FPG+SUM/MgJXIaPdcbyzLUz/A6lT9Yof/2/IL6e3U3lGw36XzNlaX1GE+Ly0uD1LQtCAiK3PrzmTpjsHoGvKapGzUR3p1rAwJENt8VAkFThu93TGlQ1VE2l7UEug1ZtbHDi8Fdc8tdePQg5DlKDUuYx2/6pxbfZ/LvGz7Do/HRxrYBBe48EFDdHDmOOFUTVVF1wvI9KzPM0Z8xKrxj1E/SXhEITpqxFqDoESvymk4n/vuQlK9fGPtJtP2Jq9OLYdqg1l/B/HLsXqGmjSQGF2g4Df+2EGEs
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1096; 5:1i9WVBPK+LGoX2aJeWMWt0xh4YK/XLLQpQD0/0kwuAv3PjQBw+isnpjyAUC1WkHA44DBUR18SHLJSVj6T9OF80LMUelIIlbJZfChhqCqBHf7G4TRq6EvwTh6nmAQ3dQ0lTZqdwPv+Ghw8/qRJIrL1Q==; 24:IOpE3dppjbvhiO4ilQYkdtoxvwBCEN9TNn/bYNPxo9EF2AGY+5DTzlcHIjk7r+KLRuy0DaUoyHHUu9mfAP/Iu1cEjP7ZiVbQu7oUkobD5WI=; 20:7rVPbhs6gSQTKavJVQunCS0cY+Vgs6pt9eyFk5tU4iCoj4SkHkBnATFd8NFKeyhPcUM8WPONVYB8maHbrOwgVA==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jul 2015 15:09:36.8415 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1096
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/vkPuHAzp81EGY8GwTo3gDuv0BzY>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 24 Jul 2015 15:09:41 -0000

> When standard defines a "no-swap" operation,  ASIC engineer would
> implement such operation completely differently

Well, this is where we came in.  The RFCs do not dictate how the ASICs
should be designed, and your ASIC designers are free to design in
whatever way best meets the needs of the systems that are going to use
those ASICs.  You can put in any optimizations you think are warranted. 
  If you expect the ASICs to be used in products that will never need to 
swap label values, never need to push labels, never need to pop labels, 
then you are free to design the ASICs without any of these features.  If 
you think that these operations are needed, but that "don't change the 
label value or the stack size" are the most common operations, you can 
certainly optimize your design for that case.

But if you think you can get the ASICs designed properly simply by 
handing the RFCs to the ASIC designers, you may be in for an unpleasant 
surprise.

> Since the label is to be "swap"ed with a new LABEL stack, then the
> design of SWAPPING need to consider TTL handling such as 1) just
> decrement of original TTL or 2) using a brand new TTL, such as using
> local new register stored value to Fill the sawp'ed new label stack.

The TTL handling is exactly the same for both cases.  If you have been 
telling your ASIC designers something different, you most definitely are 
in for an unpleasant surprise.