Subject: [spring] Per segment service instructions

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Sep 2019 14:44:52 +0200

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.

---

From: Ron Bonica <[email-masked]>
Date: Fri, 13 Sep 2019 18:10:04 +0000

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

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

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: Robert Raszuk <[email-masked]>
Date: Fri, 13 Sep 2019 21:32:11 +0200

Dear Ron,

My note and choice of function descriptions was absolutely not binding. I
used it to simply illustrate my understanding how your SRv6+ architecture
works in regards to Segment End execution not to seek another replacement
solution for this specific set of requirements.

Sure you could perhaps invent Adj SID mapping grouping all links over 10G.
Inventing SID to indicate dynamic variable like hop count which changes in
time scale towards next destination is more involved if you want to push it
into CRH.

But bottom line is to highlight that DOH's PSSI containing segment end
functions in SRv6+ architecture are:

a) executed at each segment end regardless if function even applies or
makes sense on such segment end

b) are of domian-wide significance with all of the consequences of such
design choice

Many thx,
Robert.

On Fri, Sep 13, 2019 at 8:10 PM Ron Bonica <rbonica=
[email-masked]> wrote:

>    - 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)
>
>
>
>    - How would I solve the TE problem that you describe in your email?
>    - Given another example, explain how PSSI works?
>
>
>
> *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,
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>