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 18:44 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 6D39C1B2AF2 for <mpls@ietfa.amsl.com>; Mon, 20 Jul 2015 11:44:07 -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 QBiW5FZJZNUm for <mpls@ietfa.amsl.com>; Mon, 20 Jul 2015 11:44:06 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2EC61B2AF5 for <mpls@ietf.org>; Mon, 20 Jul 2015 11:44:05 -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 CY1PR0501MB1099.namprd05.prod.outlook.com (10.160.144.141) with Microsoft SMTP Server (TLS) id 15.1.219.17; Mon, 20 Jul 2015 18:44:03 +0000
Message-ID: <55AD416D.2020306@juniper.net>
Date: Mon, 20 Jul 2015 14:43:57 -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> <55AD2DAD.4060908@juniper.net> <4A6CE49E6084B141B15C0713B8993F2831F73F3A@SJEXCHMB12.corp.ad.broadcom.com>
In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831F73F3A@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: BY2PR07CA050.namprd07.prod.outlook.com (10.141.251.25) To CY1PR0501MB1099.namprd05.prod.outlook.com (25.160.144.141)
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1099; 2:ZfrBcLGxpMRXqXialGCxxu5ELQ6vC0OZnUyGCVop1iy2F96sHmV8ZAxnaYYUoHaM; 3:ecyzQvZLwieG2CT1zB93Q3+iLAjQmeF3OVnMi7OhRe3rZ7YnLyo7xGmFAk7uTzcGv3y8K6XmnZ7wdjtri5APa4i7kmb2Cl9WUKdIagfkIWOZsG9OiGXdRWq9i7C7px4q+cQ7QCwykbGPLoFffbFlEw==; 25:PrYKI0JrIZJacUctBsgZzBPtEOuoDtyoAHEOcqJ5BU1znHkX12cffDQe3h7G7L9wn7QFkL9nuGBT9ZScYZRF8wJM7mqIvtYQuA/qLYX4zClqkmVWWVBxrj8AwwGkebmXt9bqVIGjgoioY8U2e4Axk4ReSGrFQfbwSGJntY7fKj/d3CnvcCOgeKtc+NZWiC4rA7feIcGnFN3Rqe6Bvq7A7fjS/f/lcNfv3+uoYv3LcVIDJHlNyNr5Q8JQgTnTdTVJOJx7FEt8aP2wDlUYiVHcUQ==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1099;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1099; 20:zhSZZNK7xnUP/ZgSIsfKqQ6TqGsD6GFDoaOz+KaEaW/soq0LFf1M3Pfyfo5zPl+ziHK3M+e030EAamTDp9nMRdb9SIE91DAUUi6bGPGvf6nFukRnei9tjn6B0jYgDF/6qtZLIJJheURrqvfo0rc3ZKaAe/TfaAPhyPcvAS+QxDHhhmm6wp+3YLPMvqVNISHDFrca3bAQNtCewm5jxtnbdeSnkju02zTRGqx1Iloe6tjeAFv55Zme4BU6pYIZ8HEc/lz3TJZ+DAidUYAQWwpe5eEk+N3nrUC94P60KfIfjsuEBYwfFnC7gwB3HI/dPTKsh2CxUyT8IIwfkzr+jAX05AheZNHtiHunuqhJVsPAnm7/N1zWPa7JDCmkMe9hLX8xiTKaC0ygtC0nGq8wO2Q7E6czf3kQcuTX7T5WxxuZybegSEldU7kQU3p5IGqEyGBDZBN2kfG0WBufjPpBXZWVZ/T9poPgJbEBmObEjaiqbCTxYybuXAAKTOoX1LsECXQC; 4:/bq0cUTo9BWU02jumE7amGyHhGkhoYACDxGLQfatiNpKUp7QcmSXqIJEQroeoqG8Qxfiyii7F5n93tAKbyg+b0u6nWxRsZyzLVbJ2Rh9+XEJ5eW5ZKsMf41XXn46asmov9i5YcYgwRahALoPFABsTo0i2W2ROWR2+FMgr4QYxRxPkyhwczm+bhQnFQCmY/ZQM3sbaOL3Gp107WLmrKMPXPeIUWLD2CoZ8YUl/7AJS8735k64+GJInTqZsTXgVF5BzG65ebRx5owaTfTINSafavQbIyz5dtmTlm5gR/86uVc=
CY1PR0501MB1099: X-MS-Exchange-Organization-RulesExecuted
X-Microsoft-Antispam-PRVS: <CY1PR0501MB1099C9CABAF7702A0BA73902D4850@CY1PR0501MB1099.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:CY1PR0501MB1099; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1099;
X-Forefront-PRVS: 0643BDA83C
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(479174004)(24454002)(377454003)(92566002)(23746002)(33656002)(83506001)(36756003)(65806001)(46102003)(59896002)(230783001)(66066001)(93886004)(40100003)(62966003)(77156002)(5001960100002)(2950100001)(4001350100001)(54356999)(2501003)(107886002)(77096005)(2201001)(87266999)(50466002)(87976001)(86362001)(65956001)(47776003)(76176999)(80316001)(65816999)(5001770100001)(42186005)(122386002)(189998001)(50986999)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1099; H:[172.29.32.144]; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1099; 23:qmOra6HFTFtNzXHs0xUtRoVZsYg3fZpHV+U7LzmYvPg42X41cG9x0qrtUp7loD+J2L5uv6jzy759x9aMsRvzJi+9ZpSROkDl+VugnY7Tk4ejJE6ZtLxl13jgfMb9X4ErphuQ3l86hdtjx1OZLxHNmP/Q89y7PgltrwfGFzxY/zjgb7xK23hpThy1IaBf29rO9MFkS6cooZAvj4vr/DCM9abmEawkXHKNH2LcLc2ZLy0OM93sdztFm2gdkQqNjLa1lrobBBeCzro0S1rppR5fdTsPpHUlUnIEPhnrCx8vWDZ4f0o54NzHvjVF6eHcd/EyYLS8uTSjgWSsjsLlXk1j7J3aRT7rNBb3THo1CADOCCQs4GRG01asOLqyQKuWxZ+2NPRe1yDg5sG6TwlrHJQPgZSFYkSZi7wg7OY4QA8EQ30udkOVwOQnmo6BftlJuoq3EkcXval6vpWJuT8t0Qc0aEeMbgDhDqE3YfbLixIl+1uCjQNiSO7mgZObu/GPyLU+HuB8Ytr8oiS1DHLrA5L1C+pqz1214pGQ4n5qBg5ROGIOqtgppZubplTJC0jrdAO7b2xYWYxa+1ONomy2qWHYOx3WWQ4ekoyikzQOOex+Im4cjxb0+8V+K7FSE2pbuYeW9MUjcv+WxmuPmasOFmLR7corV10ihcZE4q8nzzM+EFA+kz4rMfRbMANYmbbUrJQkXQYFXkiaOlEN7lH4BUkziuQWZscUAciL02NVqf0PCrh7Jjw8D3O8KXKReoDOuEP5eu8Fq7RD8cs1nZ3+4Pqg3+l/8o2OiVdP6fJsL54SuG8ywZmgWEbQiGQBlikcyPyBNEvwSX03luUG7tD/ruEq6YfTXeejfeUuqPUHaWA8Kb5s4TbXN2YTuyLSJOO87WCYKkzsZwIdyt69fOSEz3Y3eQFpObbZTHhaup930yVuOMTy6vdwrXZTswZH9FegOjpLLgG2tzZBdUkaJerk9hkJ3t4Iah5XUoRsMNHum0e5FgiaATZ/SF+9cpq5GE5fsF7/zRCBIXMeyNWiXzYpYpEqTg5fPl+kbWnpoi11FzWqiHgJ5QAIQTeo1Izx2f+1mWUs+TCfy2IG/aU151uKfPod+Q==
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1099; 5:uQ5DtI21X7bN3ubuAysv0SApvInAUpd6Yckzx9zzE2bYYl+wtGQ5Vi/YhPW1uzb4X17jG5/3Uktlb1fZH9GAwb7JaLVVlWk2Nihei7IJAohilMOhSD4GEyzkGjoCe9EJPB6Mtu+oulgAL6fjutXLHQ==; 24:774MGSJSBwFnHH7JF3lRkAfdyGV8tdB/kIqbcJ3dmlP4V4GIsmSnBKOtymYBFnd55zMdR6gjkA22tcCJOqQw+TVWpukWWQX3F85LyulqHxE=; 20:HA5G5X1Qx8fMtMZFQ7p0s0URNoDvRT98K5nd9cUPfDl5EVNdDCCJTsotRrU9b9aZvZEsRx6BzsSToU8gwhqtlg==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2015 18:44:03.1822 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1099
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/37K8o2VQTMILpdmG9eGi6Y9zv4o>
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 18:44:07 -0000

On 7/20/2015 2:07 PM, Shahram Davari wrote:
> The new swapped labels (The outgoing  label that replaces the
> incoming label) need to be stored in a table. Using this draft
> reduces the number of swapped labels that needs to be stored,
> regardless of  implementation. Don't you agree?

No.  If you notice that the incoming label needs to be 'replaced' by an 
outgoing label of the same value, you could just make the rewrite string 
shorter, so it won't overwrite the top label on the stack.  This seems 
to be what the draft suggests, but it could be done as an optimization 
for the particular case where the incoming and outgoing labels have the 
same value.  You could do this today, as a local implementation 
optimization. There doesn't seem to be any interop issue or any change 
to the data plane semantics.

> It also reduces the configuration and management of the new swapped labels.

We're not discussing whether there are any advantages to the use of 
domain-wide labels.  We're discussing whether the use of domain-wide 
labels requires a change in the forwarding plane architecture.  I just 
don't see that it does.