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

Andrew Qu <andrew.qu@mediatek.com> Thu, 23 July 2015 21:55 UTC

Return-Path: <andrew.qu@mediatek.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 685361ACEAE for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 14:55:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.574
X-Spam-Level:
X-Spam-Status: No, score=-1.574 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 hQTztPu1fF5O for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 14:55:27 -0700 (PDT)
Received: from mailgw01.mediatek.com (mailgw01.mediatek.com [69.46.227.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9206B1ACE70 for <mpls@ietf.org>; Thu, 23 Jul 2015 14:55:27 -0700 (PDT)
X-Listener-Flag: 11101
Received: from mtkcas64.mediatek.inc [(172.29.17.144)] by mailgw01.mediatek.com (envelope-from <andrew.qu@mediatek.com>) (Cellopoint E-mail Firewall v3.9.12 Build 0312 with TLS) with ESMTP id 1816274339; Thu, 23 Jul 2015 17:55:14 -0500
Received: from MTKMBS61N1.mediatek.inc ([fe80::2898:86df:e627:42ee]) by MTKCAS64.mediatek.inc ([::1]) with mapi id 14.03.0181.006; Thu, 23 Jul 2015 17:55:14 -0400
From: Andrew Qu <andrew.qu@mediatek.com>
To: "Andrew G. Malis" <agmalis@gmail.com>, Shahram Davari <davari@broadcom.com>
Thread-Topic: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?
Thread-Index: AQHQw8aajUti3orAQEqCOvm3DZDbXZ3pFwWwgAB2V4CAAAU1gIAANmiA///OMUA=
Date: Thu, 23 Jul 2015 21:55:13 +0000
Message-ID: <EA360A7AB9D90D4B9E9173B6D27C371EE3F60806@MTKMBS61N1.mediatek.inc>
References: <DB3PR03MB078098C91E8D3C7DCDCCF8C39D840@DB3PR03MB0780.eurprd03.prod.outlook.com> <EA360A7AB9D90D4B9E9173B6D27C371EE3F6038F@MTKMBS61N1.mediatek.inc> <55B11D6D.2040102@pi.nu> <4A6CE49E6084B141B15C0713B8993F2831F7A156@SJEXCHMB12.corp.ad.broadcom.com> <CAA=duU1oKDWn5wWtunfUffQR5HSGBqaOh_+aMZbDkTBQXLHVKQ@mail.gmail.com>
In-Reply-To: <CAA=duU1oKDWn5wWtunfUffQR5HSGBqaOh_+aMZbDkTBQXLHVKQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.17.249]
x-tm-as-product-ver: SMEX-10.2.0.3176-8.000.1202-21698.005
x-tm-as-result: No--55.164700-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_EA360A7AB9D90D4B9E9173B6D27C371EE3F60806MTKMBS61N1media_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/5wal_mnB4RefA6BoRXojn0D4D6o>
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:55:29 -0000

Hi Andy,

I believe it is RFC author’s duty to make RFC as clear as possible so that reader/implementation engineer to be clear
About the intent of authors.

In addition to what I brought up in my previous mail about the huge saving in HW resources when if on paper we have
Additional “no-swap” operation added to existing MPLS operation, I believe we should define “no-swap” first,
Let implementation folks to decide whether use “swap” operation logic to achieve “no-swap” or use specific
Way of achieving that.

Why RFC authors dictate the “real implementation” ?  all we need is just the “final compliant” result, however
“no-swap” is simply different than “swap”, why we ignore the fundamental difference.

Thanks,

Andrew

From: Andrew G. Malis [mailto:agmalis@gmail.com]
Sent: Thursday, July 23, 2015 10:33 PM
To: Shahram Davari
Cc: Loa Andersson; Andrew Qu; Alexander Vainshtein; Stewart Bryant; S. Davari; mpls@ietf.org
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Sharam,

The point was made during the meeting that on the wire, "no swap" (but still decrement TTL, etc.) is indistinguishable from "swap to the same label". So this really is a local optimization in the switch, and not subject to standardization.

Cheers,
Andy

On Thu, Jul 23, 2015 at 7:18 PM, Shahram Davari <davari@broadcom.com<mailto:davari@broadcom.com>> wrote:
I thought the idea was to decrement TTL and consider EXP bits for queuing and count as a hop so you can do OAM, etc.. Basically swap to itself.

Thx
Shahram