Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer

[Fernando Gont <[e-mail]>]

Hi, Brian,

On 29/7/20 01:03, Brian E Carpenter wrote:
[....]
>> It seems evident that the IPv6 packet structure makes a cost-effective
>> implementation rather difficult. Since engineering does not only have to
>> do with science, but also with economics, it follows that:
>>
>> * Folks (group #1) will not be willing to pay for features that their
>> clients do not explicitly require.
>>
>> * Vendors (group #2) will not spend cycles on something which will not
>> get them money in return.
>>
>> * Other set of folks (group #3) will not actively try to leverage
>> features with a high failure rate, since they would also need to
>> implement workarounds -- and if the workarounds already solve the
>> problem, with a much higher success rate, there's not much of a point in
>> spending time (and ultimately $$) in the feature that usually fails.
>>
>> * Users (group #4) use whatever solves their problem.
>>
>>
>> We may be unhappy with the above fact. But unless we're willing to pay
>> the bill :-), I'm not sure to what extent embarking into a Crusade would
>> solve the "problem".
> 
> Not what I meant, really. 

FWIW, I do agree with you. My comment was a response to Tom where he was 
objecting to folks that, for one reason or another, happen to drop 
packets. (in this particular case the advice given by JOel in his 
presentation)

And what I meant is that rather that being mad about them, one should 
try to find the reasons for which they are resorting to that (which is 
what this document is meant to), and then figure out and do what we can 
from a protocol engineering perspective.



> All we can do here is write documents. So if
> the consensus is still what the standards track documents say, including
> Node Requirements, we have actually done our duty.

That's in part correct. However, for cases where standards track 
documents implementation become unfeasible or cost-ineffective, one may 
need to consider being more flexible and reconsider the spec.

A good example was the IPsec requirement in an early revision of Node 
Reqs: it was words on paper that would never be complied with - so the 
spec was changed to reflect that.

I'm not necessarily saying that this is the case here, but rather that 
that's an option that should be on the table.



> And we have, in RFC8504:
> "All nodes SHOULD support the setting and use of the IPv6 Flow Label
> field as defined in the IPv6 Flow Label specification [RFC6437].
> Forwarding nodes such as routers and load distributors MUST NOT
> depend only on Flow Label values being uniformly distributed.

I retrospective, if it cannot depend on the FL (which I agree), is there 
much of a point in using it?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492