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

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Fri, 24 July 2015 08:31 UTC

Return-Path: <Alexander.Vainshtein@ecitele.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 9B4531A1A1E for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 01:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, 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 6C-0Cob2jyan for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 01:31:27 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0783.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::783]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1034A1A019B for <mpls@ietf.org>; Fri, 24 Jul 2015 01:31:27 -0700 (PDT)
Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0777.eurprd03.prod.outlook.com (10.161.54.27) with Microsoft SMTP Server (TLS) id 15.1.219.17; Fri, 24 Jul 2015 08:31:05 +0000
Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0219.018; Fri, 24 Jul 2015 08:31:05 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Xuxiaohu <xuxiaohu@huawei.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: AQHQxesURLWhMNTKB0OPv6fwBySQ6Q==
Date: Fri, 24 Jul 2015 08:31:05 +0000
Message-ID: <DB3PR03MB0780C71D3CF8426A5CA06C1F9D810@DB3PR03MB0780.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Infraware POLARIS Mobile Mailer v2.5
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [79.178.225.212]
x-microsoft-exchange-diagnostics: 1; DB3PR03MB0777; 5:DjlyeBXB9V1xm7SSx4xlg/gqAuDjJLbBiqEZ26ibEoqA3iJHsVCttX7wKR9kXKo3Sf90uZoacp7d3xysylmjiIkXpkDA/jlb2JkPr5PgnjGjO52xar5ZRUbWTfVOl/8rvTfB6kQkGjlaFzMFohDCIg==; 24:+fx6e6C826NDBTU3zQNE8uYwCr/PQ7Khpz7DKuLUaMoCxltuZZnbxhFPYDR44RCLV1CRsb37gknGsoYYivFdnV9U8es9BNs/VFp84KScjrg=; 20:Lrx8Ve5oqOTYdcSb3aFLIJM0FXS8PjKHK7uprSTzMLtGTt0EpzEkH6Aw6kN3TNb/V4dEjS8os1kCULSQmdxE8g==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0777;
db3pr03mb0777: X-MS-Exchange-Organization-RulesExecuted
x-microsoft-antispam-prvs: <DB3PR03MB077712D5FF0AA39C63D006619D810@DB3PR03MB0777.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR03MB0777; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0777;
x-forefront-prvs: 0647963F84
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51444003)(479174004)(24454002)(377454003)(53754006)(16236675004)(74316001)(50226001)(122556002)(106116001)(230783001)(189998001)(66066001)(5001770100001)(19580405001)(5001960100002)(5002640100001)(19580395003)(19625215002)(19617315012)(561944003)(5001920100001)(77156002)(40100003)(76576001)(33656002)(2900100001)(2656002)(50986999)(15975445007)(77096005)(92566002)(5003600100002)(46102003)(102836002)(62966003)(86362001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0777; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0780C71D3CF8426A5CA06C1F9D810DB3PR03MB0780eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2015 08:31:05.4200 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0777
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/Uk8axADex3rcOXtbLhECow8QyJ8>
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 08:31:31 -0000

Xiaohu hi!



First of all I think that you are asking the right question:-( .



This said I think that the answer to this question is NO.



I do not see why anycast segment in SR would require global labels - could you please elaborate?



Thumb typed on my LG,
Sasha

------ Original message ------
From: Xuxiaohu
Date: 24/07/2015 10:49
To: 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?


Hi all,



Before considering the possible MPLS forwarding optimization for global labels (a.k.a., domain-wide labels), should we firstly legalize the usage of global labels within the MPLS community? BTW, I believe global labels would be very useful and neccessary in some use cases, such as anycast segment.



Best regards,

Xiaohu

________________________________
发件人: mpls [mpls-bounces@ietf.org] 代表 Alexander Vainshtein [Alexander.Vainshtein@ecitele.com]
发送时间: 2015年7月24日 13:26
收件人: Robert Raszuk; Shahram Davari
抄送: mpls@ietf.org
主题: 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.



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