Re: Erratum reported on MPA (RFC 5044)

"Pat Thaler" <[email protected]> Thu, 4 Dec 2008 16:33:21 -0800
Newsgroups gmane.ietf.rddp
Message-ID <DBFBCB90599B2C46992032279293D10010191666F1@SJEXCHCCR01.corp.ad.broadcom.com>
David,

I've checked with our implementers and we support accepting the erratum.

Pat 

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: Monday, December 01, 2008 2:05 PM
To: [email protected]; [email protected]; Uri Elzur; [email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: [rddp] Erratum reported on MPA (RFC 5044)

An erratum has been reported on MPA (RFC 5044):

http://www.rfc-editor.org/errata_search.php?eid=1427

The background is that MPA is 4-byte aligned, and hence
the 2 least significant bits of a marker MUST be zero.

The current language in MPA requires a receiver to set
these bits to zero in all markers before calculating
the CRC.  The erratum suggests calculating the CRC with
whatever arrives.

This sounds like a reasonable approach, as any modifications
to inbound traffic prior to the CRC calculation may be
problematic, but it raises an issue: What is the "right"
thing to do if a packet passes a CRC check but has a
misaligned marker (two least-significant bits aren't
both zero)?

The erratum implies that this condition is ignored - the
least significant bits are treated as if they were zero
in using the marker (and this is very easy to do in an
implementation).

On this basis, I'm inclined to accept the erratum, but
would like to hear from implementers on what they actually
do with misaligned markers if they arrive - I think
"running code" should be paramount in making this decision.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
rddp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rddp