IETF Logo Mail Archive

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

Loa Andersson <loa@pi.nu> Sat, 25 July 2015 08:00 UTC

Return-Path: <loa@pi.nu>
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 94FC51A8839 for <mpls@ietfa.amsl.com>; Sat, 25 Jul 2015 01:00:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level:
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 mudgKeth04RM for <mpls@ietfa.amsl.com>; Sat, 25 Jul 2015 01:00:25 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B602E1A87ED for <mpls@ietf.org>; Sat, 25 Jul 2015 01:00:25 -0700 (PDT)
Received: from [10.0.1.78] (unknown [62.168.35.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 65C5B18013BE; Sat, 25 Jul 2015 10:00:23 +0200 (CEST)
Message-ID: <55B34210.9080107@pi.nu>
Date: Sat, 25 Jul 2015 10:00:16 +0200
From: Loa Andersson <loa@pi.nu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Eric C Rosen <erosen@juniper.net>, Lizhenbin <lizhenbin@huawei.com>, "mpls@ietf.org" <mpls@ietf.org>, Andrew Qu <andrew.qu@mediatek.com>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Shahram Davari <davari@broadcom.com>, Robert Raszuk <robert@raszuk.net>
References: <DB3PR03MB0780AE3E11BEA6B29B81FF5B9D810@DB3PR03MB0780.eurprd03.prod.outlook.com> <EA360A7AB9D90D4B9E9173B6D27C371EE3F60C0D@MTKMBS61N1.mediatek.inc> <5A5B4DE12C0DAC44AF501CD9A2B01A8D8CA1BFBE@nkgeml506-mbx.china.huawei.com> <55B25F79.1000700@juniper.net>
In-Reply-To: <55B25F79.1000700@juniper.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/FeHyFkAXlpFuWAlItDkBsHwisLE>
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: Sat, 25 Jul 2015 08:00:27 -0000

Folks,

On 2015-07-24 17:53, Eric C Rosen wrote:
> On 7/24/2015 4:40 AM, Lizhenbin wrote:
>> In fact, according to implementation, the SWAP can be seen as POP a
>> label, then PUSH a label.
>
> Certainly the architecture could have been written this way.  But it
> wasn't ;-)  It was written in such a way as to emphasize the difference
> between operations that change the size of the label stack and
> operations that do not.

In addition the intention of a pop (in most cases) is to make the next
label in the stack available to take decisions on, a swap does not do
this.

/Loa
>
> These concepts do not necessarily show up at all in the forwarding
> logic.  All the forwarding plane has to know is what the rewrite string
> is, where to put it, and how to adjust any TTL and/or checksum fields
> that might be in it.
>
>
>
>
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls

v2.23.0 | Report a Bug | By Email