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]>]

Authors

If the SR source node steers the flow to the services SFC being rendered on
a firewall etc and if that entire path is now encoded into the SRH then I
think the service SID end.x variant instantiation should be added to SRV6
programming draft.

Does the service have to be an SR aware service and what is the benefit.  I
guess programmability from a PCE centralized model.  Any other benefits as
it does add complexity and exacerbates SID depth issue.

Instead of the service SID being extra SID hops steered by the SR source
node could the end.x Sid instantiation on the egress PE ultimate segment
have special “SFC encoding” in the function or argument field of the SID
IID 64 bit portion.

The function encoded could state “firewall SFC needs to be rendered”  ;
perform 6in6 encapsulation with new SRH and steer the flow to the service
endpoint.

The SR source node would have the knowledge that services are needed and I
think encoding the SFC in the ultimate segment egress PE would signal
egress PE to now steer the flow to the service SID endpoint.

Kind regards

Gyan

On Fri, Jan 17, 2020 at 12:13 AM Gyan Mishra <[e-mail]> wrote:

>
> 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]
>
>
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]