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

From: Linda Dunbar <[email-masked]>
Date: Fri, 17 Jan 2020 00:31:14 +0000

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

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 17 Jan 2020 00:13:35 -0500

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-masked]>
wrote:

> “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-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 17 Jan 2020 00:37:57 -0500

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 <[email-masked]> wrote:

> 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

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: "Francois Clad (fclad)" <[email-masked]>
Date: Mon, 20 Jan 2020 16:27:30 +0000

Dear Linda,

Thank you for your email.

Please see inline.

Thanks,
Francois

From: Linda Dunbar <[email-masked]>
Date: Friday 17 January 2020 at 01:31
To: "[email-masked]" <[email-masked]>
Cc: SPRING WG <[email-masked]>
Subject: Can features described by draft-ietf-spring-sr-service-programming-01 be supported by draft-ietf-spring-srv6-network-programming-08?

“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 is by including a service SID in the SID-list that you can steer packets through the network function associated with this service SID. Regarding your specific example, if you add service SIDs in a SID-list that already contains other types of SIDs (e.g., topological ones), then it will indeed make your SID-list longer.

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?

While you may be able to perform some basic service chaining with the functionalities defined in other drafts, many service chaining use-cases require more than that. For example, some service chaining use-cases involve legacy network functions (SR-unaware) that are not able to process an SR packet (SR-MPLS or SRv6) or the usage of metadata. draft-ietf-spring-sr-service-programming defines the additional data plane procedures and protocol extensions to support these use cases for both SR-MPLS and SRv6.

Depending on the use-case and the behavior, the inner payload can be Ethernet, IPv4, IPv6, or a transport layer header.

ENH is an old terminology that is really the Upper-layer header type (inner payload type). The same applies to value 59, which should be changed to “TBD1” from draft-ietf-spring-srv6-network-programming until the appropriate value is assigned by IANA. Thank you for raising that point. We will correct that in the next revision of the draft.

Thank you very much,

Linda Dunbar