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

Andrew Qu <andrew.qu@mediatek.com> Fri, 24 July 2015 15: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 E588A1A6FFE for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 08:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.975
X-Spam-Level:
X-Spam-Status: No, score=-0.975 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_42=0.6, 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 nNch-PmYznAs for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 08:55:12 -0700 (PDT)
Received: from mailgw02.mediatek.com (mailgw02.mediatek.com [69.46.227.142]) by ietfa.amsl.com (Postfix) with ESMTP id DEAC41A1A2C for <mpls@ietf.org>; Fri, 24 Jul 2015 08:55:11 -0700 (PDT)
X-Listener-Flag: 11101
Received: from mtkcas64.mediatek.inc [(172.29.17.144)] by mailgw02.mediatek.com (envelope-from <andrew.qu@mediatek.com>) (Cellopoint E-mail Firewall v3.9.12 Build 0312 with TLS) with ESMTP id 1843848804; Fri, 24 Jul 2015 11:54:00 -0500
Received: from MTKCAS63.mediatek.inc (172.29.17.143) by MTKCAS64.mediatek.inc (172.29.17.144) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 24 Jul 2015 11:54:58 -0400
Received: from MTKMBS61N1.mediatek.inc ([fe80::2898:86df:e627:42ee]) by MTKCAS63.mediatek.inc ([fe80::69ba:ee95:46f7:711d%10]) with mapi id 14.03.0181.006; Fri, 24 Jul 2015 11:54:46 -0400
From: Andrew Qu <andrew.qu@mediatek.com>
To: Jeff Tantsura <jeff.tantsura@ericsson.com>, Eric C Rosen <erosen@juniper.net>
Thread-Topic: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?
Thread-Index: AQHQw8aajUti3orAQEqCOvm3DZDbXZ3pFwWwgAB2V4D///4uQIABdXEAgAAEFYD//8NioA==
Date: Fri, 24 Jul 2015 15:54:45 +0000
Message-ID: <EA360A7AB9D90D4B9E9173B6D27C371EE3F612C5@MTKMBS61N1.mediatek.inc>
References: <DB3PR03MB078098C91E8D3C7DCDCCF8C39D840@DB3PR03MB0780.eurprd03.prod.outlook.com> <EA360A7AB9D90D4B9E9173B6D27C371EE3F6038F@MTKMBS61N1.mediatek.inc> <55B11D6D.2040102@pi.nu> <EA360A7AB9D90D4B9E9173B6D27C371EE3F607FB@MTKMBS61N1.mediatek.inc>, <55B2552A.80702@juniper.net> <5365D2B8-E3A1-4C25-85B4-C82CDE03090B@ericsson.com>
In-Reply-To: <5365D2B8-E3A1-4C25-85B4-C82CDE03090B@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.17.249]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-Product-Ver: SMEX-10.2.0.3176-8.000.1202-21698.005
X-TM-AS-Result: No--17.435300-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/4m_HBOJdHR4aNq5HrpqezJscAec>
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: Fri, 24 Jul 2015 15:55:15 -0000

Experience should have taught us that we should strive to get our doc/standard written as
clear as possible and don't count on our involvement to get things straight.

With due respect, I hope that all experienced folks can learn from bad experiences.

Thanks,

Andrew

-----Original Message-----
From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] 
Sent: Friday, July 24, 2015 5:24 PM
To: Eric C Rosen
Cc: Andrew Qu; Loa Andersson; Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari; mpls@ietf.org
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

Experience talks ;-)

Would be really great to get quantification.

Regards,
Jeff

On Jul 24, 2015, at 5:09 PM, Eric C Rosen <erosen@juniper.net> wrote:

>> When standard defines a "no-swap" operation,  ASIC engineer would 
>> implement such operation completely differently
> 
> Well, this is where we came in.  The RFCs do not dictate how the ASICs 
> should be designed, and your ASIC designers are free to design in 
> whatever way best meets the needs of the systems that are going to use 
> those ASICs.  You can put in any optimizations you think are warranted.  If you expect the ASICs to be used in products that will never need to swap label values, never need to push labels, never need to pop labels, then you are free to design the ASICs without any of these features.  If you think that these operations are needed, but that "don't change the label value or the stack size" are the most common operations, you can certainly optimize your design for that case.
> 
> But if you think you can get the ASICs designed properly simply by handing the RFCs to the ASIC designers, you may be in for an unpleasant surprise.
> 
>> Since the label is to be "swap"ed with a new LABEL stack, then the 
>> design of SWAPPING need to consider TTL handling such as 1) just 
>> decrement of original TTL or 2) using a brand new TTL, such as using 
>> local new register stored value to Fill the sawp'ed new label stack.
> 
> The TTL handling is exactly the same for both cases.  If you have been telling your ASIC designers something different, you most definitely are in for an unpleasant surprise.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
************* Email Confidentiality Notice ********************
The information contained in this e-mail message (including any 
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be 
conveyed only to the designated recipient(s). Any use, dissemination, 
distribution, printing, retaining or copying of this e-mail (including its 
attachments) by unintended recipient(s) is strictly prohibited and may 
be unlawful. If you are not an intended recipient of this e-mail, or believe 
that you have received this e-mail in error, please notify the sender 
immediately (by replying to this e-mail), delete any and all copies of 
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!