SRH Issue #38 TLVs in SRH

["Darren Dukes (ddukes)" <[e-mail]>]

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