Subject: SRH Issue #38 TLVs in SRH

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Sat, 23 Mar 2019 22:32:29 +0000

Regarding TLVs in the SR Header.

It is fundamental to the SR architecture to provide an integrated underlay overlay and service chaining solution through the use of topological and service segments.  Multiple drafts describe the usage of SRH for service chaining, and meta data use:
- draft-dawra-idr-srv6-vpn
- draft-ali-6man-spring-srv6-oam
- draft-xuclad-spring-sr-service-programming
- draft-boutros-nvo3-geneve-applicability-for-sfc

The SR Source may combine segments that identify the underlay waypoints for traffic engineering or service functions.  It’s clear that the former may be entirely supported by high speed ASICs, while the latter may be supported in the same network and in the same deployment by servers, or more flexible hardware implementation.

The combination of the two types of segments in the deployment does not call for the hardware implementations to support segments or parsing that is not supportable on the hardware.

Providing a container for TLVs _within the SRH_ ensures that the topological segments are not burdened with the cost of processing service segments, or walking over the meta data they use.
I.e. the service segments may appear anywhere within the segment list, the topological segments implemented by high speed ASICs need not incur the cost of processing, or even loading into memory, any meta data stored in TLVs for use by service segments.

There have been multiple usecases demonstrated where service segments are implemented in Linux IPTables and FD.io VPP.

Darren

---

From: Mark Smith <[email-masked]>
Date: Sun, 24 Mar 2019 11:22:08 +1100

> There have been multiple usecases demonstrated where service segments are implemented in Linux IPTables and FD.io VPP.

So I think this email is demonstrating a major issue with some of the
SR proposals, such as EH insertion.

The criteria that seem to be being used to justify and prove them is
that it can successfully be implemented in code, and by implication
functions in a sterile lab or test environment.

There doesn't seem to be much or any consideration of production
deployment operational issues, such has how easy troubleshooting will
be when there is either an imperfect (buggy) implementation, or if a
perfect implementation is misconfigured or suffers from a partial
failure, for example due to a partial hardware failure.

Regards,
Mark.

> Darren
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 24 Mar 2019 10:21:19 +0100

Your description below seems to imply that topological segments are
1) well defined as distinct from service segments
2) inherently allowed to ignore all TLVs.

As far as I can tell, neither of those statements is true of the current 
draft.
The proposals for separating the TLVs out from the SRH both include 
explicit mechanisms to indicate which hops have to worry about which (if 
any) TLVs.  That would seem to better address the need, compared with 
saying that all topological segments ignore TLVs and all service 
segments look at all TLVs.

Yours,
Joel

PS: If the goal is interoperable service chaining, I would like to see 
an explanation for why RFC 8300 is not applicable.  We are taking about 
a technology that needs new hardware and software anyway, so the 
transition argument used for one of the alternatives does not apply.

On 3/23/19 11:32 PM, Darren Dukes (ddukes) wrote:
> It is fundamental to the SR architecture to provide an integrated 
> underlay overlay and service chaining solution through the use of 
> topological and service segments.  Multiple drafts describe the usage of 
> SRH for service chaining, and meta data use:
> 
> The SR Source may combine segments that identify the underlay waypoints 
> for traffic engineering or service functions.  It’s clear that the 
> former may be entirely supported by high speed ASICs, while the latter 
> may be supported in the same network and in the same deployment by 
> servers, or more flexible hardware implementation.
> 
> The combination of the two types of segments in the deployment does not 
> call for the hardware implementations to support segments or parsing 
> that is not supportable on the hardware.
> 
> Providing a container for TLVs _within the SRH_ ensures that the 
> topological segments are not burdened with the cost of processing 
> service segments, or walking over the meta data they use.
> 
> I.e. the service segments may appear anywhere within the segment list, 
> the topological segments implemented by high speed ASICs need not incur 
> the cost of processing, or even loading into memory, any meta data 
> stored in TLVs for use by service segments.
> 
> There have been multiple usecases demonstrated where service segments 
> are implemented in Linux IPTables and FD.io VPP.
> 
> Darren
> 
>

---

From: "Voyer, Daniel" <[email-masked]>
Date: Sun, 24 Mar 2019 18:08:27 +0000

As also inline for production network:

Mark, what are you talking about ? We are deploying this in the network.

Sent from my mobile

> On Mar 24, 2019, at 01:22, Mark Smith <[email-masked]> wrote:
> 
Mark, what are you talking about ? We are deploying this in the network.

---

From: Tom Herbert <[email-masked]>
Date: Sun, 24 Mar 2019 19:18:16 +0100

On Sun, Mar 24, 2019, 7:09 PM Voyer, Daniel <[email-masked]> wrote:

> for traffic engineering or service functions.  It’s clear that the former
> may be entirely supported by high speed ASICs, while the latter may be
> supported in the same network and in the same deployment by servers, or
> more flexible hardware implementation.
> >>
> >>
> >>
> call for the hardware implementations to support segments or parsing that
> is not supportable on the hardware.
> >>
> >>
> >>
> topological segments are not burdened with the cost of processing service
> segments, or walking over the meta data they use.
> >>
> the topological segments implemented by high speed ASICs need not incur the
> cost of processing, or even loading into memory, any meta data stored in
> TLVs for use by service segments.
> >>
> >>
> >>
Daniel, EH insertion is in deployment?

---

From: Mark Smith <[email-masked]>
Date: Mon, 25 Mar 2019 11:54:04 +1100

Hi Daniel, Tom,

> On Sun, Mar 24, 2019, 7:09 PM Voyer, Daniel <[email-masked]> wrote:

<snip>

>> Mark, what are you talking about ? We are deploying this in the network.

I've come to realise with experience that there is "works" threshold,
and a higher "works well" threshold, and there is a fairly big gap
between them. "Working" means implementable, where as I think "working
well" means other additional criteria, such as how easy is it to
understand, deploy, operate and troubleshoot in a production network.

> Daniel, EH insertion is in deployment?

As Tom guessed, EH insertion is one of the examples I'm thinking
about. It's clear that it can be made to work.

However, when I think about "working well" criteria, I don't think it
would work that well when operating a production network.

Insertion of data into in-flight IPv6 packets is a completely new
mechanism that has not been seen before with IP networks.
Troubleshooting experience with it would be nearly non-existent, other
than perhaps at your network. It is not leveraging any existing
mechanisms that people are already familiar with when operating IP
networks.

There doesn't seem to be any inserted EH source or intended
destination device identification. The IPv6 header's SA and DA are now
do not identify the originator of the entire packet, and identify the
receiver of the entire packet. Insertion of EHs also violates the
RFC8200 SA and DA definitions as well as the EH insertion prohibition.

So I think showing something can be made to work is not enough
justification. There are other "works well" criteria that need to be
considered if the technology is intended to be used in a production
network.

Regards,
Mark.

---

From: "Voyer, Daniel" <[email-masked]>
Date: Mon, 25 Mar 2019 08:16:47 +0000

On 2019-03-25, 1:54 AM, "Mark Smith" <[email-masked]> wrote:

    Hi Daniel, Tom,

    <snip>

    
[Dan] This is why I suggested to be more specific, in the context of the draft SRH, are you suggesting to add OAM ? If yes, there is draft on this. If no, please be specific in what is it you want to see in this SRH Draft.

    

[Dan] Still in context of SRH draft, there is no EH insertion

    Regards,
    Mark.