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

[Vasilenko Eduard <[e-mail]>]

Thanks to Brian.
After Brian has extracted " Forwarding nodes such as routers and load distributors MUST NOT depend only on Flow Label values being uniformly distributed." from RFC 8504 (Node Requirement).
I believe that original dispute about "should LB relay only on Flow Label" is finished. LB should look deeper into headers.
If somebody is going to dispute this - the only way is to push 8504bis where Flow label "MAY be used as the only value" or "MUST be used".

I was very happy about Fernando's explanation for business logic - I was long time in the business too - it is exactly like his said.
Do not ignore the economy, because economy is very capable to ignore you.

Ed/
-----Original Message-----
From: v6ops [mailto:[e-mail]] On Behalf Of Fernando Gont
Sent: 29 июля 2020 г. 8:00
To: Brian E Carpenter <[e-mail]>; Tom Herbert <[e-mail]>
Cc: IPv6 Operations <[e-mail]>; [e-mail]
Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer

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




_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops