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

Uma Chunduri <uma.chunduri@ericsson.com> Fri, 24 July 2015 15:11 UTC

Return-Path: <uma.chunduri@ericsson.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 4C65C1A87C8 for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 08:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 1lrwUpI4c3Ye for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 08:11:02 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96021A86E9 for <mpls@ietf.org>; Fri, 24 Jul 2015 08:11:01 -0700 (PDT)
X-AuditID: c6180641-f794d6d000001dfb-12-55b1ed5e16cf
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8F.11.07675.E5DE1B55; Fri, 24 Jul 2015 09:46:38 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Fri, 24 Jul 2015 11:11:00 -0400
From: Uma Chunduri <uma.chunduri@ericsson.com>
To: Robert Raszuk <robert@raszuk.net>, Andrew Qu <andrew.qu@mediatek.com>
Thread-Topic: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?
Thread-Index: AQHQxfI/fvsQkGpJDkaQAeGwc+n1tJ3qncyAgAAZipA=
Date: Fri, 24 Jul 2015 15:10:59 +0000
Message-ID: <1B502206DFA0C544B7A6046915200863512A7A89@eusaamb105.ericsson.se>
References: <DB3PR03MB0780AE3E11BEA6B29B81FF5B9D810@DB3PR03MB0780.eurprd03.prod.outlook.com> <EA360A7AB9D90D4B9E9173B6D27C371EE3F60C0D@MTKMBS61N1.mediatek.inc> <5A5B4DE12C0DAC44AF501CD9A2B01A8D8CA1BFBE@nkgeml506-mbx.china.huawei.com> <EA360A7AB9D90D4B9E9173B6D27C371EE3F60E6A@MTKMBS61N1.mediatek.inc> <CA+b+ERn27-9sqy4peL0REgDaQLu9woOZKJs_X1H9fy_A110-kQ@mail.gmail.com>
In-Reply-To: <CA+b+ERn27-9sqy4peL0REgDaQLu9woOZKJs_X1H9fy_A110-kQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.12]
Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A6046915200863512A7A89eusaamb105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonRDfu7cZQg1OfpC32L/zHbnFr6UpW i6aFTcwOzB5Llvxk8mg5uZ/FY/fGBUwBzFFcNimpOZllqUX6dglcGVPfr2Iq2LKMpWLH5ndM DYwTZrB0MXJySAiYSPy9dZUJwhaTuHBvPVsXIxeHkMBRRon3s6+xQzjLGSUWbzgG1sEmoCfx cepPdhBbRMBT4s60d0BxDg5mAWWJU3dlQMLCAnESh9ZtZYQoiZfo2dXNCFIiImAl8WRGCEiY RUBVYs3S/WwgNq+Ar8St9XtZIFb9ZJL4enEDM0iCUyBQYsr792DHMQId9/3UGjCbWUBc4taT +VBHC0gs2XOeGcIWlXj5+B8rhK0kMef1NWaI+nyJb61LWSGWCUqcnPmEZQKj6Cwko2YhKZuF pGwW2GeaEut36UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0VI0dpcWpZbrqR4SZGYKwdk2Bz3MG4 4JPlIUYBDkYlHt4F2htDhVgTy4orcw8xSnOwKInzSvvlhQoJpCeWpGanphakFsUXleakFh9i ZOLglGpgNBGcoS8/7a7GEpEXKzKjOhX5gu2fP3p3P2F5afOJh3ZpHtzPPy3RO/E8M3Pd4+f1 izJlhN31N4W1/Ama9Wb2ltyM0Kg5S2zKBWbfsBbUcjbW3Xll0kfDPn/WKSvkT6yZf6vlXJHQ DUPfx24OJ/bMeR+1Jzj/0sK8L6dKJmTNTOPdN9Pj5CurxUosxRmJhlrMRcWJABG1YJGWAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/A4VSPnztZrlkwEqLq6W6JIgsOQk>
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:11:06 -0000


From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Friday, July 24, 2015 2:30 AM
To: Andrew Qu
Cc: mpls@ietf.org
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?


Another way to look at this is that SWAP requires awarness of peer's labels either by flooding, by p2p protocol like LDP or via learning to controller and pushing it back in p2mp fashion.

NO_SWAP does not have such dependency. It can be educated about just endpoint label mapping from controller and actual forwarding and adj creation will be local based on the vanilla IGP SPF.

To me this is fundamental difference.

[Uma]: Absolutely. And the need for NO_SWAP/CONTINUE kind of semantic was never needed earlier in 3031.
FWIW, It’s good  to define  a single term for this rather than per application (SR/HSDN etc..).

Cheers,
R.


On Fri, Jul 24, 2015 at 11:21 AM, Andrew Qu <andrew.qu@mediatek.com<mailto:andrew.qu@mediatek.com>> wrote:
Agreed!   From networking point of view,  no_swap and swap is simply different fundamentally.  We should address that.

Thanks,

Andrew


From: Lizhenbin [mailto:lizhenbin@huawei.com<mailto:lizhenbin@huawei.com>]
Sent: Friday, July 24, 2015 10:40 AM
To: mpls@ietf.org<mailto:mpls@ietf.org>; Andrew Qu; Alexander Vainshtein; Shahram Davari; Robert Raszuk
Subject: 答复: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?


Hi all,

I think the concept is one hand, the implementation is another hand. I would like to clarify more about it.

1. Now all of us debates if there is NO_SWAP. I want to ask one question: Should there be SWAP? In fact, according to implementation, the SWAP can be seen as POP a label, then PUSH a label.

If so, POP and PUSH is enough. Why is there SWAP.

2. For the NO_SWAP, as the introduction of H-SDN and Segment Routing, at least in concept, there should introduce one new label operation. Regarding the implementation you can use SWAP same label, or POP one label and PUSH the same label if you like. There is also the possible way introduced in the draft-fang-mpls-label-forwarding-no-swap.



In addition I would like to propose the suggestion that a totally new term for the NO_SWAP label operation should be introduced such as CONTINUE, GO, DIRECTGO, etc. Why must we make it related with the existing the label operations?





Best Regards,

Zhenbin(Robin)

















________________________________
发件人: mpls [mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>] 代表 Andrew Qu [andrew.qu@mediatek.com<mailto:andrew.qu@mediatek.com>]
发送时间: 2015年7月24日 16:06
收件人: Alexander Vainshtein; Robert Raszuk; Shahram Davari
抄送: mpls@ietf.org<mailto:mpls@ietf.org>
主题: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?
Hi Sasha,


My comments in lines…




From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Friday, July 24, 2015 7:26 AM
To: Robert Raszuk; Shahram 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?


Hi all,

Please note that CONTINUE in SPRING is:

1. A DP-agnostic primitive

2. *Implemented* as SWAP instruction with MPLS DP.



[Andrew]  You are contradicting with 1) and 2).

With “CONTINUE” defined in SR draft,  for NEW ASIC to be designed,

Why should I still use “SWAP” to achieve it? Considering that I might

Have good saving in precious on-board memory for the ASIC ?



You can suggest that using SWAP, however you said CONTINUE is DP-agnostic, then

If I do it different, I am still standard compliant. RIGHT?



Again,  that is exactly my point,  SWAP is NOT the same as “NO_SWAP”.  Once you put

The wording out there,  it WILL have different impact.



Thanks,



Andrew









So claiming equivalence of CONTINUE and NO-SWAP seems to be inaccurate IMO.



As for global labels (in SDN, MPLS-TP or any other technology) - this definitely looks to me like a very bad idea for networks comprised of devices that support different label ranges. From my experience these scenarios have been encountered in real MPLS-TP deployments  and resulted in eventually dropping the "simple" solution as live networks have been extended with new NEs supporting a more narrow label space than the original ones.



Adding a new forwarding primitive to MPLS architecture (yet another argument on this thread) immediately raises the question:



Is support of the new primitive mandatory?



If it is not (and this is clearly the case for NO-SWAP), then why should we bother? Occam's rasor cuts this off IMHO.



My personal bottom line: this is a strictly NO GO proposal.



My 2c.


Thumb typed on my LG,
Sasha

------ Original message ------
From: Robert Raszuk
Date: 24/07/2015 00:22
To: Shahram 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?

The point is that new control plane is already defined. In fact we already have two :)

As I mentioned in my first mail to the list the concept of NO_SWAP/CONTINUE is common to both H-SDN and SEGMENT ROUTING architectures.

Ref: https://goo.gl/3oxRbl

Thx,
R.


On Thu, Jul 23, 2015 at 11:16 PM, Shahram Davari  <davari@broadcom.com<mailto:davari@broadcom.com>> wrote:
Robert,

So instead of calling it no-swap probably you should call it global label or so, and then define new control plane for it. But seems the data-pane behavior does not change and existing hardware can support this global label.  So maybe you just need new control plane.

Thx
Shahram

From: rraszuk@gmail.com<mailto:rraszuk@gmail.com> [mailto:rraszuk@gmail.com<mailto:rraszuk@gmail.com>] On Behalf Of Robert Raszuk
Sent: Thursday, July 23, 2015 2:12 PM
To: Shahram Davari
Cc: Eric C Rosen; stbryant@cisco.com<mailto:stbryant@cisco.com>; mpls@ietf.org<mailto:mpls@ietf.org>

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



Hi Shahram,

Labels which are non of a local significance can be distributed by flooding protocols extensions (ISIS, OSPF) or by direct p2p sessions (BGP 3107, sessions from the controller, XMPP etc ...)

The important part is that the actual forwarding is computed recursively or set at the controller.

AFAIK I have not seen any proposal where LDP would play any role in such distribution.

Regards,
R.





On Thu, Jul 23, 2015 at 11:07 PM, Shahram Davari <davari@broadcom.com<mailto:davari@broadcom.com>> wrote:
Hi Robert,

How are these labels distributed? Via LDP or via SDN controller?

Thanks
Shahram

From: rraszuk@gmail.com<mailto:rraszuk@gmail.com> [mailto:rraszuk@gmail.com<mailto:rraszuk@gmail.com>] On Behalf Of Robert Raszuk
Sent: Thursday, July 23, 2015 12:58 PM
To: Eric C Rosen
Cc: Shahram Davari; stbryant@cisco.com<mailto:stbryant@cisco.com>; mpls@ietf.org<mailto:mpls@ietf.org>
Subject: Re: [mpls] draft-fang-mpls-label-forwarding-no-swap - how much does it really save?

​Hi Eric,​

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

​This is precisely ​the crux where your statement fails.

You use term "incoming label" and "outgoing lable" ... well in the new architectures there is no such things.

It is a "global label" or "path label" with adjacency information.

So to support legacy hardware new control plane has to make up from single label now two (identical) labels to pass it to data plane. Now also data plane must be smart to check that and program its state per your suggestion.

Why would we do that other then due to worry about legacy chipsets feared to be non compliant to new RFC ?

Many thx,
R.




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



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