Re: SRH Issue #38 TLVs in SRH

On Sun., 24 Mar. 2019, 09:33 Darren Dukes (ddukes), <ddukes@cisco.com> wrote:
>
> 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.
>
>

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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------