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

Eric C Rosen <erosen@juniper.net> Mon, 20 July 2015 17:20 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 7D93E1B2C7B for <mpls@ietfa.amsl.com>; Mon, 20 Jul 2015 10:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 jjPA5fCyF_Rw for <mpls@ietfa.amsl.com>; Mon, 20 Jul 2015 10:20:09 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0148.outbound.protection.outlook.com [207.46.100.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438831B2CB5 for <mpls@ietf.org>; Mon, 20 Jul 2015 10:19:50 -0700 (PDT)
Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;
Received: from [172.29.32.144] (66.129.241.12) by DM2PR0501MB1101.namprd05.prod.outlook.com (10.160.245.11) with Microsoft SMTP Server (TLS) id 15.1.213.14; Mon, 20 Jul 2015 17:19:47 +0000
Message-ID: <55AD2DAD.4060908@juniper.net>
Date: Mon, 20 Jul 2015 13:19:41 -0400
From: Eric C Rosen <erosen@juniper.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Shahram Davari <davari@broadcom.com>, "stbryant@cisco.com" <stbryant@cisco.com>, "mpls@ietf.org" <mpls@ietf.org>
References: <55AD19F2.1010206@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F73A21@SJEXCHMB12.corp.ad.broadcom.com>
In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831F73A21@SJEXCHMB12.corp.ad.broadcom.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [66.129.241.12]
X-ClientProxiedBy: BN1PR12CA0013.namprd12.prod.outlook.com (25.160.77.23) To DM2PR0501MB1101.namprd05.prod.outlook.com (25.160.245.11)
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1101; 2:nwveqMHkM4S7wfCYDIqcE3Xvls96YO8TGZ4G/jKVD7P1ecegV/l6to0/M0u+2TnC; 3:Jv9HS9XIYB8UGeSl+xLhTcWKr7ZNRLHF5H5tEoe8T6j0g8nCOeldtQtnABFKUDKVZXiRkon6zoiT4vo8yT5krWV5W9qe6iTOwJufYvGovJwzZoKDTqj1pZnEHMppFzWvECzcyeGyiXEYiJubgIDwSw==; 25:ZV2YOVfbjGEeBx0+lfHdHWaSGenPppuDMQXD5+Dah0f89qBPBXZuMyQ9l/Bwbn8QFrmHH9Uz1w9u4QLHvOGvbizQb+soxhIc/jINiDx12EqjbLXsCN0X9qw0AFNmVhQBnYDt8DlWm2n3gcj9JZzvl1NhKlkx1b1NZA00yao1yhJOoi/IXDnJnNfkbr2XdcmNu1DQo6j1ZnhrbkG30Z2L9Vgv08B+ilPyvHjj7zoDMvBT3zAcAZ27r58mOWWw+MyC
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1101;
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1101; 20:QU0mb8nhtq5ChlpN9R6YDKOFyTIXk2Zt6r34ZEYYkENO9DyruDfSHpIgM4GtxQUpk6KxW/uhbAdvwbTzsRLka3tkwZ+zkKQUyOGjsUWexdVmsSpzhFB0AqNX7Il6JvmjblXlvaKwWuFKJVZZ4R0zZH6QwHXD187EHk9+R3tyjiwXhdwzO6xp4AYAZTgzB2cs66A2XfrMfOchpQIGz/8J8QKQogTjo5hUa7kETaDoFNSUWe+oUCh0lKFj/kuC3+w/vvoSOJQDKsCT17100xIi+dunpNd0yInKjkd2dKclXCtOYw6eUmkOfQL2KAyvI+vdj3EjbBt2MLW00xzxR07pmDn2H2BiGwH5furIlCQ4vv04jyjEZ72gfpFykl93ZkFRxYXcztkFsq0dQmPKXHBN+ZgDTizR/v/21/xA2Udagd18FJA7KZHE6KPp8UPPR+OrZjYOS5XO9PEUGgK38R9pepADfb2V4ShdVw5a1IAXR4Bz3TVazFxM90ZfHO2/it+f; 4:lNImLKvVjD+VA3v0Hqmuaaj0r8RjP5XJbT/d+y9pqNBLrBg8oaF4Tg2yNOOuGPFy57vbiB1RrKel315A5HHof8GFAA4Pm3rtbzfBHFJBTS9ph91uHMjnmq2aql430Ps872znzS0xdbTcT9A2g8g5K9sHhsTEnMHs1B/yr8y/TtFi+S1z26QIsbue2WnF0cDV6QvjjM2bO59YMzPavxp0FZz1IJcaRKzwvoc5ZeBOS990jVZq7WwF3rpFL6S3q/zM6h19yG41r0fbrDy6vlm5EdVreYynZ+kqeiLCBH6Bzwo=
DM2PR0501MB1101: X-MS-Exchange-Organization-RulesExecuted
X-Microsoft-Antispam-PRVS: <DM2PR0501MB110188CE71E6DE9E67C0BB66D4850@DM2PR0501MB1101.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:DM2PR0501MB1101; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1101;
X-Forefront-PRVS: 0643BDA83C
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(24454002)(377454003)(479174004)(80316001)(62966003)(87976001)(50466002)(230783001)(59896002)(42186005)(65806001)(65956001)(107886002)(77156002)(2950100001)(47776003)(5001960100002)(66066001)(77096005)(2501003)(46102003)(122386002)(92566002)(4001350100001)(33656002)(86362001)(65816999)(50986999)(5001770100001)(23746002)(36756003)(54356999)(189998001)(76176999)(87266999)(40100003)(83506001)(2201001)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1101; H:[172.29.32.144]; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DM2PR0501MB1101; 23:oe8CgHrGhoyUpoC6LJrpL2QTdDFp2bTgkEw?= =?Windows-1252?Q?sxYWKA2TVD3IUy8gpgIMAX8vvV1Lq9NeVV83S+XCA2DDg0i+ECiJRN3f?= =?Windows-1252?Q?Vw40fD1JNhcPW33V3z+IbQpCH+IKCGQmNStbP/Iu3Kp0sBdB61dtKmXr?= =?Windows-1252?Q?pPcdyAdItusNgyhVBJSy1aw5JsvRr1BlZJOIMLe6E20iJhTeGrRc5gAu?= =?Windows-1252?Q?wsiL0gikBCMnk8Go8xBB/QpgxPatOQVh0bcATioIi1vqLN8R9yiV5tJ2?= =?Windows-1252?Q?KjYUUSOMR8Y0MH/ARmUKfKKHLBdbOiKJq+IBHXJVTruFwL2cPXE9vUB1?= =?Windows-1252?Q?nlKNJtFFbTgn3nJrUv4AJtWln0YFVdaQw/f7IRzRgn3nrafOo7D8GLRN?= =?Windows-1252?Q?up/6yh6iwpO5YDBSuSx7LqilmBXwnrBEDDYiJHy53gVxspEtlYXneyue?= =?Windows-1252?Q?sNio3l4+dLxUb8YLYej/Ue/u6WEskxiIEYPTN/WMztlEjHFeN8VWcDuf?= =?Windows-1252?Q?gZj+H5xlXJOSWPclLR31MJTLllEXImfTNxQ7CGdFuD0PpEYFP0+3A2Gy?= =?Windows-1252?Q?Rg//TyVaOmxGB8/DJYAM6bsdnMCndJN5QZ+TFki5HgwScZKRibcnMmr/?= =?Windows-1252?Q?xlejhHKr1caoS1yab4QTCpcwyFbAGI6ECERsbvDpdaDwp9e7rHieJv7P?= =?Windows-1252?Q?irLoy0BvNJJoGAXVtklPjqoc7jz2YFloZBqICzZz+mVK7QaNIG61hU4u?= =?Windows-1252?Q?s6cv4FT0BTqYvGZiLwxj60dPbr46gSLJM+KmQVEW8ohVXwgaupdFE6Tz?= =?Windows-1252?Q?IPaH0mx4bRMniLqq/b4i4yLKvYwtLl2U8s25MawuKHSVjfPuKUBsAEeJ?= =?Windows-1252?Q?8T9pPs2vAsXEv6MTEqPJBRkR9bkdZXGGpBQTUwJ2ynh4CAlYoUY/GuAh?= =?Windows-1252?Q?0Wk2MJyCbEnx6pqQI8mC+u6Cb/hT7RqSz/FnIKS9y3QPmM2tJM/Hqopw?= =?Windows-1252?Q?5lSj9PGxjFgoZQR8UKutRoPXOIF+no1crn23AUk+82qc+pR3CMSQom8n?= =?Windows-1252?Q?5wcNr5Ur0aHt5LBOrjfZSbR1fPCRqhUVJxKDcg4DU+/yR5hq98wMlytf?= =?Windows-1252?Q?/6V0IBqI0Xf+7GSxzxSMrypdvI2ZTs6qK9yLrvUkMUpXn?=
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1101; 5:VMnwK/ugSYcpn1g82tqfON4juAETc8trcg9v/BwUTcZ0KBxOSwTqq80RrhvyalxExZdPqr5HV7VPqWYHH4lqFJsUtFFRhFwumOkTVo+cPKbvcCE6UPcBIUd9KLhbNhfTx62obe29FN75WeePOgRHjA==; 24:ijn9SVuouaGGxeffjpGjm9DN6o8FcfO/ArGU2CuqS0xSPTVj6X0Evf/hhN8VZbc/Hl5OzpYETqdseQXNXjFxRrntIahCCvoJx+UMMzmMnxs=; 20:hmDrhgMNXFIJC3sNACfn0y2lzyWKRIEZtugUwhtRUaxoRExODbEJlrOOSSAiI7+PSCyVgp5ZJ86ql2P5IfrPsA==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2015 17:19:47.5183 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1101
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/wIhJl-CwONNAatAv5Z3pWn-H7c8>
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: Mon, 20 Jul 2015 17:20:13 -0000

On 7/20/2015 12:27 PM, Shahram Davari wrote:
> This draft actually saves a lot of memory as it requires only very
> little MPLS entry table and associated processing. There are only a
> few Ethernet MAC headers used in MPLS forwarding, typically one MAC
> per port, but there can be thousands Of swapped labels. So it is not
> a matter of 14 bytes vs 18 bytes.

This seems like purely a local implementation matter.  You still have to 
look up the label, don't you?  If you want to optimize for the case 
where the top label doesn't actually change its value, just use a 
14-byte rewrite string instead of an 18-byte string for those labels, 
and allow multiple label lookups to result in a pointer to the same 
14-byte rewrite string.

I don't really see the point of the draft, as this optimization does not 
require any architecture changes or any protocol changes.