Subject: [imss] FW: Last Call: 'Transmission of IPv6 Packets over Fibre Channel' to Proposed Standard

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 9 Apr 2004 14:05:47 +0200

Here are some last minute comments/questions that we got from
one of the IPv6 WG chairs. Can you send an answer please.

Thanks,
Bert 

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]]
Sent: donderdag 8 april 2004 18:53
To: Wijnen, Bert (Bert); [email-masked]
Cc: Thomas Narten; Margaret Wasserman (E-mail); Bob Hinden
Subject: Re: Last Call: 'Transmission of IPv6 Packets over Fibre
Channel' to Proposed Standard

Hi All,

I just have a few comments/questions on this draft.  On the whole,
it looks good to me.

1. 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?

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.

3. Section 6 - I would think that this section needs to at least say
    that the rules defined in RFC 2462 should be followed.  And any
    variations from that document need to be explicitly stated here.

4. Section 9 - Again a mention of 1024 octets rather than 1280.

5. 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?

Thanks,
Brian

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

---

From: Claudio DeSanti <[email-masked]>
Date: Mon, 12 Apr 2004 13:22:50 -0700

Hi Brian,

thanks for your review. My replies are in-line.
Please tell me if they solve your issues.
Thanks,

                     Claudio.

>    a single frame?  Does that affect the ability to support the minimum

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.

>    that doesn't include any Optional Headers.

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.

>    variations from that document need to be explicitly stated here.

Section 6 is all about following the RFC 2462 rules, and that RFC is 
referenced in the third paragraph of section 6.1. If we want to make this 
more explicit, that paragraph may be reworded as follows:

"Stateless address autoconfiguration MUST be performed as specified in 
[ACONF]. An IPv6 Address Prefix used for stateless address 
autoconfiguration of an Nx_Port MUST have a length of 64 bits."

>4. Section 9 - Again a mention of 1024 octets rather than 1280.

See my reply to point 2.

>    in?  If so, should the NDP behavior be different between p2p, loop,

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.