RE: DRAFT San Diego minutes

[email protected]
Newsgroups gmane.ietf.rddp
Message-ID <[email protected]>
I don't want to be argumentative here since I think
where you ended up is fine.  A few thoughts follow.

Julian Satran wrote:
> The reasoning behind this requirement was  that an
> I_T pair may  want to negotiate CRC (or equivalent)
> as an e2e guarantee but have no way of doing that if they use iSER.

The conclusion does seem to follow from the premise.
The question is why the I_T pair negotiates the CRC.
ULPs are not allowed to negotiate use of IPsec or
negotiate with IP layer as to which routes are 
acceptable.  There is an argument to be made
for a layered architecture in which each layer
is responsible for making the critical decisions
in its own "area of expertise".

Caitlin Bestler wrote:
> In any event, this would hardly be the first time
> that a requirement was stated in terms of an
> acceptable solution. Building codes routinely
> require a certain type of wood be used for floors,
> and occasionally state 'must support X pounds 
> per square foot

This is a nice analogy and makes sense.  The only
thing that give me a little pause is that for 
typical installations where the links are already
CRC protected, and networking equipment is well
designed with internal data paths parity protected,
TCP checksum escapes are probably not the weak
link in end to end data integrity, so adding a
CRC will not improve data integrity in this case.
This case may well turn out to be the majority
of installations.  However the added CRC certainly
does no harm.

Mallikarjun C. wrote:
> MPA CRC should allow being turned off 
> if there's IPSec/similar protection underneath.

I have seen this idea before and cringe every time.
I fear that the IPSec encryption/decryption layer
is an order of magnitude more likely to cause
data corruption than everything else in the end
to end data path combined.  There is not even
a practical method to parity protect this logic.
The IPSec design team decided to order encryption
and authentication such that the encryption/decryption
logic is totally unprotected by the authentication
layer.

To me, IPSec seems like a good argument to turn
the CRC on, and not a very reassuring argument
to turn it off.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.