Ken,
Even if we put is a good practice in
the implementer's guide it would merely help in avoiding some nasty bugs
in the initiator and/or target. And we can't mandate it in the implementoer's
guide.
The supporting code for all the exceptions
you mention has to be there and not only because of the session type placement
but because the normal session type has to be supported. All of your arguments
would make sense only if you envision an implementation that supports the
two session types with separate pieces of code or even boxes.
Julo
"Ken Sandars"
<ken_sandars <at> adaptec.com>
Sent by: ips-bounces <at> ietf.org
05-12-05 08:15
|
|
To
|
"'Julian Satran'" <julian.satran <at> gmail.com>,
<Sears_Bill <at> emc.com>
|
|
cc
|
ips <at> ietf.org
|
|
Subject
|
RE: [Ips] Question regarding SessionType |
|
Hi Julo,
I think there is merit in having a recommendation in the implementor guide
that if the SessionType key is going to be set to "Discovery",
it should be
set in the initial Login request.
Clearly this only affects named sessions since the only legal unnamed
session requires SessionType=Discovery in the initial Login request.
Say an initiator wants to create a named discovery session but doesn't
supply SessionType in the initial Login request. The target will assume
the
SessionType is Normal (as it is the default value), and negotiate
accordingly. Some consequences of this are:
1. The initiator will have to be prepared to negotiate Normal session
parameters which the target may offer - such as MaxConnections,
MaxBurstLength, etc.
2. If a target is configured to operate without security for Discovery
sessions but with it for Normal sessions, the initiator cannot successfully
bypass the security phase.
3. The target might make different resource allocation decisions dependant
on the type of session. A Discovery session has much less scope for
consuming system resources than a Normal session. The target implementation
may reject the login due to resource constraints when in fact there are
none
for this session.
4. Some keys must be negotiated with knowledge of the SessionType. For
example, in the implementor's guide, section 5.1 - the ErrorRecoveryLevel
value MUST be negotiated to 0 for Discovery sessions.
MaxRecvDataSegmentLength might be declared differently for different session
types so the target has to hold off with its declaration until either the
final Login request or SessionType is explicitly declared.
While none of these consequences are show-stoppers, they do add complexity
which would be nice to avoid. To recommend this in the implementor guide
should have very little impact as I don't think the named-discovery session
is in common use (at all?).
Thanks,
Ken Sandars
> -----Original Message-----
> From: ips-bounces <at> ietf.org [mailto:ips-bounces <at> ietf.org] On
> Behalf Of Julian Satran
> Sent: 30 November 2005 01:53
> To: Sears_Bill <at> emc.com
> Cc: ips <at> ietf.org
> Subject: Re: [Ips] Question regarding SessionType
>
>
> Bill,
>
> Unfortunately the text of RFC3720 does not agree with your
> assumptions.
> The session type can be specified at any stage as explicitly
> stated in
> chapters 11 and 12.
> I can't think of a good reason we should limit its use (or even
> recommend it as good practice in the implementor guide).
>
> Julo
>
> Sears_Bill <at> emc.com wrote:
> >
> >
> >
> > rfc3720 section 5.3 states:
> >
> > The initial login request of the first connection of a session
MAY
> > also include the SessionType key=value pair.
> >
> > The use of the word 'MAY' here is bothersome. Does this
> mean that an
> > initiator may leave out the session type in the first
> request but then
> > explicitly specify it later? This seems possible but very
> annoying.
> > For example:
> >
> > During Security stage it seems that an initiator could leave
out
> > SessionType but specify a TargetName=<something>.
Later during
> > operational stage the initiator could specify
> SessionType=Discovery.
> > It seems that this is allowed.
> >
> > Currently I am assuming that if the SessionType is not specified
in
> > the initial login request of the first connection that the
> initiator
> > is implicitly negotiating for SessionType=Normal. In this
case I
> > wont send SessionType=Normal in a response PDU but I will
> assume that
> > SessionType has been negotiated to its default value of Normal.
I
> > regard seeing SessionType in any subsequent LoginRequest PDU
as an
> > error.
> >
> >
> >
> > Bill
> >
> >
> >
> >
> --------------------------------------------------------------
> ----------
> >
> > _______________________________________________
> > Ips mailing list
> > Ips <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
> >
>
>
> _______________________________________________
> Ips mailing list
> Ips <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>
>
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
RSS Feed