Re: SRH Issue #38 TLVs in SRH

On Sun, Mar 24, 2019, 7:09 PM Voyer, Daniel <daniel.voyer@bell.ca> wrote:

> 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.
> >
>
Daniel, EH insertion is in deployment?

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