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

[Brian E Carpenter <[e-mail]>]

Nick,
On 04-Jun-21 01:14, Nick Hilliard 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.

I've certainly been assuming #2. If it's #1, I think we'd simply be
recreating the inconsistency between the real world and the satndard
that RFC7045 & RFC8200 removed. IMNSHO there will always be routers
that ignore HbH options.

This suggests that a change to the draft is needed:

OLD:
This document updates [RFC8200] that a node MUST process the first Option 
in the Hop-by-Hop Header in the Fast Path and MAY process additional Hop-by-Hop Options if configured to do so.

NEW:
This document updates [RFC8200] such that if a node is configured to process Hop-by-Hop options, it MUST process the first Option in the Hop-by-Hop Header in the Fast Path and MAY also be configured to process additional Hop-by-Hop Options.

   Brian

> 
> - 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.
> 
> - 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: *[e-mail] <mailto:[e-mail]>
>>> *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" <[e-mail] 
>>> <mailto:[e-mail]>>, "Godred Fairhurst" 
>>> <[e-mail] <mailto:[e-mail]>>, "Gorry 
>>> Fairhurst" <[e-mail] <mailto:[e-mail]>>, 
>>> "Robert Hinden" <[e-mail] <mailto:[e-mail]>>
>>>
>>>
>>> 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
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> .
>