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

Robert Raszuk <robert@raszuk.net> Thu, 23 July 2015 19:58 UTC

Return-Path: <rraszuk@gmail.com>
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 B3F201A00F9 for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 12:58:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 i9HoIJySlWGn for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 12:58:10 -0700 (PDT)
Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8C31A1B23 for <mpls@ietf.org>; Thu, 23 Jul 2015 12:58:10 -0700 (PDT)
Received: by ykax123 with SMTP id x123so2634782yka.1 for <mpls@ietf.org>; Thu, 23 Jul 2015 12:58:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iXws1bLF5zbzwFSq1tYL5hIftreV7KIGR9qYa8egLug=; b=BjANImSyhpKhXDABlVfskT54hsuxNOi2vucS/ACGIBfuC6p8WIJwCFD8Lry2dAVkjj ClkidK72ZVanh/ZoCb8Y0YabPUm5ykmp5TNjQmdxh49jNuISDptv2/fjvFTvNB3fMPxu 7hziIi4Blv+6GIAuW56ELXv8gP3Fz0fAqHFGezGOyxK7Dly4ksxbMbSz+7gqqiL/Qklr KxGAj5NBUW6yb5aNtEJen5f83OSdcw5CbHtcnvSqGKBpet5vvmKEE7PaaI+B5uggX593 Hkogp9Poiote44Lc7C0vqFgOoE/mwl+Ey1MLHL1LjPq0rYX8rxL+EOBT/WSHiU36mtEj QUCQ==
MIME-Version: 1.0
X-Received: by 10.170.128.8 with SMTP id u8mr7305352ykb.32.1437681489880; Thu, 23 Jul 2015 12:58:09 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.129.40.137 with HTTP; Thu, 23 Jul 2015 12:58:09 -0700 (PDT)
In-Reply-To: <55AD416D.2020306@juniper.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>
Date: Thu, 23 Jul 2015 21:58:09 +0200
X-Google-Sender-Auth: LWO4G6Nmc4FBYvQ4Uf7xupnelZM
Message-ID: <CA+b+ER=nEqxiHigEFbgY9LehQMRNH8rOzQKeTQpmMrHh6_-MEA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: Eric C Rosen <erosen@juniper.net>
Content-Type: multipart/alternative; boundary=001a1138f354812d6f051b904e9f
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/AaXkZmdz4kvhvTiMm76jtqMrOdU>
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 19:58:11 -0000

​Hi Eric,​


> ​​
> 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.


​This is precisely ​the crux where your statement fails.

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

It is a "global label" or "path label" with adjacency information.

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.

Why would we do that other then due to worry about legacy chipsets feared
to be non compliant to new RFC ?

Many thx,
R.