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 14:01 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 7EC791A1AA7 for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 07:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.974
X-Spam-Level:
X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 o9-wHR-hrk33 for <mpls@ietfa.amsl.com>; Thu, 23 Jul 2015 07:01:31 -0700 (PDT)
Received: from mailgw01.mediatek.com (mailgw01.mediatek.com [69.46.227.141]) by ietfa.amsl.com (Postfix) with ESMTP id A1DB31A038D for <mpls@ietf.org>; Thu, 23 Jul 2015 07:01:30 -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 625931396; Thu, 23 Jul 2015 10:01:17 -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 10:01:17 -0400
From: Andrew Qu <andrew.qu@mediatek.com>
To: 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: AQHQw8aajUti3orAQEqCOvm3DZDbXZ3pFwWw
Date: Thu, 23 Jul 2015 14:01:16 +0000
Message-ID: <EA360A7AB9D90D4B9E9173B6D27C371EE3F6038F@MTKMBS61N1.mediatek.inc>
References: <DB3PR03MB078098C91E8D3C7DCDCCF8C39D840@DB3PR03MB0780.eurprd03.prod.outlook.com>
In-Reply-To: <DB3PR03MB078098C91E8D3C7DCDCCF8C39D840@DB3PR03MB0780.eurprd03.prod.outlook.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--60.564900-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_EA360A7AB9D90D4B9E9173B6D27C371EE3F6038FMTKMBS61N1media_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/e997nZPvImbLz_qyWvdySUABXU4>
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 14:01:34 -0000

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 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