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 22: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 D6D881B2A3E for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 15:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.375
X-Spam-Level:
X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=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 7uL6y7i8cCmN for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 15:55:38 -0700 (PDT)
Received: from mailgw02.mediatek.com (mailgw02.mediatek.com [69.46.227.142]) by ietfa.amsl.com (Postfix) with ESMTP id CE1E81B2A3C for <mpls@ietf.org>; Thu, 23 Jul 2015 15:55:37 -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 1330832023; Thu, 23 Jul 2015 18:54:31 -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 18:55:25 -0400
From: Andrew Qu <andrew.qu@mediatek.com>
To: Shahram Davari <davari@broadcom.com>, Loa Andersson <loa@pi.nu>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Stewart Bryant <stbryant@cisco.com>, "Andrew G. Malis" <agmalis@gmail.com>, "S. Davari" <davarish@yahoo.com>
Thread-Topic: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?
Thread-Index: AQHQw8aajUti3orAQEqCOvm3DZDbXZ3pFwWwgAB2V4D///4uQIAAV4QA//+/rvA=
Date: Thu, 23 Jul 2015 22:55:24 +0000
Message-ID: <EA360A7AB9D90D4B9E9173B6D27C371EE3F608A2@MTKMBS61N1.mediatek.inc>
References: <DB3PR03MB078098C91E8D3C7DCDCCF8C39D840@DB3PR03MB0780.eurprd03.prod.outlook.com> <EA360A7AB9D90D4B9E9173B6D27C371EE3F6038F@MTKMBS61N1.mediatek.inc> <55B11D6D.2040102@pi.nu> <EA360A7AB9D90D4B9E9173B6D27C371EE3F607FB@MTKMBS61N1.mediatek.inc> <4A6CE49E6084B141B15C0713B8993F2831F7ADF4@SJEXCHMB12.corp.ad.broadcom.com>
In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2831F7ADF4@SJEXCHMB12.corp.ad.broadcom.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--63.337100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/nAOCAEU24l47H8nTwTpwVA6Jfgk>
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 22:55:41 -0000
Hi Shahram, That is not a fair question in the first place. SWAP is defined in RFC which is already Data-plane behavior, then why we purposely ignore to mention "no_swap"? why only "no_swap" is data-plane specific but not swap? To me, Swap and no_swap is a twin siblings, they come together. Missing "no_swap" in the RFC when "swap" was originally brought is mistake in the first place, We should do due diligence to correct it when it is really needed. Considering the following: 1) if NO_SWAP is additionally added but NOT breaking ANY existing framework 2) huge benefit might be potentially achieved 3) NO_SWAP is naturally coming after "SWAP" which RFC is defined in the first place. Then on what base, we should not clarify it with an incremental change document? Thanks, Andrew -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com] Sent: Friday, July 24, 2015 12:06 AM To: Andrew Qu; Loa Andersson; Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari Cc: mpls@ietf.org Subject: RE: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save? Andrew, Focusing on just the data-plane, do you agree that externally observable behavior of a router that does "no-swap" is same as "swap" to the same label. If so why do you think a standards RFC for data-plane is required? since standards RFC should be something that is externally visible outside of a box. Thanks Shahram -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Andrew Qu Sent: Thursday, July 23, 2015 2:55 PM To: Loa Andersson; Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari Cc: mpls@ietf.org Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save? It seems I mislead folks from my previous mail. Please let me rephrase my points. :-) >From a ASIC design engineer point of view, I wanted to say swap and >no-swap is Very different meaning. As long as there is a defined swap operation, I have to design the "swap" completely In ASIC logic. If there is a "no-swap" operation defined, then my ASIC engineer will implement it differently than swap. I used "TTL" and EXP handling as example. Since the label is to be "swap"ed with a new LABEL stack, then the design of SWAPING 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. And in reality, the ASIC may chose a HW adjacency storage which has complete label stack space, SW is resonspile To file them up to fulfill so called "swap" operation. When standard defines a "no-swap" operation, ASIC engineer would implement such operation completely differently in Real RTL design with regarding how to handling TTL or EXP. If I am putting NETWORK meaning aside for the moment, the wording in RFC about "swap" and "no-swap" is already making difference to inplementor already. So that is what I meant that as RFC writer, we should be as clear as possible. That is first of my points. My next point is that: As matter of fact, "no-swap" operation has huge difference in the following implementation than "swap". For example: When without "no-swap" operation defined, in order to achieve "no-swap" result, as you suggested, I would simply copy "in-label" and write it back to "out-label", but to HW, it means that for different in-label, I must use different HW adjacency to support "no-swap" result. So it will be 1-1 mapping of using adjacencies of HW resource even they share the rest of rewrite Information such out going port and DMAC/SMAC etc. However if we do have a "no-swap" operation defined, then I can share no matter of how many in-coming Label with just "ONE" HW adjacence to rewrite the in-coming packets. The adjacency instruction would simply just be "no operation on label value, decrement TTL" and using "out_port, DMAC, SMAC" for all the incoming packet with different labels. This is huge saving in terms of implementation when "no-swap" is defiend as a MPLS opearation option for a ASIC design engineer.. Lastly, I still personally believe, the network meaning of "swap" and "no-swap" can't be treated the same. As Robert pointed out, SR also has "CONTINUE" operation as well, why SR keep that operation if we thing SWAP is good to cover all cases including "CONTINUE" ? The local implementation may use the "same" way to meet two different requirements does NOT mean they Are the same, so from standard RFC point of view, we should not leave it as it is, I feel when use Case arises, we should add the clarification such as this draft to clarify. Thanks, Andrew -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Thursday, July 23, 2015 6:59 PM To: Andrew Qu; Alexander Vainshtein; Stewart Bryant; Andrew G. Malis; S. Davari Cc: mpls@ietf.org Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save? Andrew, On 2015-07-23 16:01, Andrew Qu wrote: > I don't agree no-swap is the same as "swap with same value". > > I think if standard adds a no-swap operation, that would be great for > people to implement > > Either SW or HW. > > Once the label is defined as swap, I need to consider > > 1)TTL > > Copy payload TTL ? or using const_value > > 2)QoS (pipe mode or not) > > If pipe mode => then I need to do something > > If not=> then I need to do something else. > > However if it is really a "no-swap", then it is very clear for HW/SW > to implement such operation. > > I don't need to consider any part of above cases. I've a little bit ambivalent (mostly thought this is a no go) about this draft, bur if we say that no-swap and not considering TTL and QOS, then this definitely a no go! /Loa > > I don't think swaping a same value label is NOT the same as "no-swap" > at all. > > From Standard point of view, we should NOT leave ambiguity here at all. > > Thanks, > > Andrew > > *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Alexander > Vainshtein > *Sent:* Tuesday, July 21, 2015 5:05 PM > *To:* Stewart Bryant; Andrew G. Malis; S. Davari > *Cc:* mpls@ietf.org > *Subject:* Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how > much does it really save? > > +1. > > Thumb typed on my LG, > Sasha > > ------ Original message ------ > *From: *Stewart Bryant > *Date: *21/07/2015 17:58 > *To: *Andrew G. Malis;S. Davari; > *Cc: *mpls@ietf.org <mailto:mpls@ietf.org>; > *Subject:*Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how > much does it really save? > > This draft proposes architectural changes, and as we can show that > these changes are not needed, in my view, this draft should not go > forward. > > - Stewart > > > On 21/07/2015 09:02, Andrew G. Malis wrote: > > As there are no architectural or protocol changes or IANA > considerations, this draft should be informational if it goes > forward (it currently says "standards track"). > > Cheers, > > Andy > > On Mon, Jul 20, 2015 at 8:52 PM, S. Davari <davarish@yahoo.com > <mailto:davarish@yahoo.com>> wrote: > > Eric > > I agree no standard change is required since this is a local > optimization issue. > > Regards, > Shahram > > > > On Jul 20, 2015, at 11:43 AM, Eric C Rosen <erosen@juniper.net <mailto:erosen@juniper.net>> wrote: > > > >> On 7/20/2015 2:07 PM, Shahram Davari wrote: > >> The new swapped labels (The outgoing label that replaces the > >> incoming label) need to be stored in a table. Using this draft > >> reduces the number of swapped labels that needs to be stored, > >> regardless of implementation. Don't you agree? > > > > No. 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. You could do this > today, as a local implementation optimization. There doesn't seem to > be any interop issue or any change to the data plane semantics. > > > >> It also reduces the configuration and management of the new swapped labels. > > > > We're not discussing whether there are any advantages to the use of domain-wide labels. We're discussing whether the use of domain-wide labels requires a change in the forwarding plane architecture. I just don't see that it does. > > > > _______________________________________________ > > mpls mailing list > >mpls@ietf.org <mailto:mpls@ietf.org> > >https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org <mailto:mpls@ietf.org> > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org <mailto:mpls@ietf.org> > > https://www.ietf.org/mailman/listinfo/mpls > > > > > -- > > For corporate legal information go to: > > > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > ************* 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! > > > > _______________________________________________ > 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! _______________________________________________ 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!
- [mpls] draft-fang-mpls-label-forwarding-no-swap -… Stewart Bryant
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Shahram Davari
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Eric C Rosen
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Shahram Davari
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Shahram Davari
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Eric C Rosen
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… S. Davari
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew G. Malis
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Alexander Vainshtein
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew G. Malis
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Alexander Vainshtein
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Stewart Bryant
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Alexander Vainshtein
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew Qu
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Adrian Farrel
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Alexander Vainshtein
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Stewart Bryant
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Loa Andersson
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Shahram Davari
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Robert Raszuk
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew G. Malis
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Shahram Davari
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Shahram Davari
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Robert Raszuk
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Gregory Mirsky
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Shahram Davari
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Robert Raszuk
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Robert Raszuk
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Eric C Rosen
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Shahram Davari
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Robert Raszuk
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Robert Raszuk
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Gregory Mirsky
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew Qu
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew Qu
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Shahram Davari
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Robert Raszuk
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew Qu
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Gregory Mirsky
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Alexander Vainshtein
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Xuxiaohu
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew Qu
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew Qu
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Alexander Vainshtein
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Alexander Vainshtein
- [mpls] 答复: draft-fang-mpls-label-forwarding-no-sw… Lizhenbin
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Xuxiaohu
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Robert Raszuk
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew Qu
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew Qu
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Robert Raszuk
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Eric C Rosen
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Uma Chunduri
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Jeff Tantsura
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew Qu
- Re: [mpls] 答复: draft-fang-mpls-label-forwarding-n… Eric C Rosen
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew Qu
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Robert Raszuk
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Eric C Rosen
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Robert Raszuk
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Adrian Farrel
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Adrian Farrel
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Robert Raszuk
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew G. Malis
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Robert Raszuk
- Re: [mpls] 答复: draft-fang-mpls-label-forwarding-n… Loa Andersson
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Stewart Bryant
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Eric C Rosen
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Robert Raszuk
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew Qu
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Stewart Bryant
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Robert Raszuk
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew G. Malis
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew Qu
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew Qu
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Gregory Mirsky
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Shahram Davari
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew Qu
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Alexander Vainshtein
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Adrian Farrel
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Xuxiaohu
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Stewart Bryant
- Re: [mpls] draft-fang-mpls-label-forwarding-no-sw… Andrew Qu