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