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

Andrew Qu <andrew.qu@mediatek.com> Tue, 28 July 2015 14:57 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 CED1E1AC3EE for <mpls@ietfa.amsl.com>; Tue, 28 Jul 2015 07:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.898
X-Spam-Level:
X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 e8L-esPU-WCf for <mpls@ietfa.amsl.com>; Tue, 28 Jul 2015 07:57:50 -0700 (PDT)
Received: from mailgw02.mediatek.com (unknown [66.228.70.112]) by ietfa.amsl.com (Postfix) with ESMTP id 20FFA1AC3A1 for <mpls@ietf.org>; Tue, 28 Jul 2015 07:57:47 -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 1680433605; Tue, 28 Jul 2015 10:56:16 -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; Tue, 28 Jul 2015 10:57:34 -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; Tue, 28 Jul 2015 10:57:34 -0400
From: Andrew Qu <andrew.qu@mediatek.com>
To: "stbryant@cisco.com" <stbryant@cisco.com>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Robert Raszuk <robert@raszuk.net>, Shahram Davari <davari@broadcom.com>
Thread-Topic: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?
Thread-Index: AQHQxdE8jUti3orAQEqCOvm3DZDbXZ3qQZhggAVnVgCAAAFBUIABV0UA///4lfA=
Date: Tue, 28 Jul 2015 14:57:34 +0000
Message-ID: <EA360A7AB9D90D4B9E9173B6D27C371EE3F64252@MTKMBS61N1.mediatek.inc>
References: <DB3PR03MB0780AE3E11BEA6B29B81FF5B9D810@DB3PR03MB0780.eurprd03.prod.outlook.com> <EA360A7AB9D90D4B9E9173B6D27C371EE3F60C0D@MTKMBS61N1.mediatek.inc> <55B64078.7030601@cisco.com> <EA360A7AB9D90D4B9E9173B6D27C371EE3F624BE@MTKMBS61N1.mediatek.inc> <55B7617A.90808@cisco.com>
In-Reply-To: <55B7617A.90808@cisco.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-21708.005
X-TM-AS-Result: No--9.323900-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/MAUK0B8N_w-3S2fyk0CFEqxt-To>
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: Tue, 28 Jul 2015 14:57:53 -0000

Hi Stewart,

Agreed that SWAP must be kept because MPLS fundamentals can't be broken.
And I agreed that _if_ there is NO such global label space idea,  no-swap is
optimization of swap as well. 

However I don't agree no-swap become an optimization in terms of network
Behavior when global label idea become a needed thing.


When global Label introduced, then no_swap is the conceptually right thing for the transition [even
Local implementation can use swap to achieve, again, per previous conversation,
the popular wisdom, which I agreed as well,  is that this is local implementation, we should
not get involved, so we must define no-swap as the new primitive at RFC level]


So the question really boils down to that do we need global label?

I believe that is the key thing here.  May be we can put swap/no-swap aside for the moment.

Thanks,

Andrew


-----Original Message-----
From: Stewart Bryant [mailto:stbryant@cisco.com] 
Sent: Tuesday, July 28, 2015 4:03 AM
To: Andrew Qu; Alexander Vainshtein; Robert Raszuk; Shahram Davari
Cc: mpls@ietf.org
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

> Adding "NO_SWAP" for new/future generation DEVICE does NOT break 
> backward capability.
>
Andrew

Existing devices should be assumed to have non-aligned label spaces.
(there is much empirical evidence to support this position)

So if you have a no-swap only device between two existing devices you cannot be sure that you can build an LSP.

A backwards compatible device would therefore need to support swap.

Once you support swap then no-swap become an optimization.

- Stewart


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