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 protected]] on behalf of Acee Lindem (acee)
[[email protected]]
*Sent:* Thursday, September 10, 2015 9:46 PM
*To:* Pushpasis Sarkar; Anil Kumar S N (VRP Network BL); Gaurav agrawal;
Alexander Vainshtein
*Cc:* [email protected]; [email protected]; Vinod Kumar S 70786
*Subject:* Re: [spring] [SPRING] Query related to SR Architecture
Hi Pushpasis, Anil,
From: spring <[email protected] <mailto:[email protected]>>
on behalf of Pushpasis Sarkar <[email protected]
<mailto:[email protected]>>
Date: Thursday, September 10, 2015 at 11:42 AM
To: "Anil Kumar S N (VRP Network BL)" <[email protected]
<mailto:[email protected]>>, Gaurav agrawal <[email protected]
<mailto:[email protected]>>, Alexander Vainshtein
<[email protected] <mailto:[email protected]>>
Cc: "[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>, "[email protected] <mailto:[email protected]>"
<[email protected] <mailto:[email protected]>>, Vinod Kumar S 70786
<[email protected] <mailto:[email protected]>>
Subject: Re: [spring] [SPRING] Query related to SR Architecture
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 protected] <mailto:[email protected]>", "[email protected]
<mailto:[email protected]>", Vinod Kumar S 70786
Subject: RE: [spring] [SPRING] Query related to SR Architecture
Pushpasis,
Thank you again, Please see inline */[Anil >>]/*.
Thanks & Regards
Anil S N
“Be liberal in what you accept, and conservative in what you send” -
Jon Postel
*From:*spring [mailto:[email protected]] *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 protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>; 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 protected] <mailto:[email protected]>", "[email protected]
<mailto:[email protected]>", Vinod Kumar S 70786
*Subject: *RE: [spring] [SPRING] Query related to SR Architecture
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.
[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
*//*
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.
[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./*
[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
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 protected]]
*Sent:* 10 September 2015 00:45
*To:* Gaurav agrawal; Alexander Vainshtein
*Cc:* Anil Kumar S N (VRP Network BL); [email protected]
<mailto:[email protected]>; [email protected] <mailto:[email protected]>;
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.
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 protected]
<mailto:[email protected]>", "[email protected] <mailto:[email protected]>",
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 protected] <mailto:[email protected]>
Huawei Technologies Co., Ltd.
*From:*Alexander Vainshtein [mailto:[email protected]]
*Sent:* Wednesday, September 09, 2015 5:01 PM
*To:* Gaurav agrawal
*Cc:* Anil Kumar S N (VRP Network BL); Vinod Kumar S 70786;
[email protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>
*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 protected]
<mailto:[email protected]>
*From:*spring [mailto:[email protected]] *On Behalf Of *Gaurav
agrawal
*Sent:* Wednesday, September 09, 2015 1:38 PM
*To:* [email protected] <mailto:[email protected]>
*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 protected] <mailto:[email protected]>
Huawei Technologies Co., Ltd.
_______________________________________________
mpls mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mpls
