Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text

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

On 18/04/2015 17:58, Eric Vyncke (evyncke) wrote:
> Fred,
> 
> The performance impact/network health issues are mainly related to
> hop-by-hop which is per RFC 2460 inspected by every router on the path.
> This EH should be ignore IMHO by all routers over the Internet (private
> networks may still inspect/act on it for RSVP for examine).

With a slight sigh:

We explicitly covered this in RFC 7045, which updated RFC 2460 in 2013.
http://tools.ietf.org/html/rfc7045#section-2.2

IMHO we should not be messing with that (or other) standards track
statements in this Informational document.

On 18/04/2015 23:23, Nick Hilliard wrote:

> On 18/04/2015 02:46, Fred Baker (fred) wrote:
>> Well, question for you. If we follow RFC 2460, the router in the middle
>> doesn’t know whether the header is there or not. The only systems that
>> should have a performance impact are systems that parse to them or
>> interpret them. 
> 
> layer 4 information is routinely parsed to extract n-tuples in order to
> create lag / ecmp hashes for load balancing.  I.e. we have a requirement
> for routers to interpret ipv6 packet headers on a per-hop basis, and make
> consistent routing decisions based on this analysis.

Again, we have hashed over this (pun intended) in the past and the conclusions
are in RFC 7045, RFC 6564 and for that matter in RFC 6438 and RFC 7098.

Badsically the design of the extension header mechanism is unfriendly to
middleboxes, which is one reason that I have been trying to make the flow
label useful.

    Brian