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

Loa Andersson <loa@pi.nu> Thu, 23 July 2015 16:59 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 0FB4B1B29A9 for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 09:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level:
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, 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 wqY39l2G3DZz for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 09:59:37 -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 D32F01B29A8 for <mpls@ietf.org>; Thu, 23 Jul 2015 09:59:34 -0700 (PDT)
Received: from [31.133.139.48] (unknown [31.133.139.48]) (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 B64ED18013E2; Thu, 23 Jul 2015 18:59:31 +0200 (CEST)
Message-ID: <55B11D6D.2040102@pi.nu>
Date: Thu, 23 Jul 2015 18:59:25 +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: Andrew Qu <andrew.qu@mediatek.com>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Stewart Bryant <stbryant@cisco.com>, "Andrew G. Malis" <agmalis@gmail.com>, "S. Davari" <davarish@yahoo.com>
References: <DB3PR03MB078098C91E8D3C7DCDCCF8C39D840@DB3PR03MB0780.eurprd03.prod.outlook.com> <EA360A7AB9D90D4B9E9173B6D27C371EE3F6038F@MTKMBS61N1.mediatek.inc>
In-Reply-To: <EA360A7AB9D90D4B9E9173B6D27C371EE3F6038F@MTKMBS61N1.mediatek.inc>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/YvvQrEuLkquESsOjMdQqDZeoVzM>
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 16:59:40 -0000

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
>