Re: SRH Issue #38 TLVs in SRH

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 <markzzzsmith@gmail.com> wrote:
> 
>> 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.
> 
Mark, what are you talking about ? We are deploying this in the network. 
> 
> Regards,
> Mark.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> Darren
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------