[T11.3] FC-LS/FCP-4: Proposed REC behavior

Roger Hathorn rhathorn at us.ibm.com
Thu Aug 31 10:40:20 PDT 2006


Formatted message: <A HREF="r0608319_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0608319_graycol.gif">graycol.gif</A>
Attachment #2: <A HREF="r0608319_pic04238.gif">pic04238.gif</A>
Attachment #3: <A HREF="r0608319_ecblank.gif">ecblank.gif</A>
Attachment #4: <A HREF="r0608319_1a953013.gif">1a953013.gif</A>
Attachment #5: <A HREF="r0608319_1a782353.gif">1a782353.gif</A>

David,
I did not mean to imply that the recipient shall verify the rule.  The
words say that the sender shall follow the rule.
Existing implementations do not enforce any rules about the S_ID in the REC
payload.  I don't think you can expect enforcement by the recipient,
because that would then make existing implementations non-compliant.   If
the originator breaks the rules, unexpected results can be expected.   If
you expect the recipient to enforce the rule, then you need to say what
happens when the rule is broken.  Since this would require changes in
existing implementations, I don't think we can say anything about
enforcement.
Bob, I am fine with your words too.   I think they mean the same thing.
Roger G. Hathorn
Senior Engineer, Storage Systems Development
IBM Systems and Technology Group
Tel: 520-799-5950 (T/L: 321-5950)
Pager: 520-446-2741 or
http://www.arch.com/cgi-bin/wwwpreproc.exe?PIN=5204462741
	     Bob.Nixon at Emulex.					       
	     Com						       
	     Sent by:							To
	     t11_3-bounces at lis	       <David.Peterson at mcdata.com>,    
	     tserve.com 	       <t10 at t10.org>, <t11_3 at mail.t11.org>
									cc
	     08/31/2006 09:00					   Subject
	     AM 		       RE: [T11.3] FC-LS/FCP-4: Proposed
				       REC behavior		       
Rather than say who shall do it, we should simply say what it shall be.
Unless we excuse either side explicitly (which we should not do) then the
sender is required to get it right, and the receiver is required to protect
itself.  In the first paragraph of the description, change
The S_ID specified in the Payload of the request Sequence may differ from
address identifiers of both the source and destination of the REC request
itself
to
The S_ID specified in the Exchange originator S_ID field of the Payload of
the request Sequence shall be the same as either the S_ID or the D_ID in
the Frame Header of the request Sequence.
   - bob
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of David
Peterson
Sent: Thursday, August 31, 2006 8:21 AM
To: t10 at t10.org; t11_3 at mail.t11.org
Subject: RE: [T11.3] FC-LS/FCP-4: Proposed REC behavior
Howdy Roger,
Don't see how your proposed change allows existing implementations to
remain compliant either.
Per your proposed change, it still implies the recipient FCP_Port needs to
verify that the FC header S_ID field value is a valid address identifier
for the target Exchange.
In other words, without checking FC header S_ID field value, how can the
recipient FCP_Port verify that the REC was issued by the Originator Nx_Port
or Responder Nx_Port of the target Exchange?
Not quite enough teeth for me. I'm looking to enforce that REC is not
processed via a 3rd party request.
Also note that FCP-4 already contains changes to PRLI (i.e., the
REC_SUPPORTED bit).
Thanks...Dave
(no disclaimer)
      From: Roger Hathorn [mailto:rhathorn at us.ibm.com]
      Sent: Wednesday, August 30, 2006 3:53 PM
      To: David Peterson
      Cc: t10 at t10.org; t11_3 at mail.t11.org
      Subject: Re: [T11.3] FC-LS/FCP-4: Proposed REC behavior
      I suggest that the proposed text:
      A Read Exchange Consise Request shall only be accepted if the
      Originator Nx_Port or the Responder Nx_Port of the target Exchange
      makes the request
      be changed to:
      "A Read Exchange Consise Request shall only be issued by the
      Originator Nx_Port or the Responder Nx_Port of the target Exchange."
      to allow existing implementations to remain compliant. The text, as
      proposed, indicated that the recipient has to somehow check this.
      Roger G. Hathorn
      Senior Engineer, Storage Systems Development
      IBM Systems and Technology Group
      Tel: 520-799-5950 (T/L: 321-5950)
      Pager: 520-446-2741 or
      http://www.arch.com/cgi-bin/wwwpreproc.exe?PIN=5204462741
      Inactive hide details for "David Peterson"
      <David.Peterson at mcdata.com>"David Peterson"
      <David.Peterson at mcdata.com>
			 "David 				       
			 Peterson"				       
			 <David.Peterson			       
			 @mcdata.com>				       
			 Sent by:					To
			 t11_3-bounces at l			       
			 istserve.com		   <t10 at t10.org>,      
						   <t11_3 at mail.t11.org>
			 08/30/2006					cc
			 10:29 AM				       
								   Subject
						   [T11.3] FC-LS/FCP-4:
						   Proposed REC behavior
      Howdy,
      To remove the ability for a third party to issue an REC, here is the
      proposed text for FC-LS:
      4.2.42.1 Description
      This ELS shall be used only for purposes specific to an FC-4. The REC
      (Read Exchange Concise) Extended Link Service requests an Nx_Port to
      return Exchange information for the RX_ID and OX_ID originated by the
      S_ID specified in the Payload of the request Sequence. The S_ID
      specified in the Payload of the request Sequence may differ from
      address identifiers of both the source and destination of the REC
      request itself. A Read Exchange Consise Request shall only be
      accepted if the Originator Nx_Port or the Responder Nx_Port of the
      target Exchange makes the request. The specification of OX_ID and
      RX_ID shall be provided for the destination Nx_Port to locate the
      status information requested. A Responder destination Nx_Port shall
      use the RX_ID and verify that the OX_ID is consistent, unless the
      RX_ID is unassigned (i.e., RX_ID = FFFFh). If the RX_ID is unassigned
      in the request, the Responder shall identify the Exchange by means of
      the S_ID specified in the Payload of the request Sequence and OX_ID.
      An Originator Nx_Port shall use the OX_ID and verify that the RX_ID
      is consistent.
      Please review the proposed text and be ready for a vote at the
      October T11 FC-LS working group meeting.
      Thanks...Dave
      (no disclaimer)
      _______________________________________________
      T11_3 mailing list
      http://mailman.listserve.com/listmanager/listinfo/t11_3
      _______________________________________________
      T11_3 mailing list
      http://mailman.listserve.com/listmanager/listinfo/t11_3



More information about the T10 mailing list