Hi Linda Those are good questions which I have similar and will try to answer your questions as best I can as my interpretation.
So the SRv6 programming draft provides the End.x variant instantiation of the end SID where the destination IP is the local interface. So that is in regards to normal outer header Hop by hop traffic steering (A1,A2) where A1 is source and A2 is destination and SRH is (S3,S2,S1) and SL=<S1,S2,S3> and S1 is first segment and S3 is the ultimate segment. So with this services SID which I agree is very confusing is a case where you have a firewall or LB or some type of SFC that had to happen so now you traffic steering path does incur few extra SIDs that go outside the SR egress PE construct to an “SR aware” services endpoint L(S) where L is the egress PE and now you have a few extra SID hops steered to the service. Since the service is within the SR domain context dataplane but outside the SR domain flow ingress PE to egress PE ; service hanging off the egress PE the SR programming only reflects End.x Sid instantiation and since this service is local to the egress PE to SR capable node I am guessing that is why there is different treatment and it’s not considered end.x Sid variant instantiation. Let’s call Z the services SID hops (A1,A2) where A1 is source and A2 is destination and SRH is (S3,S2,S1,Z3,Z2,Z1) and SL=<S1,S2,S3,Z1,Z2,Z3) No doubt very confusing. I think if the ingress SRv6 source node SRH is steering the entire path to the services SID it gets questionable and maybe the SRv6 programming needs to add End.x Sid variant instantiation for the extra hops off the egress PE to the services SID. I am thinking maybe the egress PE could make the decision that SFC service is needed and not the ingress PE SR source node ; and then it does simplify the MSD SID depth issue length of the SRH ; and so we would terminate on the egress PE ; and then we would have a new 6in6 encapsulation with new SRH literally identical to performing TI-LFA at the PLR node. I thin the ENH is same as EH extended header in 6.1.2. Authors What do you think of my proposal? Gyan On Thu, Jan 16, 2020 at 7:31 PM Linda Dunbar <[email protected]> wrote: > Authors of draft-ietf-spring-sr-service-programming-01: > > > > “draft-ietf-spring-sr-service-programming” specifies Service SIDs to be > embedded into the SID list. Does it make the SID list even longer? For > example, if a packet needs to be steered through the network by 3 SIDs > (S1, S2, S3), Service SIDs will be the additional SIDs to be added to the > packet header? > > > > It seems straight forward for draft-ietf-spring-srv6-network-programming > to add an instruction to forward the packet to a specific service > Function. Why not using draft-ietf-spring-srv6-network-programming to > steer packets to specific service functions? > > What features specified by draft-ietf-spring-sr-service-programming that > can’t be achieved by draft-ietf-spring-srv6-network-programming? > > > > Some minor questions: What is the ENH in Section 6.1.2? You have ENH = > 59, ENH = 4, Are you talking the Ethernet frames being encapsulated by > SRH header? > > The inner payload are IP frames, aren’t they? > > > > Thank you very much, > > > > Linda Dunbar > > > > > > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: [email protected]
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
