Subject: Re: [spring] Per segment service instructions

From: "Bernier, Daniel" <[email-masked]>
Date: Sat, 14 Sep 2019 05:03:23 +0000

Hi Ron,

If PSSI provide non-routing services such as SE1 from Robert’s example which offers DPI, FW and Packet Replication then, I need a domain-wide PSSI defining DPI + FW + Sampling but if somewhere else in my network I just need FW, then I need another domain-wide PSSI for only FW.
In that model, I will end up with and endless list of permutations which must be agreed upon to ensure interop (i.e. vendor A cannot use a PSSI X for FW while vendor B think’s its DPI).
Thx
Dan B

On 2019-09-13, 2:10 PM, "ipv6 on behalf of Ron Bonica" <[email-masked]<mailto:[email-masked]> on behalf of rbonica=[email-masked]<mailto:rbonica=[email-masked]>> wrote:

Robert,

In your email, you ask how I would solve a TE problem with a Per Segment Service Instruction (PSSI). In SRv6+:

-          The CRH and the SIDs that it contains are used to solve TE problems

-          The PSSI is used too provide non-routing services (e.g., firewalling, sampling, DPI)

This leaves the following questions to be answered:

-          How would I solve the TE problem that you describe in your email?

-          Given another example, explain how PSSI works?

Which question would you like me to tackle first?

                                                                    Ron

From: Robert Raszuk <[email-masked]>
Sent: Friday, September 13, 2019 8:45 AM
To: Ron Bonica <[email-masked]>
Cc: SPRING WG <[email-masked]>; 6man <[email-masked]>
Subject: Per segment service instructions

Dear Ron,

I have read yet one more draft from the SRv6+ package defining another Destination Option type - this time Per Segment Service Instruction(s) described in draft-bonica-6man-seg-end-opt

I have one technical question regarding it.

Imagine I have following topology - drawing only what is relevant to the question:

PE1 - - P1 - - SE1 - - P2 - -  SE2 - - P3 - - PE2

When packet enters the network PE1 is instructed to program my flow A to execute following following functions on Segment End 1 (SE1) and Segment End 2 (SE2):

SE1 - When packet is routed out of SE1 consider only interfaces of bw 10G and up

SE2 - When packet is routed out of SE2 make sure that path to segment end node is no more then 2 hops away.

From reading the draft I think the answer is that you mandated the segment end functions in SRv6+ to have domain-wide significance such that the function itself contains not only the instruction but also as it is of domain-wide significance the location of the instruction to execute it on.

So far so good ... Flow-A get's CRH and PSSI encoding the above requirement.

When packet enters SE1 Destination Options preceding RH is read and PSSIs are attempted to get executed ! Both instructions are tried but only one is known so only one get's executed on SE1. Same story on SE2.

Not sure if eveyone would be ok with such model to read and attempt to execute instructions which are not for a given end segment but let's assume some may accept it.

But now how unfortunate it may sound PE1 is receving the flow-B and for flow B the requirements are opposite:

SE1 - When packet is routed out of SE1 make sure that path to segment end node is no more then 2 hops away.

SE2 - When packet is routed out of SE2 consider only interfaces of bw 10G and up.

Well what do you - simple - you allocate another two domain wide functions and encode it in the packet at PSSI DOH on PE1.

But if my description matches the plan you now end up with per flow !!! state in the network which is the price to pay for splitting SIDs with its functions into completely different headers.

I don't know about others but I think we went in the past via multiple attempts to put any per flow state into the large network and it all failed when faced scale.

Also SR specifically in its architecture RFC8402 says that segment routing is "maintaining per-flow state only at the ingress node(s) to the SR domain."

Kind regards,
Robert.

Juniper Business Use Only

---

From: Ron Bonica <[email-masked]>
Date: Mon, 16 Sep 2019 15:22:34 +0000

Daniel,

Yes, you will need one PSSI for each combination of service elements in the domain. However, PSSIs are allocated at configuration time on a per domain basis. There is no need for vendor involvement or interdomain co-ordination.

Beyond that, there are many ways to approach service function chaining in SRv6+. Among these are:

  *   Use the PSSI
  *   Dedicate an IP address to each service and omit the PSSI
  *   Use the NSH and omit the PSSI

                                             Ron

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of Bernier, Daniel
Sent: Saturday, September 14, 2019 1:03 AM
To: Ron Bonica <rbonica=[email-masked]>; Robert Raszuk <[email-masked]>
Cc: SPRING WG <[email-masked]>; 6man <[email-masked]>
Subject: Re: [spring] Per segment service instructions

Hi Ron,

If PSSI provide non-routing services such as SE1 from Robert's example which offers DPI, FW and Packet Replication then, I need a domain-wide PSSI defining DPI + FW + Sampling but if somewhere else in my network I just need FW, then I need another domain-wide PSSI for only FW.
In that model, I will end up with and endless list of permutations which must be agreed upon to ensure interop (i.e. vendor A cannot use a PSSI X for FW while vendor B think's its DPI).

Thx
Dan B

Robert,

                                                                    Ron

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Friday, September 13, 2019 8:45 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Per segment service instructions

Dear Ron,

Kind regards,
Robert.

---

From: Tarek Saad <[email-masked]>
Date: Mon, 16 Sep 2019 15:59:21 +0000

Hi all,

A possible way to avoid domain wide scope of PSSI, would be to encode a per node ID within the PSSI (per node namespace of Service IDs).
This allows the node parsing the DOH to identify PSSI(s) that needs to be invoked locally and to resolve the Service ID within its node scope. The per node ID can be a SRV6+ short SID that is instantiated locally on the node.

So, a PSSI = Short-SID.SE1

DOH can contain:
Short-SID1.SE1
Short-SID2.SE2
Etc.

Regards,
Tarek

From: spring <[email-masked]> on behalf of "Bernier, Daniel" <[email-masked]>
Date: Saturday, September 14, 2019 at 1:03 AM
To: Ron Bonica <rbonica=[email-masked]>, Robert Raszuk <[email-masked]>
Cc: SPRING WG <[email-masked]>, 6man <[email-masked]>
Subject: Re: [spring] Per segment service instructions

Hi Ron,

Robert,

                                                                    Ron

Dear Ron,

Kind regards,
Robert.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 16 Sep 2019 18:27:18 +0200

Dear Tarek,

Your line of thinking is correct but please no more additional levels of
abstraction. Why not just use normal routable prefix on the node as part of
the instruction ?

And if so we are back to use of SRH as is - even if only for network
programming :).

Best,
R.

On Mon, Sep 16, 2019 at 6:00 PM Tarek Saad <[email-masked]> wrote:

> Hi all,
>
>
>
> A possible way to avoid domain wide scope of PSSI, would be to encode a
> per node ID within the PSSI (per node namespace of Service IDs).
>
> This allows the node parsing the DOH to identify PSSI(s) that needs to be
> invoked locally and to resolve the Service ID within its node scope. The
> per node ID can be a SRV6+ short SID that is instantiated locally on the
> node.
>
>
>
> *From: *spring <[email-masked]> on behalf of "Bernier, Daniel" <
> [email-masked]>
> *Date: *Saturday, September 14, 2019 at 1:03 AM
> *To: *Ron Bonica <rbonica=[email-masked]>, Robert Raszuk <
> [email-masked]>
> *Cc: *SPRING WG <[email-masked]>, 6man <[email-masked]>
> *Subject: *Re: [spring] Per segment service instructions
>
>
>
> Hi Ron,
>
>
>
> If PSSI provide non-routing services such as SE1 from Robert’s example
> which offers DPI, FW and Packet Replication then, I need a domain-wide PSSI
> defining DPI + FW + Sampling but if somewhere else in my network I just
> need FW, then I need another domain-wide PSSI for only FW.
>
> In that model, I will end up with and endless list of permutations which
> must be agreed upon to ensure interop (i.e. vendor A cannot use a PSSI X
> for FW while vendor B think’s its DPI).
>
> Thx
>
> Dan B
>
>
>
>
>
>
>
> On 2019-09-13, 2:10 PM, "ipv6 on behalf of Ron Bonica" <
> [email-masked] on behalf of rbonica=[email-masked]>
> wrote:
>
>
>
> Robert,
>
>
>
> In your email, you ask how I would solve a TE problem with a Per Segment
> Service Instruction (PSSI).. In SRv6+:
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Friday, September 13, 2019 8:45 AM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* SPRING WG <[email-masked]>; 6man <[email-masked]>
> *Subject:* Per segment service instructions
>
>
>
> Dear Ron,
>
>
>
> I have read yet one more draft from the SRv6+ package defining another
> Destination Option type - this time Per Segment Service Instruction(s)
> described in draft-bonica-6man-seg-end-opt
>
>
>
> When packet enters the network PE1 is instructed to program my flow A to
> execute following following functions on Segment End 1 (SE1) and Segment
> End 2 (SE2):
>
>
>
> From reading the draft I think the answer is that you mandated the segment
> end functions in SRv6+ to have domain-wide significance such that the
> function itself contains not only the instruction but also as it is of
> domain-wide significance the location of the instruction to execute it on.
>
>
>
> When packet enters SE1 Destination Options preceding RH is read and PSSIs
> are attempted to get executed ! Both instructions are tried but only one is
> known so only one get's executed on SE1. Same story on SE2.
>
>
>
> Not sure if eveyone would be ok with such model to read and attempt to
> execute instructions which are not for a given end segment but let's assume
> some may accept it.
>
>
>
> Well what do you - simple - you allocate another two domain wide functions
> and encode it in the packet at PSSI DOH on PE1.
>
>
>
> But if my description matches the plan you now end up with per flow !!!
> state in the network which is the price to pay for splitting SIDs with its
> functions into completely different headers.
>
>
>
> I don't know about others but I think we went in the past via multiple
> attempts to put any per flow state into the large network and it all failed
> when faced scale.
>
>
>
> Also SR specifically in its architecture RFC8402 says that segment routing
> is "maintaining per-flow state only at the ingress node(s) to the SR
> domain."
>
>
>
> Kind regards,
>
> Robert.
>
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 16 Sep 2019 16:44:11 +0000

Good idea!!

Juniper Business Use Only
From: Tarek Saad <[email-masked]>
Sent: Monday, September 16, 2019 11:59 AM
To: EXT - [email-masked] <[email-masked]>; Ron Bonica <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: SPRING WG <[email-masked]>; 6man <[email-masked]>
Subject: Re: [spring] Per segment service instructions

Hi all,

DOH can contain:
Short-SID1.SE1
Short-SID2.SE2
Etc.

Regards,
Tarek

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of "Bernier, Daniel" <[email-masked]<mailto:[email-masked]>>
Date: Saturday, September 14, 2019 at 1:03 AM
To: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>, 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Per segment service instructions

Hi Ron,

Robert,

In your email, you ask how I would solve a TE problem with a Per Segment Service Instruction (PSSI).. In SRv6+:

                                                                    Ron

Dear Ron,

Kind regards,
Robert.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 17 Sep 2019 11:30:19 +0200

Hi Robert,

> Your line of thinking is correct but please no more additional levels of abstraction. Why not just use normal routable prefix on the node as part of the instruction ?

How large a prefix do you envision is needed per node? What size are we talking about (roughly)?

Cheers,
Sander