Re: Fwd: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

On Thu, Jun 3, 2021 at 6:15 AM Nick Hilliard <nick@foobar.org> wrote:
>
> Hi Bob, Gorry,
>
> Couple of things on this.
>
> - draft-hinden-6man-hbh-processing is not the document to have
> terminology statements about control / forwarding plane / fast path /
> slow path / etc.  The topic is more subtle and nuanced than can be dealt
> with in a summary of a draft which addresses a different topic.  The
> ietf really needs a proper document to discuss the issue because the
> terms are used in quite a lot of discussions relating to packet
> forwarding, and several subtleties are germane to this draft.
>
> - Is it correct to conclude that this doc changes the semantics of HBH
> from only being processed when "explicitly configured to do so" to "MUST
> process"?  The text in the draft is ambiguous in the sense that it could
> mean:
>
> 1. nodes MUST examine at least one HBH EH and MUST process the first
> Option in the fast path, or
> 2. if a node is configured to process HBH EHs, it MUST process the first
> Option in the fast path.
>
> - signaling slow path HBH processing via the Router Alert option should
> be interpreted in the context that if a HBH packet reaches the slow
> path, this should be treated as something of a curiosity, i.e. the
> exception rather than the rule.
>
> - consequently + for other reasons, it might be an idea to update the
> text in the security considerations from "Due to this it's common for
> transit routers" to "Due to this, it is routine for transit routers"
>
> - given the many and increasing orders of magnitude of difference
> between fast path and slow path processing speed, I really question the
> wisdom of making any declarations at all about slow path processing.
> This is writing cheques on an empty account.  We need to deprecate this
> idea completely - it's been entirely non-viable for many years.
>
Completely agree with that, the concept of "slow path" in the datapath
needs to go away! IMO, if a router can't process something in the fast
path then it shouldn't process it all-- preferably the router would
ignore things it can't process quickly, but if it can't, from a host
perspective I'd rather routers drop packets (packet loss would at
least be an explicit signal that a host is sending something routers
don't like). Even if the slow path is only taken intermittently, that
is still problematic as it creates variances in RTT that can wreak
havoc on transport congestion control algorithms that are measuring
delay. Not to mention that attacking the slow path is an obvious DoS
vector.

Tom

> - nit: all instances of "it's" except for the last one in section 8
> should be changed to "its"
>
> Nick
>
> Bob Hinden wrote on 02/06/2021 19:31:
> > Hi,
> >
> > We posted a new version of draft-hinden-6man-hbh-processing.    The
> > changes include:
> >
> >     *  Expanded terminology section to include Forwarding Plane and
> >        Control Plane.
> >     *  Changed draft that only one HBH Option MUST be processed and
> >        additional HBH Options MAY be processed based on local
> >        configuration.
> >     *  Clarified that all HBH options (with one exception) must be
> >        processed on the Fast Path.
> >     *  Kept the Router Alert options as the single exception for Slow
> >        Path processing.
> >     *  Rewrote and expanded section on New Hop-by-Hop Options.
> >     *  Removed requirement for HBH Option size and alignment.
> >     *  Removed sections evaluating currently defined HBH Options.
> >     *  Added content to the Security Considerations section.
> >     *  Added people to the acknowledgements section.
> >     *  Numerous editorial changes
> >
> > We think this resolves most of the issues raised on the list and at the
> > pervious IETF meeting.
> >
> > Please review and comment on the list.
> >
> > Bob & Gorry
> >
> >> Begin forwarded message:
> >>
> >> *From: *internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
> >> *Subject: **New Version Notification for
> >> draft-hinden-6man-hbh-processing-01.txt*
> >> *Date: *June 2, 2021 at 11:27:07 AM PDT
> >> *To: *"Robert M. Hinden" <bob.hinden@gmail.com
> >> <mailto:bob.hinden@gmail.com>>, "Godred Fairhurst"
> >> <gorry@erg.abdn.ac.uk <mailto:gorry@erg.abdn.ac.uk>>, "Gorry
> >> Fairhurst" <gorry@erg.abdn.ac.uk <mailto:gorry@erg.abdn.ac.uk>>,
> >> "Robert Hinden" <bob.hinden@gmail.com <mailto:bob.hinden@gmail.com>>
> >>
> >>
> >> A new version of I-D, draft-hinden-6man-hbh-processing-01.txt
> >> has been successfully submitted by Robert M. Hinden and posted to the
> >> IETF repository.
> >>
> >> Name:draft-hinden-6man-hbh-processing
> >> Revision:01
> >> Title:IPv6 Hop-by-Hop Options Processing Procedures
> >> Document date:2021-06-02
> >> Group:Individual Submission
> >> Pages:13
> >> URL:
> >> https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-01.txt
> >> Status: https://datatracker.ietf.org/doc/draft-hinden-6man-hbh-processing/
> >> Html:
> >> https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-01.html
> >> Htmlized:
> >> https://datatracker.ietf.org/doc/html/draft-hinden-6man-hbh-processing
> >> Diff:
> >> https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-hbh-processing-01
> >>
> >> Abstract:
> >>   This document specifies procedures for how IPv6 Hop-by-Hop options
> >>   are processed.  It modifies the procedures specified in the IPv6
> >>   Protocol Specification (RFC8200) to make processing of IPv6 Hop-by-
> >>   Hop options practical with the goal of making IPv6 Hop-by-Hop options
> >>   useful to deploy and use in the Internet.  When published, this
> >>   document updates RFC8200.
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >>
> >>
> >
> >
> >
> > --------------------------------------------------------------------
> > 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
> --------------------------------------------------------------------