Re: Boot through the SAN disk ?

["Mallikarjun C." <cbm@rose.hp.com>]

Not sure what you mean by "remote boot".

Booting over iSCSI is however supported.  Check this URL out:

http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-boot-10.txt
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com

----- Original Message -----
From: "Aggarwal, Vikas (OFT)" <Vikas.Aggarwal@oft.state.ny.us>
To: "Mallikarjun C." <cbm@rose.hp.com>; <ips@ece.cmu.edu>
Sent: Friday, July 25, 2003 12:02 PM
Subject: Boot through the SAN disk ?


my apologies if not a right place to ask this question.

Will iSCSI support "Remote Boot".
Or please direct me to right place if "Fibre Channel protocol" supports "remote boot" or if there is any work
in that direction.

-vikas


-----Original Message-----
From: Abhijit Lahiri [mailto:abhijit_lahiri@yahoo.com]
Sent: Thursday, July 24, 2003 9:29 AM
To: Mallikarjun C.; ips@ece.cmu.edu
Cc: supriyo_p2003@yahoo.com
Subject: Re: Clarification requested on iscsi-draft-20 w.r.t target
behavior on error conditions




Hi Mallikarjun,

Thanks. Your direction was really useful.

We would request you to clarify another issue.

We have noticed that in some error conditions, the
iSCSI target neither sends any Reject PDU nor does it
close connection. It drops the bad packet and logs an
error message. Since in such cases there is no clue as
to what the Device Under Test have gone through (I
mean without viewing the log), do we say that the
behaviour is incorrect ?

-Regards,
Abhijit











--- "Mallikarjun C." <cbm@rose.hp.com> wrote:
> There is no hard rule involving connection drops and
> Rejects.
> As I already said, the targets *may* drop the
> connection when
> the protocol error is disruptive enough to their
> implementations.
> In fact, either side may drop the connection at any
> time (though
> of course it will be very rare, one would hope) for
> other reasons.
> Your protocol conformance tester would have to take
> these
> factors into consideration.
>
> > I wanted to know the effect of sequence errors
> when
> > ErrorRecoveryLevel=0.
>
> A review of section 6 should help here.
> ErrorRecoveryLevel=0
> means that session recovery is the only promised
> level of recovery,
> and PDU or connection recovery is definitely not
> used.
> It however does *not* mean that session recovery
> must be used
> for every error (though it may be).  I'd in fact
> expect that just the
> specific task with the sequence error will be
> terminated in all
> cases (unless it's the initiator seeing a sequence
> error with a status
> PDU in ErrorRecoveryLevel=0).
>
> Hope that helps.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm@rose.hp.com
>
> ----- Original Message -----
> From: "Abhijit Lahiri" <abhijit_lahiri@yahoo.com>
> To: "Mallikarjun C." <cbm@rose.hp.com>;
> <ips@ece.cmu.edu>
> Cc: <abhijit_lahiri@yahoo.com>;
> <supriyo_p2003@yahoo.com>
> Sent: Wednesday, June 25, 2003 7:09 AM
> Subject: Re: Clarification requested on
> iscsi-draft-20 w.r.t target behavior on error
> conditions
>
>
> >
> > Thanks for your clarifications....
> > I have few more related questions. Please see
> below.
> >
> > > --
> > > Mallikarjun
> > >
> > >
> > >
> > > > Hi All,
> > > >
> > > > We are in the process of desigining an iscsi
> > > target
> > > > simulator as per draft-ietf-ips-iscsi-20.txt.
> > > >
> > > > The draft does not seem to be explicit about
> an
> > > ISCSI
> > > > target's behavior on encountering the
> following
> > > error
> > > > conditions.
> > > >
> > > > 1. Logout Request contains non zero
> > > DataSegmentLength
> > > >
> > > > 2. Write or Data-Out PDU contains data more
> than
> > > >    MaxRecvDataSegmentLength
> > > >
> > > > 3. When pre-negotiated KeyValue pairs (like
> > > > InitialR2T,
> > > >    ImmediateData, DataPDUInOrder etc) are not
> > > >    honoured in Full Feature Phase
> > > >    ("not honouring", also means violation of
> > > result
> > > >     function rules)
> > >
> > > All the above seem to fall into the "protocol
> error"
> > > bucket,
> > > so one would have to employ Rejects to deal with
> > > these.
> > > Depending on the severity of the impact on the
> > > receiving
> > > implementation, it may also choose to drop the
> > > connection
> > > in some cases. The protocol error discussion
> text
> > > (6.11)
> > > provides a hint to this effect.
> >
> >
> > Can we specifically say that an ISCSI Target
> should
> > always follow the following path :
> >
> > 1. Send Reject
> > 2. Then drop the conenction.
> >
> > OR, should an ISCSI Target always drop the
> connection
> > ?
> >
> > OR, can it send only reject and NOT close
> connection ?
> >
> > I am asking this because we are also developing an
> > iSCSI protocol conformance tester from which we
> will
> > simulate these error conditions.
> >
> > If the draft specifies an well defined way of
> > responding to the error message, the tester can be
> > more specific.
> >
> > If an iSCSI target is given the option of behaving
> in
> > any of the 3 ways specified above, the tester
> needs to
> > be prepared for any of the above cases.
> >
> > > > 4. When the sequence of PDUs (DataSN for
> Data-Out,
> > >
> > > >    R2TSN for R2T, CmdSN for Command) are not
> in
> > > >    increasing order
> > >
> > > This protocol error manifests as a "sequence
> error"
> > > whose
> > > handling is described in fair detail in the
> error
> > > recovery chapter (section 6).
> >
> > I am sorry about this query. I should have been
> more
> > specific  about this.
> >
> > I wanted to know the effect of sequence errors
> when
> > ErrorRecoveryLevel=0.
> >
> > Which of the following might happen in this case
> when
> > errorRecoveryLevel = 0 ?
> >
> > 1. Send Reject
> > 2. Then drop the conenction.
> >
> > OR, should an ISCSI Target always drop the
> connection
> > ?
> >
> > OR, can it send only reject and NOT close
> connection ?
> >
> > > >
> > > > 5. SNACK PDU sent for an iSCSI PDU already
> > > >    acknowledged
> > > >
> > > > 6. If NOP-Out ping request is sent in response
> to
> > > a
> > > >    a NOP-In ping request
> > > >
> > > > 7. Renegotiating KeyValue pairs which are not
> > > >    permitetd FFP,. (viz. MaxConnections)
> > >
> > > These all seem to again fall into the protocol
> error
> > > category.
> > > Note that #5 is specifically mentioned in the
> Reject
> > > reason
> > > code table as a protocol error.
> >
> > Right :)  Thanks.
> >
> >
> >
> > __________________________________
>
=== message truncated ===


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com