Subject: FCIP: Minutes of FCIP author's call 10/24/01

From: "Elizabeth Rodriguez" <[email-masked]>
Date: Fri, 26 Oct 2001 12:21:53 -0400

Participating:

Elizabeth Rodriguez, Milan Merhar (taking these notes,) Ralph Weber, Jim
Nelson, Dave Peterson, Vi Chau, Raj B, Venkat  Rangan , Bob Snively, Kha
Sin Teow (from Brocade), Larry Lamberts, Ken Hirata

Comment on last draft - still unclear re handling of one TCP option.
Will be reworded to clarify disabling Nagle "Telnet" handling.

Kha Sin Teow  from Brocade, Bill Krieg from Lucent asked to participate
in conf call. Updating of current author's list to reflect actual
participation may need to be reviewed.

Side discussion on topic of Security Draft

Questions:  On Security draft: currently informative -- do such
informative documents expire?  No, they are RFCs.  Are they reviewed, or
do they express a consensus?   Not subject to review by or consensus of
working group.  

Venkat - in the past when people have wanted to contribute, they could
do so through the mailing list.  This is not available to such private
submissions.   Ralph - Larry and Bob are well within their rights in
stating they were unfairly excluded from participation in development of
security  document, which directly affects them.  

Bob - there are basically three paths; either this is a standards track
document, in which case all interested parties must be able to
participate (e.g. by email.)  Or, it's a proposed set of information
recorded in each standard document, or it's informative information for
reference only.  The Security document as it stands is unacceptable for
any of these three uses. 

Proposed NAPT draft discussion 

Discussion of NAPT draft Ralph distributed.  Larry raised a concern
regarding the statement that an ISL connecting R to W is different than
an ISL connecting W to R.  He believes we should have bidirectional
messages, making those two connections identical.  Ralph said this
document does not use bidirectional messaging, so there is a need to
handle the two unidirectional paths separately.  Larry points out that
until a short frame has been received, there is no way of knowing that a
new TCP connection does or does not connect the same FC addresses as
does a previous connection.

Ralph - note that there is also a change at the end of this same
paragraph, indicating that BB-2 now allows additional behavior beyond
shutting down the connection.  Larry - so, this is to be handled up at
the fabric layer?  I believe there is much more intelligence at the FCIP
device (for connection management,) rather than being exclusively at the
fabric level.  The way this is written, you're precluding me from doing
lots of things that I could use to create a reliable FCIP link using
multiple TCP sessions.  Bob - but, we don't want to create a command set
at the link level.  Larry - and I don't have to.  Let the FCIP entity
decide which connections can be incorporated into a link.  Ralph - what
happens if the information passed across that bidirectional link is
inconsistent?  

Should there be one or more than one link between FCIP devices?  Ralph -
that's something that changes as a result of NAPT.  Bob - yes, the
information that had to be provided to resolve NAPT now allows creation
of multiple links, and multiple FCIP entities.

If you have NAPTs, there is no way of knowing what the entity is via
address; you connect to some address and well-known port, and then you
need to exchange short-frame information, which carries FCIP world-wide
name.  Question - and you can't provide this world-wide name via another
mechanism, such as manual configuration?  Larry - yes, but I don't want
to have to be sitting at the console whenever the connection comes in.
Bob - the fundamental problem, is that I want this information to come
from the FC-BB2 level, but Larry would prefer to have it happen at the
FCIP level.  To a first approximation, there would always be two
connections made, from R to W and W to R, and then FC-BB2 would throw
one away.

Larry - when I ship a box out there won't be any fixed information, the
WWN will probably be derived from the Eport name.  I don't want to have
to rely on manual configuration or the existence of SLP to make this
work.  Bob - but, you have absolutely no idea how these connections are
to be combined.  Larry - I will assign them to a virtual E-port, as the
connections come in and identify themselves.  

Bob - As I understand it, there have been some proposals floating around
FC-SW for trunking of multiple E ports, which would have similar effects
to what you're proposing.  That's why I want to make the FCIP decision
process as naive as possible, so we can take best advantage of it later
in FC-BB2.  Larry - but I don't see what that has to do with
bidirectional messages.  Bob - it makes it redundant. Ralph - the more
it looks like a login, the greater the complexity, and the greater the
risk of problems.

Elizabeth - does it make any sense to make any of this optional - e.g.
ability to make a query.  Consensus is no.   Do people think they have
enough information to make a decision?

Milan - as I don't participate in FC-BB2, I must admit that I see a
protocol, but not a model for how that protocol is to be used, as I
don't have access to the upper level documents where that is described.
So, I'm going to have to abstain.  

Bob - the question Elizabeth asks is do you need a bidirectional short
frame, and the answer is 'no'.  Larry - or, if you have SLP (and that
provides WWN information,) you don't even need short frames.  Ralph -
you do need short frames to identify particular connections within the
collection that makes up a link.

Elizabeth - consensus we have sufficient information.  Should we
actually implement the bidirectional short frame?  One vote "yes," three
votes "no", out of fourteen some companies, nine of which are
represented on this call.  Should this go to the author's mailing list?
Ralph suggests that won't fundamentally change the vote.  Elizabeth
agrees, and recommends that -08 draft of NAPT be posted to the reflector
(as a separate item.)  Suggests that a discussion period be requested
ending around November 9th, so there is time to meet the final draft
cutoff date.

Ralph - this would give us a draft to be reviewed by the 14th, with a
final submission shortly thereafter.  Bob - and that would be ready for
final call, excepting the security issues.

Ralph - we could take those two paragraphs out, and leave it to the
reader to figure it out whether you can or can not merge parallel
connections.  Elizabeth - yes, but would it be interoperable?  Larry -
not without the bidirectional short frame.  Bob - bidirectional short
frame is a red herring here, real question is whether you attempt to
merge the connections or not.  Ralph - and we're back to the same
question again.

Elizabeth - I'll ask the question again.  Do we need those two
paragraphs or not? 

Larry - if those paragraphs go, the one paragraph further down (about
handing an incoming connnection) needs to go too.  Elizabeth - my
perspective is that the two paragraphs should go.  Bob -
interoperability aside?  Ralph - interoperability is at another level
anyway.  Raj - does this then say that the parallel connections
represent the same link?  Ralph - The wording to describe the effect
remains, but the wording that describes the results of that effect would
be eliminated. Elizabeth - Raj, do you think they should stay?  Raj - I
have no problem with this, but they will be in separate links.  

Elizabeth - Since I hear no one on the call who believes the paragraphs
should stay in, I recommend they be taken out.

Raj - I have one question about the connection use flags.  Do both ends
have to agree on how many connections will be used?  Larry - if your
Class F connection goes down, are you not going to send Class F, or are
you going to send it on another connection?  I think you should make a
new connection, but the way it's worded we have to wait for the other
guy to make the connection, and you're sitting on Class F, or you're
sending it mixed with Class 2 or Class 3 stuff and hoping the other guy
can sort it out.

Ralph - Raj's question is a routing question, and therefore has to be
answered in BB.

Bob - I would expect that the connection initiated for Class F would be
used for Class F, and that no other connection would carry Class F
because of ordering issues.  What happens when the Class F connection
goes down?  What happens when any other connection goes down? Of course,
if you're using something like the Virtual Channel stuff Larry was
talking about for Class 4, you could use one of them for Class F.

Ralph has submitted document to the email reflector.

Next call will be hosted by Qlogic .