Re: [spring] Can features described by draft-ietf-spring-sr-service-programming-01 be supported by draft-ietf-spring-srv6-network-programming-08?

[Gyan Mishra <[e-mail]>]

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 <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]