Re: SRH Issue #38 TLVs in SRH

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:
> 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
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 