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

["Elizabeth Rodriguez" <egrodriguez@lucent.com>]

Title: NAPTs Solution r08

 

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 .