Subject: Re: [spring] [SPRING] Query related to SR Architecture

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 9 Sep 2015 16:45:00 +0000

Hi Gaurav,

Looks like you are asking the routers to forward looking at the second innermost label and not the topmost label. This does NOT fit into the MPLS architecture. I am not sure it fits SR-IPV6 architecture or not, but I doubt.

Looks like your requirement is that each node on shortest path to the final destination (indicated by the bottom-most Node-segment) provide some service. In this regard, can you be specific about wether all the nodes will provide the same service or different service? It does not make sense to me for all the transit nodes to execute the same service on the packet. So if they are not required to provide the same service on each transit node, question is how one service label will be enough to indicate which specific service will need to be executed at each node.

Hope you have gone through SFC drafts already.

Thanks
-Pushpasis

From: spring on behalf of Gaurav agrawal
Date: Wednesday, September 9, 2015 at 6:09 PM
To: Alexander Vainshtein
Cc: "Anil Kumar S N (VRP Network BL)", "[email-masked]<mailto:[email-masked]>", "[email-masked]<mailto:[email-masked]>", Vinod Kumar S 70786
Subject: Re: [spring] [SPRING] Query related to SR Architecture

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: [email-masked]<mailto:[email-masked]>
Huawei Technologies Co., Ltd.

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, September 09, 2015 5:01 PM
To: Gaurav agrawal
Cc: Anil Kumar S N (VRP Network BL); Vinod Kumar S 70786; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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:   [email-masked]<mailto:[email-masked]>

From: spring [mailto:[email-masked]] On Behalf Of Gaurav agrawal
Sent: Wednesday, September 09, 2015 1:38 PM
To: [email-masked]<mailto:[email-masked]>
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: [email-masked]<mailto:[email-masked]>
Huawei Technologies Co., Ltd.

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Thu, 10 Sep 2015 12:47:38 +0000

Hi Pushpasis,

                Thanks a lot for replying.

                The requirement is still under research stage once it is in a presentable format  will share the details.
we need every node on the path to perform the same service, we could even define a service globally and allocate one label to it which is understandable by all.

                Technically it must be possible right, as top label specifies to service once that service is performed then refer ILM/NHLFE table for forwarding and if service label says before sending out the packet push the label back on the stack.
                The Egress device will finally pop both service and node label.

Hope you are refering to with respect to SFC https://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02”

                As per below section a node label and service lable combination has to be pushed for each hop if the service is intended to  be performed by each node on the path to destination.
                If there is any metadata involved for service NSH has to be piggybacked in the packet. SFC don’t solve in reducing number of labels involved.

        The service classifier therefore would attach a
        segment list {SID(SN1), SID(SF1), SID(SN2), SID(SF2)} to the packet.
        This segment list is actually represented by a MPLS label stack.  In
        addition, the service classifier could optionally impose metadata on
        the packet through the Network Service Header (NSH)

Thanks & Regards
Anil S N

“Be liberal in what you accept, and conservative in what you send” - Jon Postel

From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: 10 September 2015 00:45
To: Gaurav agrawal; Alexander Vainshtein
Cc: Anil Kumar S N (VRP Network BL); [email-masked]; [email-masked]; Vinod Kumar S 70786
Subject: Re: [spring] [SPRING] Query related to SR Architecture

Hi Gaurav,

Thanks
-Pushpasis

Dear Alexander,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

Gaurav,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 10 Sep 2015 14:45:19 +0000

Hi Anil,

From: "Anil Kumar S N (VRP Network BL)"
Date: Thursday, September 10, 2015 at 6:17 PM
To: Pushpasis Sarkar, Gaurav agrawal, Alexander Vainshtein
Cc: "[email-masked]<mailto:[email-masked]>", "[email-masked]<mailto:[email-masked]>", Vinod Kumar S 70786
Subject: RE: [spring] [SPRING] Query related to SR Architecture

Hi Pushpasis,

                The requirement is still under research stage once it is in a presentable format  will share the details.
we need every node on the path to perform the same service, we could even define a service globally and allocate one label to it which is understandable by all.
[Pushpasis] First, it does not make sense to me why all the nodes on the path will execute the same service on the payload? It would make more sense that they do different services on different node. Can you illustrate with an example?  Second, If they all are providing the same service, why need a separate service label?

                Technically it must be possible right, as top label specifies to service once that service is performed then refer ILM/NHLFE table for forwarding and if service label says before sending out the packet push the label back on the stack.
[Pushpasis] In MPLS architecture, labels are always of local significance. So the global service label you are talking about MUST be actually a label allocated by the first hop node who has allocated the specific label for the service. Even the Node Segment Label the ingress will use to push the packet is allocated by the first hop node.

                As per below section a node label and service lable combination has to be pushed for each hop if the service is intended to  be performed by each node on the path to destination.
                If there is any metadata involved for service NSH has to be piggybacked in the packet. SFC don’t solve in reducing number of labels involved.
[Pushpasis] I agree. Perhaps we need to find a different solution.

Thanks
-Pushpasis

Thanks & Regards
Anil S N

Cc: Anil Kumar S N (VRP Network BL); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Vinod Kumar S 70786

Hi Gaurav,

Thanks
-Pushpasis

Dear Alexander,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

Gaurav,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Thu, 10 Sep 2015 15:26:02 +0000

Pushpasis,

                Thank you again, Please see inline [Anil >>].

Thanks & Regards
Anil S N

From: spring [mailto:[email-masked]] On Behalf Of Pushpasis Sarkar
Sent: 10 September 2015 20:15
To: Anil Kumar S N (VRP Network BL); Gaurav agrawal; Alexander Vainshtein
Cc: [email-masked]; [email-masked]; Vinod Kumar S 70786
Subject: Re: [spring] [SPRING] Query related to SR Architecture

Hi Anil,

Hi Pushpasis,

[Anil >>] What did you meant by “Second, If they all are providing the same service, why need a separate service label? ”.  What we meant is the case where 10 different services need to be performed by every hop based on based on received service label in the SR packet.

                Technically it must be possible right, as top label specifies to service once that service is performed then refer ILM/NHLFE table for forwarding and if service label says before sending out the packet push the label back on the stack.
[Pushpasis] In MPLS architecture, labels are always of local significance. So the global service label you are talking about MUST be actually a label allocated by the first hop node who has allocated the specific label for the service. Even the Node Segment Label the ingress will use to push the packet is allocated by the first hop node.
[Anil >>]  pushing local service label originated by immediate nexthop before transmitting will serve the purpose , each node will push new local service label based on the nexthop as a last step after processing service label & node label.
we want service label on the top of the stack.

                As per below section a node label and service lable combination has to be pushed for each hop if the service is intended to  be performed by each node on the path to destination.
                If there is any metadata involved for service NSH has to be piggybacked in the packet. SFC don’t solve in reducing number of labels involved.
[Pushpasis] I agree. Perhaps we need to find a different solution.
[Anil >>]  By having service label at the top will solve label stack issues in some cases.

would like to know technical issues involved in having service label as top label, Please help us.

Thanks
-Pushpasis

Thanks & Regards
Anil S N

Hi Gaurav,

Thanks
-Pushpasis

Dear Alexander,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

Gaurav,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 10 Sep 2015 15:42:28 +0000

Hi Anil,

Inline again

From: "Anil Kumar S N (VRP Network BL)"
Date: Thursday, September 10, 2015 at 8:56 PM
To: Pushpasis Sarkar, Gaurav agrawal, Alexander Vainshtein
Cc: "[email-masked]<mailto:[email-masked]>", "[email-masked]<mailto:[email-masked]>", Vinod Kumar S 70786
Subject: RE: [spring] [SPRING] Query related to SR Architecture

Pushpasis,

Thanks & Regards
Anil S N

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Vinod Kumar S 70786

Hi Anil,

Hi Pushpasis,

[Anil >>] What did you meant by “Second, If they all are providing the same service, why need a separate service label? ”.  What we meant is the case where 10 different services need to be performed by every hop based on based on received service label in the SR packet.
[PS2] Ok. So what you are saying is… Each node is capable of N number services. The service label is to only indicate which one it is. Right? It is still not clear why the same service needs to be executed on each transit node.

[PS2] You mean ingress will put the service label and node segment label and send it to first hop. Then first hop will pop the service label, execute the service, look at the next node label and then add the same service label along with node segment label advertised by the second hop for the final destination. And so on. Right? This sounds to convoluted to me.

[PS2] I don’t think so. Once again I don’t get why all transit nodes need to execute the same service again and again on the same payload? Have you considered the case where 3 (say) different service needs to be applied at the three different service nodes and then finally forwarded to destination? How will you specify three different services without three different service labels?

Thanks
-Pushpasis

Thanks
-Pushpasis

Thanks & Regards
Anil S N

Hi Gaurav,

Thanks
-Pushpasis

Dear Alexander,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

Gaurav,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Sep 2015 17:46:26 +0200

Hi Anil,

Another possibility here would be to allocate not 1 but 10 SR labels for a
given segment and embed the service notion in it. For 10 services I think
the scale is ok. Perhaps for 1000 services this could bring label space
scaling concerns, but this is very specific to particular deployment.

That way on the packet you will have label stack of 1 label (not two) and
have at the imposition point 10 labels getting the packets to particular SR
node/link while also transporting the information about service selection
to be performed at each service aware transit or SR node.

Best,
R.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 10 Sep 2015 16:16:07 +0000

Hi Pushpasis, Anil,

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 10, 2015 at 11:42 AM
To: "Anil Kumar S N (VRP Network BL)" <[email-masked]<mailto:[email-masked]>>, Gaurav agrawal <[email-masked]<mailto:[email-masked]>>, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Vinod Kumar S 70786 <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] [SPRING] Query related to SR Architecture

Hi Anil,

Inline again

Pushpasis,

Thanks & Regards
Anil S N

Hi Anil,

Hi Pushpasis,

Clearly convoluted. Even if the desired behavior is applicable to every node, this represents a unique MPLS forwarding paradigm. It is similar to stitching LSPs but not identical.  Before introducing something like this, the MPLS WG would have to consider implementation implications, partial deployment, and backward compatibility versus the benefits of the limited use cases.

Thanks,
Acee

Thanks
-Pushpasis

Thanks
-Pushpasis

Thanks & Regards
Anil S N

Hi Gaurav,

Thanks
-Pushpasis

Dear Alexander,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

Gaurav,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Thu, 10 Sep 2015 17:04:04 +0000

Hi Acee,

    Thanks for your inputs. I might be wrong, correct me if i am.

        Each node can advertise two different types service label for a same service.
        a)  Service label after poping it, perform the service continue  with forwarding (current case)
        b)  New kind of service label after poping it, perform/schedule the service and before forwarding push back the neighbors local service label.

Will this have backward compatibility issue ? as we are attaching more meaning to a service label which is new.
(new kind of service label processing will be done only be capable nodes who understand this new label type, capability must be exchanged to support backward compatibility)

Implementation implications : I could foresee one difficulty but need communities opinion
                                                        The top label which is a special service label will be swapped with peer's service label but only after forwarding decision is made.

Partial development : This i am not sure at this point of time, i will definitely check with with our product team and get back to you ASAP.

With Regards
Anil S N
________________________________
From: spring [[email-masked]] on behalf of Acee Lindem (acee) [[email-masked]]
Sent: Thursday, September 10, 2015 9:46 PM
To: Pushpasis Sarkar; Anil Kumar S N (VRP Network BL); Gaurav agrawal; Alexander Vainshtein
Cc: [email-masked]; [email-masked]; Vinod Kumar S 70786
Subject: Re: [spring] [SPRING] Query related to SR Architecture

Hi Pushpasis, Anil,

Hi Anil,

Inline again

Pushpasis,

Thanks & Regards
Anil S N

Hi Anil,

Hi Pushpasis,

Thanks,
Acee

Thanks
-Pushpasis

Thanks
-Pushpasis

Thanks & Regards
Anil S N

Hi Gaurav,

Thanks
-Pushpasis

Dear Alexander,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

Gaurav,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Sep 2015 13:11:14 -0400

Anil,
     The task of using MPLS for carrying service chaining can be 
addressed in multiple ways without making odd assumptions or changing 
MPLS semantics.
     First, please, do not assume that "all nodes deliver the same 
service".  that is not the model being used by IETF SFC nor by ETSI NFV.
     Second, there are at least two different ways to use MPLS as an SFC 
transport across multiple service functions without violating the 
existing MPLS architecture.  One could use MPLS Spring, for example 
using the proposal from Xuxiaohu as a trqnsport.  One could also use an 
MPLS LSP that traverses several Service function forwarders and service 
functions.  This could be done either with MPLS support on the Service 
Function, or with service functions which simply preserve the MPLS 
header, and the service function forwarders take care of the remapping 
that is part of MPLS.  Either of these preserve the MPLS architecture 
that the local node forwards only based on the top label.

     If one wants to preserve an MPLS label that is external to the 
service chaining system, that is probably best done via interaction with 
the ingress and egress systems.  If one is certain that the entire 
domain supports MPLS, one could keep the external stack, but have 
special processing at the ingress and egress of the SFC domain for 
adding and removing the NSH header, but personally I would not recommend 
that approach.

Yours,
Joel

On 9/10/15 1:04 PM, Anil Kumar S N (VRP Network BL) wrote:
>          b)  New kind of service label after poping it, perform/schedule
> the service and before forwarding push back the neighbors local service
> label.
>
> (new kind of service label processing will be done only be capable nodes
> who understand this new label type, capability must be exchanged to
> support backward compatibility)
>
>                                                          The top label
> which is a special service label will be swapped with peer's service
> label but only after forwarding decision is made.
>
> Partial development : This i am not sure at this point of time, i will
> definitely check with with our product team and get back to you ASAP.
>
> With Regards
> Anil S N
> ------------------------------------------------------------------------
> *From:* spring [[email-masked]] on behalf of Acee Lindem (acee)
> [[email-masked]]
> *Sent:* Thursday, September 10, 2015 9:46 PM
> *To:* Pushpasis Sarkar; Anil Kumar S N (VRP Network BL); Gaurav agrawal;
> Alexander Vainshtein
> *Cc:* [email-masked]; [email-masked]; Vinod Kumar S 70786
> *Subject:* Re: [spring] [SPRING] Query related to SR Architecture
>
> Hi Pushpasis, Anil,
>
> From: spring <[email-masked] <mailto:[email-masked]>>
> on behalf of Pushpasis Sarkar <[email-masked]
> <mailto:[email-masked]>>
> To: "Anil Kumar S N (VRP Network BL)" <[email-masked]
> <mailto:[email-masked]>>, Gaurav agrawal <[email-masked]
> <mailto:[email-masked]>>, Alexander Vainshtein
> <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>, Vinod Kumar S 70786
> <[email-masked] <mailto:[email-masked]>>
>     Cc: "[email-masked] <mailto:[email-masked]>", "[email-masked]
>     <mailto:[email-masked]>", Vinod Kumar S 70786
>                      Thank you again, Please see inline */[Anil >>]/*.
>
>     Thanks & Regards
>
>     Anil S N
>
>     *From:*spring [mailto:[email-masked]] *On Behalf Of
>     *Pushpasis Sarkar
>     *Sent:* 10 September 2015 20:15
>     *To:* Anil Kumar S N (VRP Network BL); Gaurav agrawal; Alexander
>     Vainshtein
>     *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; Vinod Kumar S 70786
>     *Subject:* Re: [spring] [SPRING] Query related to SR Architecture
>
>     Hi Anil,
>
>     *From: *"Anil Kumar S N (VRP Network BL)"
>     *Date: *Thursday, September 10, 2015 at 6:17 PM
>     *To: *Pushpasis Sarkar, Gaurav agrawal, Alexander Vainshtein
>     *Cc: *"[email-masked] <mailto:[email-masked]>", "[email-masked]
>     <mailto:[email-masked]>", Vinod Kumar S 70786
>     *Subject: *RE: [spring] [SPRING] Query related to SR Architecture
>
>     Hi Pushpasis,
>
>                      The requirement is still under research stage once
>     it is in a presentable format  will share the details.
>
>     we need every node on the path to perform the same service, we could
>     even define a service globally and allocate one label to it which is
>     understandable by all.
>
>     [Pushpasis] First, it does not make sense to me why all the nodes on
>     the path will execute the same service on the payload? It would make
>     more sense that they do different services on different node. Can
>     you illustrate with an example?  Second, If they all are providing
>     the same service, why need a separate service label?
>
>     */[Anil >>] /**What did you meant by **“**Second, If they all are
>     providing the same service, why need a separate service label?
>     **”**.  What we meant is the case where 10 different services need
>     to be performed by every hop based on based on received service
>     label in the SR packet.*
>
>     [PS2] Ok. So what you are saying is… Each node is capable of N
>     number services. The service label is to only indicate which one it
>     is. Right? It is still not clear why the same service needs to be
>     executed on each transit node.
>
>     **
>
>                      Technically it must be possible right, as top label
>     specifies to service once that service is performed then refer
>     ILM/NHLFE table for forwarding and if service label says before
>     sending out the packet push the label back on the stack.
>
>     [Pushpasis] In MPLS architecture, labels are always of local
>     significance. So the global service label you are talking about MUST
>     be actually a label allocated by the first hop node who has
>     allocated the specific label for the service. Even the Node Segment
>     Label the ingress will use to push the packet is allocated by the
>     first hop node.
>
>     */[Anil >>]  pushing local service label originated by immediate
>     nexthop before transmitting will serve the purpose , each node will
>     push new local service label based on the nexthop as a last step
>     after processing service label & node label./*
>
>     */we want service label on the top of the stack./*
>
>     [PS2] You mean ingress will put the service label and node segment
>     label and send it to first hop. Then first hop will pop the service
>     label, execute the service, look at the next node label and then add
>     the same service label along with node segment label advertised by
>     the second hop for the final destination. And so on. Right? This
>     sounds to convoluted to me.
>
>
> Clearly convoluted. Even if the desired behavior is applicable to every
> node, this represents a unique MPLS forwarding paradigm. It is similar
> to stitching LSPs but not identical.  Before introducing something like
> this, the MPLS WG would have to consider implementation implications,
> partial deployment, and backward compatibility versus the benefits of
> the limited use cases.
>
> Thanks,
> Acee
>
>
>
>
>
>     *//*
>
>     Hope you are refering to with respect to SFC
>     https://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02”
>
>                      As per below section a node label and service lable
>     combination has to be pushed for each hop if the service is intended
>     to  be performed by each node on the path to destination.
>
>                      If there is any metadata involved for service NSH
>     has to be piggybacked in the packet. SFC don’t solve in reducing
>     number of labels involved.
>
>     */[Anil >>]  By having service label at the top will solve label
>     stack issues in some cases./*
>
>     [PS2] I don’t think so. Once again I don’t get why all transit nodes
>     need to execute the same service again and again on the same
>     payload? Have you considered the case where 3 (say) different
>     service needs to be applied at the three different service nodes and
>     then finally forwarded to destination? How will you specify three
>     different services without three different service labels?
>
>     Thanks
>     -Pushpasis
>
>     *//*
>
>     *//*
>
>     */would like to know technical issues involved in having service
>     label as top label, Please help us./*
>
>     Thanks
>
>     -Pushpasis
>
>     *From:*Pushpasis Sarkar [mailto:[email-masked]]
>     *Sent:* 10 September 2015 00:45
>     *To:* Gaurav agrawal; Alexander Vainshtein
>     *Cc:* Anil Kumar S N (VRP Network BL); [email-masked]
>     <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;
>     Vinod Kumar S 70786
>     *Subject:* Re: [spring] [SPRING] Query related to SR Architecture
>
>     Hi Gaurav,
>
>     Looks like you are asking the routers to forward looking at the
>     second innermost label and not the topmost label. This does NOT fit
>     into the MPLS architecture. I am not sure it fits SR-IPV6
>     architecture or not, but I doubt.
>
>     Looks like your requirement is that each node on shortest path to
>     the final destination (indicated by the bottom-most Node-segment)
>     provide some service. In this regard, can you be specific about
>     wether all the nodes will provide the same service or different
>     service? It does not make sense to me for all the transit nodes to
>     execute the same service on the packet. So if they are not required
>     to provide the same service on each transit node, question is how
>     one service label will be enough to indicate which specific service
>     will need to be executed at each node.
>
>     *From: *spring on behalf of Gaurav agrawal
>     *Date: *Wednesday, September 9, 2015 at 6:09 PM
>     *To: *Alexander Vainshtein
>     *Cc: *"Anil Kumar S N (VRP Network BL)", "[email-masked]
>     <mailto:[email-masked]>", "[email-masked] <mailto:[email-masked]>",
>     Vinod Kumar S 70786
>     *Subject: *Re: [spring] [SPRING] Query related to SR Architecture
>
>     Dear Alexander,
>
>     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:
>
>     With this we needn’t repeat the service label for each transit node
>     thereby making the SR Label stack COMPACT.
>
>     Company_logo
>     Email: [email-masked] <mailto:[email-masked]>
>
>     *From:*Alexander Vainshtein [mailto:[email-masked]]
>     *Sent:* Wednesday, September 09, 2015 5:01 PM
>     *To:* Gaurav agrawal
>     *Cc:* Anil Kumar S N (VRP Network BL); Vinod Kumar S 70786;
>     [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     *Subject:* RE: [SPRING] Query related to SR Architecture
>
>     Gaurav,
>
>     Email: [email-masked]
>     <mailto:[email-masked]>
>
>     *From:*spring [mailto:[email-masked]] *On Behalf Of *Gaurav
>     agrawal
>     *Sent:* Wednesday, September 09, 2015 1:38 PM
>     *To:* [email-masked] <mailto:[email-masked]>
>     *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: [email-masked] <mailto:[email-masked]>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 10 Sep 2015 18:31:05 +0000

Hi Anil,

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 10, 2015 at 1:04 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>, Gaurav agrawal <[email-masked]<mailto:[email-masked]>>, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Vinod Kumar S 70786 <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] [SPRING] Query related to SR Architecture

Hi Acee,

In MPLS, one label is like any other label (except for the first 15 which are reserved). I think you are missing a whole lot of context here - you can’t just declare a new label type with different semantics.

I do not wish to get into a protracted discussion on a proposal that is unlikely to be adopted. Independent of your product requirements, a standardized solution will need to address this point one way or another.

Acee

With Regards
Anil S N
From: spring [[email-masked]<mailto:[email-masked]>] on behalf of Acee Lindem (acee) [[email-masked]<mailto:[email-masked]>]

Hi Pushpasis, Anil,

Hi Anil,

Inline again

Pushpasis,

Thanks & Regards
Anil S N

Hi Anil,

Hi Pushpasis,

Thanks,
Acee

Thanks
-Pushpasis

Thanks
-Pushpasis

Thanks & Regards
Anil S N

Hi Gaurav,

Thanks
-Pushpasis

Dear Alexander,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

Gaurav,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Sep 2015 20:38:17 +0200

​Hey Acee,
​

> In MPLS, one label is like any other label (except for the first 15 which
> are reserved). I think you are missing a whole lot of context here - you
> can’t just declare a new label type with different semantics.
>

​That is actually quite incorrect :)  We do declare new semantics for
labels all the time ... ​

Few examples:

- context label
- entropy label
- sr label
etc...

​Cheers,
R​

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 10 Sep 2015 18:44:27 +0000

Hi Robert,

On Sep 10, 2015, at 2:38 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

​Hey Acee,
​

​That is actually quite incorrect :)  We do declare new semantics for labels all the time ... ​

Few examples:

- context label
- entropy label
- sr label
etc…

But the mechanisms for advertising the label semantics as such must be specified as well.

Thanks,
Acee

​Cheers,
R​

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 Sep 2015 20:49:17 +0200

> But the mechanisms for advertising the label semantics as such must

I don't think so ... in the age of SDN those can be one time pushed
from controller to network element as example.

Those can also be configured by hand.

Especially if we are talking domian/global label values.

Cheers,
R.

On Thu, Sep 10, 2015 at 8:44 PM, Acee Lindem (acee) <[email-masked]> wrote:
> Hi Robert,
>
> On Sep 10, 2015, at 2:38 PM, Robert Raszuk <[email-masked]> wrote:
>
> Hey Acee,
>
>>
> That is actually quite incorrect :)  We do declare new semantics for labels
> all the time ...
>
> Few examples:
>
> - context label
> - entropy label
> - sr label
> etc…
>
>
> Cheers,
> R

---

From: "Anil Kumar S N (VRP Network BL)" <[email-masked]>
Date: Thu, 10 Sep 2015 18:49:06 +0000

Thanks a lot Acee/Alexander/pushpasis & Joel for answering our query.

Since the idea of having service label as top label is breaking MPLS/SR architecture we don't want to proceed with that idea.
We just hoped this would reduce label stack size :)

Thank you all so much for your time.
Anil S N
________________________________
From: spring [[email-masked]] on behalf of Robert Raszuk [[email-masked]]
Sent: Friday, September 11, 2015 12:08 AM
To: Acee Lindem (acee)
Cc: [email-masked]; Gaurav agrawal; Alexander Vainshtein; Vinod Kumar S 70786; [email-masked]; Anil Kumar S N (VRP Network BL); Pushpasis Sarkar
Subject: Re: [spring] [mpls] [SPRING] Query related to SR Architecture

​Hey Acee,
​

Few examples:

- context label
- entropy label
- sr label
etc...

​Cheers,
R​

---

From: Gaurav agrawal <[email-masked]>
Date: Tue, 15 Sep 2015 10:12:29 +0000

Dear Acee,

While going through the MRT Architecture draft, we found that a special label called Topology-Id Label is defined and carried as a top label in label stack, followed by FEC Label.
Also the operation as per MRT Draft is similar to our query.

Request your opinion on same.

Our Original Query
“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.”

Reference: https://tools.ietf.org/html/draft-ietf-rtgwg-mrt-frr-architecture-06
6.1.1.2<https://tools.ietf.org/html/draft-ietf-rtgwg-mrt-frr-architecture-06#section-6.1.1.2>.  Topology and FEC encoded using a two label stack (Option 1B)
   With this forwarding mechanism, a two label stack is used to encode
   the topology and the FEC of the packet.  The top label (topology-id
   label) identifies the MRT forwarding topology, while the second label
   (FEC label) identifies the FEC.  The top label would be a new FEC
   type with two values corresponding to MRT Red and Blue topologies.

   When an MRT transit router receives a packet with a topology-id
   label, the router pops the top label and uses that it to guide the
   next-hop selection in combination with the next label in the stack
   (the FEC label).  The router then swaps the FEC label, using the FEC-
   label bindings learned through normal LDP mechanisms.  The router
  then pushes the topology-id label for the next-hop.

   As with Option 1A, this forwarding mechanism also has the useful
   property that the FEC associated with the packet is maintained in the
   labels at each hop along the MRT.

   This forwarding mechanism has minimal usage of additional labels,
   memory and LDP communication.  It does increase the size of packets
   and the complexity of the required label operations and look-ups.

   This forwarding option is consistent with context-specific label
   spaces, as described in [RFC 5331<https://tools.ietf.org/html/rfc5331>].  However, the precise LDP
   behavior required to support this option for MRT has not been
   specified.

Gaurav Agrawal
[Company_logo]

Phone: 0124-4774700 Ext- 85756
Mobile: +91-7838700296
Email: [email-masked]<mailto:[email-masked]>
Delhi, India
Huawei Technologies Co., Ltd.

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Friday, September 11, 2015 12:01 AM
To: Anil Kumar S N (VRP Network BL); Pushpasis Sarkar; Gaurav agrawal; Alexander Vainshtein
Cc: [email-masked]; [email-masked]; Vinod Kumar S 70786
Subject: Re: [spring] [SPRING] Query related to SR Architecture

Hi Anil,

Hi Acee,

Acee

With Regards
Anil S N

Hi Anil,

Inline again

Pushpasis,

Thanks & Regards
Anil S N

Hi Anil,

Hi Pushpasis,

Thanks,
Acee

Thanks
-Pushpasis

Thanks
-Pushpasis

Thanks & Regards
Anil S N

Hi Gaurav,

Thanks
-Pushpasis

Dear Alexander,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

Gaurav,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 15 Sep 2015 17:53:12 +0000

If you have a way to make the binding known throughout the MPLS domain (and yes, this can be via a controllor) and the routers  in LSP path know how to perform the forwarding behavior you have described, then it will work. However, there are partial deployment considerations that need to be addressed. You probably should discuss this with your colleagues active in the MPLS WG. There was also the comment that there are other ways to accomplish this.
Thanks,
Acee

From: Gaurav agrawal <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 15, 2015 at 6:12 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, "Anil Kumar S N (VRP Network BL)" <[email-masked]<mailto:[email-masked]>>, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Vinod Kumar S 70786 <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] [SPRING] Query related to SR Architecture

Dear Acee,

Our Original Query

Gaurav Agrawal
[Company_logo]

Hi Anil,

Hi Acee,

Acee

With Regards
Anil S N

Hi Anil,

Inline again

Pushpasis,

Thanks & Regards
Anil S N

Hi Anil,

Hi Pushpasis,

Thanks,
Acee

Thanks
-Pushpasis

Thanks
-Pushpasis

Thanks & Regards
Anil S N

Hi Gaurav,

Thanks
-Pushpasis

Dear Alexander,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

Gaurav,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

---

From: Gaurav agrawal <[email-masked]>
Date: Wed, 16 Sep 2015 06:18:54 +0000

Thanks Acee for the clarification.

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Tuesday, September 15, 2015 11:23 PM
To: Gaurav agrawal; Anil Kumar S N (VRP Network BL); Pushpasis Sarkar; Alexander Vainshtein
Cc: [email-masked]; [email-masked]; Vinod Kumar S 70786
Subject: Re: [spring] [SPRING] Query related to SR Architecture

Dear Acee,

Our Original Query

Gaurav Agrawal
[Company_logo]

Hi Anil,

Hi Acee,

Acee

With Regards
Anil S N

Hi Anil,

Inline again

Pushpasis,

Thanks & Regards
Anil S N

Hi Anil,

Hi Pushpasis,

Thanks,
Acee

Thanks
-Pushpasis

Thanks
-Pushpasis

Thanks & Regards
Anil S N

Hi Gaurav,

Thanks
-Pushpasis

Dear Alexander,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296

Gaurav,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Hi,

Thanks and Regards,
Gaurav Agrawal
[Company_logo]

Mobile: +91-7838700296