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

Eric C Rosen <erosen@juniper.net> Thu, 23 July 2015 21:28 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 E5A1F1ACE6F for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 14:28:01 -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 AjR8-6kHvfEU for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 14:28:00 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4470F1ACE49 for <mpls@ietf.org>; Thu, 23 Jul 2015 14:28:00 -0700 (PDT)
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;
Received: from [172.29.35.93] (66.129.241.14) by BN3PR0501MB1090.namprd05.prod.outlook.com (10.160.113.12) with Microsoft SMTP Server (TLS) id 15.1.219.17; Thu, 23 Jul 2015 21:27:58 +0000
To: Robert Raszuk <robert@raszuk.net>
References: <55AD19F2.1010206@cisco.com> <4A6CE49E6084B141B15C0713B8993F2831F73A21@SJEXCHMB12.corp.ad.broadcom.com> <55AD2DAD.4060908@juniper.net> <4A6CE49E6084B141B15C0713B8993F2831F73F3A@SJEXCHMB12.corp.ad.broadcom.com> <55AD416D.2020306@juniper.net> <CA+b+ER=nEqxiHigEFbgY9LehQMRNH8rOzQKeTQpmMrHh6_-MEA@mail.gmail.com>
From: Eric C Rosen <erosen@juniper.net>
Message-ID: <55B15C59.5040105@juniper.net>
Date: Thu, 23 Jul 2015 17:27:53 -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: <CA+b+ER=nEqxiHigEFbgY9LehQMRNH8rOzQKeTQpmMrHh6_-MEA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [66.129.241.14]
X-ClientProxiedBy: BN1PR12CA0029.namprd12.prod.outlook.com (25.160.77.39) To BN3PR0501MB1090.namprd05.prod.outlook.com (25.160.113.12)
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1090; 2:HqPxnjwCwBDQFG/ceh49WRz4lUp6sC0VC10ISeRIA0hG8xqYVKHqZHF2gZ/RqCKK; 3:RRRXAb5iNZKCweTQdU/Y+QHqhJPrrLMjt13Vaq7PBilbv+t5qP4AIsarvIcVh/f2ja1NDuwPWu0PUx4Sy3LNi8mPmiL6WsEQnK3f8r2kiQ0B9KxWgAzdc0yo75tZZ3jSM7i8+ztGGGO98cIgnieYCw==; 25:hwSp1hVSl3QjB1QwP0Hs1pTSazZnKx7gXgbvwUb8A5i6pVq8deAraRYpzbHWySxM1Scgmlj0VhO8+MbTaNlHvBSbIRpG2OVvW1ueeELfpZQS9OXHJsA/a3rD41109ao1ia0O5ZBO5IEyN0Qbs8pc3xaadBplqVc/sstFjB8rgONK5O3+yNI63wK00CiGv0bEPJ1+JK+gjgiag4VFjIHOirRtwEsgL29S5JSOqu0tPn+DpMe+WzSxySZBbx5diiO19G0LzAMB9yuhP2KvHcWghg==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1090;
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1090; 20:uVfG0RwYXB+nmqI6ekR+ACYxNEYlMDG5yHmd76dOSr2YyJ2goh6WT84a2t8Wt6y3iPFgpiYbtAtrYAylHC9Bqqd52EVYv+XXCKMqSxzfy7sGzq3eeeWrgfXrNpNsxUPLcoYDW21B9VtARRicuWhCJAyAaaZzRKCk8Lkgl5bCXfZXgKl8lP63eQXDDmD0hhI4uyYJwl+VCh+3kIjFB/tVjaQKM1ecH6h/tIDAKgLaO/8n0tcV9MOlw/X6eYxF1naABKKJfFibILUAXbJaQiWoIJd8cCxy/fAkeRVKzBHM7DyEnEz+hXAYpS8Wk0000eE/rft8s19ogehIz2wZFEQJT7Vhj0VEF4Ti/vGiir+wm/QRyZcoFitIyMfaGc/5qlbgDMOpyPE/HFrkAxXyjc5hZHLx9cCzgKu32a4YtL+NnLY72/KX+Blw0B2rsqLdWm11gZPOuefJKuQE644VV/1luGgSPfMZuu7+12VIygAWKPFjl9Rgho6wByPPxkcYUymw; 4:kgABKo07SNeLNJddygdH2xrTJ+wSr1IGoPyxLYTg30J05XCZUkp3nuihBjre5E7euiYr9l+9VIEa9c4YZqTmO8IFS1u4zOrrgxWelPtUcy6grd2b/s/lLKDUgxyloO6fqLDMeFj77vUY7KHsD0Rk9mbpuyxV6mzXK55ntHv8fi7wrqjFc48v6z4CP1WiX05Zge1NqlcGicgtDBZSjRYS0p2qVTJEhzy8lv/5h5ZRlq18Vsf3PhelnoeKsB8qEbmb5t5YsC+Y0Cut4YaIk1KAFUzOKXkuEek+4B1mKHEjiqA=
BN3PR0501MB1090: X-MS-Exchange-Organization-RulesExecuted
X-Microsoft-Antispam-PRVS: <BN3PR0501MB1090AB4A1CF665FCED069E80D4820@BN3PR0501MB1090.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:BN3PR0501MB1090; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1090;
X-Forefront-PRVS: 06469BCC91
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(5001960100002)(189998001)(4001350100001)(110136002)(46102003)(86362001)(230783001)(40100003)(62966003)(77156002)(64126003)(50466002)(122386002)(47776003)(87976001)(42186005)(80316001)(93886004)(65806001)(33656002)(77096005)(65956001)(36756003)(66066001)(2950100001)(50986999)(92566002)(87266999)(83506001)(76176999)(65816999)(23676002)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1090; H:[172.29.35.93]; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1090; 23:y0nA2E5GP0yyeEpraf7wZcZFm6tcUsTTBb4oB+mNqJV9foGH8VkQ72Gtc4ejzFow9vELhzmaY+e77zvC9+dxIbH/ihZ+YvSnypCjj2WmPWKU610+HZN/nFOTaCK4Zj1MdNy+amxcn1cu+xKtvPzh+Eh160w6fXTxQcLPmrKD5G0UnBWxdQsGXXB4oyxaPmHRCvY9Oprlez7kz1XHzuFrUMYcbeVlaATI+H1H6osGP+SAep1msLAV9OPTiCF0hTinEvERfFjFsjChn5blRzlFJBEGe+m4i8KNacl0He3ldFTixdwNa4xSI+m1k+m1yL5HkAMq+BFSoWIdgjnPK3lAFYI3sk2KDXD3ywSr52GGc/fAb19rukSHaZ1I8l5+iqHbhcZNSc3gPsVn0/LqVU4rGtG7jRBve+ydEPxQFgCWyxgVbkXuJVsPw2WatsvPoY4NytJsB7R31bVbX1C0/S7Y1mQQ4ihtfGQW4Nfj7N0vCEi7b1spDkAo5//8A1itQ/XpxlEwxk5OIe/yGeU8dCry27q5faX2LM0uhsLMKMauGbsMWgcAIt0F/n5FCpDkKty0b+eb86CjexRnhUAsiV64lyoHoMZzyax+RG6JtdDhXzfhJ5QXyEUqbQw4cezmsbHhNJOw5cQT8H4qcLMhUS5raB5u4ZecREGFSIbJvc56/olSioUi0VWHZTlpyNfF6Umtz2dyM+9NPmbuNlaEAG0i1twVqjJidv4SKGitgwSd1tKhWcaNvMX/AgjudwWF8oeREIFKRjygnFsGo6yT3lXZq0hOvRMZ46KDIepcPljBKwPDYQDBTQZDc+C8nGLtb4YKMGcbO+ty9pgRGa2C0HzF8DKM5sZVtDw8TBGsOvGQlR0t+69uICS6S+9PT0T/PVMZEQFKBONSsmOAWtQfUvATQpAmVhWHxGKgej3PlPwMYE4=
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1090; 5:EjT0WL+2rbdo6WFsmGSJ73hnWJ/zbzPrRtDe+WP0q8jo5j6bX75GNTGq51/g4PX2bMroUyEIb4icCkM8iptsQBAdCDHMxO3C8YhxKdDxt9fr2sMZbhbP4w4N2QwQMTbldxbUQnbS44rk7HMJkWp+Nw==; 24:Foy1p26CG+bpSzrlk6W+spE9UXApH+N5d9uqW8yKZjFL/zAmWz7K7B1+h/JdxqAPNIyFCBlvnDx1gXo7/658nEvtxnryumk2kM2ORxrg4eE=; 20:QRGHk98dKhRfKG6yYNTm6MyalJMB4WHziaOolk94qKT56YqoEK8cP1g58jbZGrUgysKrF+weX2gRbqyOIMjYuw==
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jul 2015 21:27:58.2139 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1090
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/fp-hbT5UAZd2Xb4bqmFc5FqJVs0>
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: Thu, 23 Jul 2015 21:28:02 -0000

> You use term "incoming label" and "outgoing label" ... well in the
> new architectures there is no such things.

The incoming label is the label on the packet when it arrives, and the
outgoing label is the label on the packet when it departs.  If a packet
arrives with a label and leaves with a label, it has an incoming label 
and an outgoing label.  I believe that even in the "new architectures", 
  packets still arrive and depart.

> So to support legacy hardware new control plane has to make up from
> single label now two (identical) labels to pass it to data plane. Now
> also data plane must be smart to check that and program its state
> per your suggestion.

I don't really understand what you are saying here.  The control plane
determines the rewrite string and causes it to be programmed into the
data plane.  There are many ways to implement this interaction.

Are you worried about the following:

> What happens if hardware vendor comes with hardware which exposes to
> control plane API which allow protocols to signal that mpls label Y
> is not to be swapped ? If so which IETF document such API would be
> compliant with ?

I don't understand this point either.  RFC 3031 does not specify an API, 
so it doesn't make any sense to ask whether a particular API is or is 
not compliant with it.