IETF Logo Mail Archive

Re: [mpls] [SPRING] Query related to SR Architecture

Gaurav agrawal <gaurav.agrawal@huawei.com> Wed, 09 September 2015 12:39 UTC

Return-Path: <gaurav.agrawal@huawei.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 136DD1A9103; Wed, 9 Sep 2015 05:39:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 vff8Ql5SwfkS; Wed, 9 Sep 2015 05:39:46 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473891A8AFA; Wed, 9 Sep 2015 05:39:45 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXK36965; Wed, 09 Sep 2015 12:39:43 +0000 (GMT)
Received: from SZXEMI404-HUB.china.huawei.com (10.82.75.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Sep 2015 13:39:38 +0100
Received: from SZXEMI502-MBX.china.huawei.com ([169.254.5.238]) by SZXEMI404-HUB.china.huawei.com ([10.82.75.40]) with mapi id 14.03.0235.001; Wed, 9 Sep 2015 20:39:28 +0800
From: Gaurav agrawal <gaurav.agrawal@huawei.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Thread-Topic: [SPRING] Query related to SR Architecture
Thread-Index: AdDq65ivSlkcrVwiTI617CwiZGO4PQABzFLAAAFUH3A=
Date: Wed, 09 Sep 2015 12:39:28 +0000
Message-ID: <2F2059F256F9B24F82EAC5EE47F446C6B0134BAA@szxemi502-mbx.china.huawei.com>
References: <2F2059F256F9B24F82EAC5EE47F446C6B0134B3A@szxemi502-mbx.china.huawei.com> <DB3PR03MB0780CFBEDF2DB23373B340849D520@DB3PR03MB0780.eurprd03.prod.outlook.com>
In-Reply-To: <DB3PR03MB0780CFBEDF2DB23373B340849D520@DB3PR03MB0780.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.20.132.129]
Content-Type: multipart/related; boundary="_004_2F2059F256F9B24F82EAC5EE47F446C6B0134BAAszxemi502mbxchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/Xb7EvxJJAvWwxhLkqYKMPUlQ0n4>
Cc: "Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com>, "spring@ietf.org" <spring@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, Vinod Kumar S 70786 <v70786@notesmail.huawei.com.cn>
Subject: Re: [mpls] [SPRING] Query related to SR Architecture
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: Wed, 09 Sep 2015 12:39:50 -0000

Dear Alexander,

Thanks for your inputs. Let me further elaborate on the subject.

The requirement is to make every node on the path to destination to perform a specific service(Service could be anything).

Currently Service label can only follow a Node Label, because of which to let every node perform same service, SR Label stack expects to have node and service label for each transit node, this results in huge label stack.

If we can push a service label prior to node label & each intermediate node can perform below operation:
1) Pop Service Label & perform/schedule the service.
2) Decide the further forwarding based on Node Label
3) Push the service label back to stack.

With this we needn't repeat the service label for each transit node thereby making the SR Label stack COMPACT.

We can derive many optimized implementation by having this.

So, we would like to hear from You and MPLS/SPRING community about our view point.

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296
Email: gaurav.agrawal@huawei.com<mailto:gaurav.agrawal@huawei.com>
Huawei Technologies Co., Ltd.

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, September 09, 2015 5:01 PM
To: Gaurav agrawal
Cc: Anil Kumar S N (VRP Network BL); Vinod Kumar S 70786; spring@ietf.org; mpls@ietf.org
Subject: RE: [SPRING] Query related to SR Architecture

Gaurav,
Not sure I understand the context for your requirement.
But to the best of my understanding your requirement does not match MPLS architecture.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Gaurav agrawal
Sent: Wednesday, September 09, 2015 1:38 PM
To: spring@ietf.org
Cc: Anil Kumar S N (VRP Network BL); Vinod Kumar S 70786
Subject: [spring] [SPRING] Query related to SR Architecture

Hi,

We would like to have a label stack with only two labels such a way that service label is a top label  and the bottom label would be SR destination node label. This is to make sure each intermediate node perform the specified service based on the top label while reaching the destination.
We would appreciate if anyone could clarify whether SR architecture could allow a service label to be a top label in a label stack.

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296
Email: gaurav.agrawal@huawei.com<mailto:gaurav.agrawal@huawei.com>
Huawei Technologies Co., Ltd.

v2.23.0 | Report a Bug | By Email