Subject: [imss] Other comments

From: Claudio DeSanti <[email-masked]>
Date: Fri, 16 Apr 2004 19:35:03 -0700

There are few other comments, which I forgot to mention in the previous 
mail, because they did not go into the document.
Thanks,

                           Claudio.

----------

 From Michael Patton:

>As previously mentioned, I'd like to see a general description of what
>FC is.  As far as I can tell, this document describes a mesh which
>supports port-to-port unicast and broadcast (with a comment about
>optional multicast).  I'm a bit worried that the architecture
>described is N-squared requiring every node to maintain a separate
>connection to every other node and manage state for that connection
>(called Exchanges in the FC lingo).  This is a general problem of mesh
>topologies, so I'm not sure there's much that can be done, but I'd
>like to see a mention of this aspect.  Hopefully, FC fabrics will be
>able to handle that quantity of Exchanges.  Furthermore, it explicitly
>disclaims as "outside the scope of this document" the techniques for
>dealing with that.

Response: Section 2 is aimed to describe what Fibre Channel is. There may 
be scalability issues in this architecture, but the goal of this draft is 
simply to define how to carry IPv6 over this technology.

>The acronym ESP applies both at the FC layer and the IPv6 layer.  What
>it means at the FC layer is not explained (nor is its meaning at the
>IPv6 layer, but I know that one).  From context it seems reasonable to
>assume that they are, in fact, similar, but that should be mentioned.
>Now, given my assumption that they are similar, I see them both
>mentioned in section 4.1, mentioning that either may be used for
>security.  Yet, there is no discussion, either in that section or in
>the Security Considerations section, of what the tradeoffs are for
>choosing one or the other.  [I actually know, but think it should be
>explicitly stated in the document somewhere.]

Response: The security considerations section has been improved in response 
to Russ Housley's comment. Being this a specification for how to carry IPv6 
over this technology, the important point to say are that every security 
method defined for IPv6 may be used also in this environment. What Fibre 
Channel may offer in terms of security is still partially under development.

 From Brian Haberman:

>    Section 2.3 - Can all of the defined Optional Headers appear in
>    a single frame?  Does that affect the ability to support the minimum
>    MTU of 1280?

Response: Yes, No. An important characteristic that differentiates Fibre 
Channel from other technologies is that it maps an IPv6 packet to a 
sequence of frames, not to a single frame, as explained in section 2.4.
An IPv6 packet is called Information Unit in fibre channel terminology. 
Size requirements on IPv6 are then information unit requirements on Fibre 
Channel. An information unit is mapped by Fibre Channel to a sequence of 
frames, not to a single frame, and this explain, among the other things, 
how the default MTU for IPv6 over FC is 65280 octets, while the maximum 
frame payload size is 2112 octets. The information unit to sequence mapping 
is performed by Fibre Channel and is transparent to IPv6.
The usage of optional header is specific to each protocol mapped over Fibre 
Channel. Most optional headers are per information unit (which means they 
are present only on the first frame of a sequence), while others are per 
frame (which means they are present in each frame of a sequence). For IPv6, 
section 4 of this document specifies that the Network_Header MUST be used 
with the LLC/SNAP header, that the ESP_Header MAY be used, and that other 
types of optional headers MUST NOT be used. The ESP_Header is a per frame 
optional header, and as such it is transparent to the size of the original 
information unit. Then the requirement to support the minimum IPv6 MTU of 
1280 octets translates in the requirement to support an information unit at 
least 1304 octets long (bullet 4 in section 3), which is 1280 (IPv6) + 16 
(Network_Header) + 8 (LLC/SNAP header). See also figure 2.

>    Section 3, 5th bullet - Why is the receive data size minimized at
>    1024 octets?  I would think that this should be 1280 for IPv6, and
>    that doesn't include any Optional Headers.

Response: This is a frame size requirement, not an information unit 
requirement. As explained in section 2.2, fourth paragraph, before 
effective communication is possible between two Nx_Ports, a port login has 
to be performed, to exchange operational parameters. A critical parameters 
for the sequencing mechanism is the maximum frame size that may be received 
by an Nx_Port. When this parameter is known, an information unit will be 
segmented in a sequence of frames, each of them not bigger than the maximum 
receive data field size. So this requirement does not limit the size of an 
information unit.
This requirement is needed for multicast/broadcast data transmission. For 
unicast communication an explicit login may be performed, i.e., an exchange 
of frames carrying the Nx_Ports' operational parameters. For broadcast 
transmission it is no possible to perform an explicit login, and then the 
login has to be implicit, so with parameters known "a priori", i.e., set by 
this specification. 1024 is a receive data field size that accommodates any 
current implementation, and this is the reason why it has been chosen. The 
requirement is carefully worded as a SHOULD, because if in a particular 
environment the network administrator knows that all the involved Nx_Ports 
are capable to support a bigger receive data field size, it may configure 
them accordingly. The only real requirement, as explained in section 9, 
second paragraph, is that the chosen parameter MUST be equal across all the 
IPv6 communicating Nx_Ports.

>    Section A - Can a node determine in which mode each port is working
>    in?  If so, should the NDP behavior be different between p2p, loop,
>    and fabric mode?

Response: An Nx_Port always determines in which mode it is working, p2p, 
loop or fabric, but all of that is transparent to the upper layer. The 
Neighbor Discovery behavior is the same across the three topologies.

_______________________________________________
imss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/imss