Subject: [imss] Reminder: IMSS Working Group last call on IPv6 over Fibre Channel Draft Ends Monday Nov 24

From: "Elizabeth Rodriguez" <[email-masked]>
Date: Thu, 20 Nov 2003 10:44:47 -0800

This is a reminder that the FC over IPv6 draft is currently in IMSS working
group last call.  The last call period ends on November 24 at 9pm EST.

The draft may be found at 
www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel-00.txt

A link to the draft may also be found at the bottom of the IMSS WG home page
at www.ietf.org/html.charters/imss-charter.html.  This page also includes
instructions on subscribing to the mailing list.

If anyone has comments against this draft, please post them to the IMSS
mailing list.  If the comments are only editorial in nature, they may be
posted to the mailing list or send directly to the author with copies to the
chair and technical advisors as indicated below.

The original WG Last Call announcement follows.

Thanks,
Elizabeth Rodriguez
IMSS Chair

Note:  The URLs above have been verified. If the URLs above do not work for
you, make sure your mailer has not split the URL over two lines.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Sunday, November 02, 2003 8:59 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: [imss] IMSS: Working Group last call on IPv6 over Fibre Channel
Draft

Hello,

I would like to announce the IETF IMSS Working Group last call on the IPv6
over Fibre Channel draft.
The draft may be found at
http://www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel-
00.txt
The last call period will end at 9pm EST on Monday, November 24, 2003.  

Please address any technical comments to the IMSS mailing list at
[email-masked]. 
Editorial comments may be made directly to the draft author, Claudio
DeSanti, at [email-masked].
Please copy me at [email-masked] and our technical
coordinators for this draft, David Black ([email-masked]) and Margaret
Wasserman ([email-masked]).

Summary:

Draft:  IPv6 over Fibre Channel
Draft URL:
http://www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel-
00.txt
WGLC ends: Monday, November 24, 2003 at 9pm EST
Technical comments to: [email-masked]
Editorial comments to: Claudio DeSanti ([email-masked]), David Black
([email-masked]), Margaret Wasserman ([email-masked]) and
Elizabeth Rodriguez ([email-masked])

Thank you,

Elizabeth Rodriguez
IMSS Chair

IMSS Charter: http://www.ietf.org/html.charters/imss-charter.html
To subscribe to the IMSS mailing list, see
https://www1.ietf.org/mailman/listinfo/imss

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

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 20 Nov 2003 22:34:24 +0200 (EET)

> www.ietf.org/internet-drafts/draft-ietf-imss-ipv6-over-fibre-channel-00.txt
[...]

Thanks for the reminder.  I figured I should contribute with a review.
Note: I know nothing about Fibre Channel.

In general, I think the document is very good quality.  Thanks for
writing it.  It's even vaguely comprehensible to non-FC folks, even
though terminology quickly introduced in section 2 took quite a while
to handle.  I think the issues should be easily fixable.

I've split the comments to a couple rough categories, categories
sorted in the decreasing priority, the contents within the catories in
the same order as the text.

the biggest issue
-----------------

5. Maximum Transfer Unit

   The default MTU size for IPv6 [IPv6] packets over Fibre Channel is
   65280 octets. This size may be reduced by a Router Advertisement
   [DISC] containing an MTU option that specifies a smaller MTU, or by
   manual configuration of each Nx_Port. However, as required by [IPv6],
   the MTU MUST NOT be lower than 1280 octets. If a Router Advertisement
   received on an Nx_Port has an MTU option specifying an MTU larger
   than 65280, or larger than a manually configured value, that MTU
   option MAY be logged to system management but MUST be otherwise
   ignored.

==> has this been discussed?  As long as you use FC e.g. between
storage devices, this is fine, but if you'd use it to access Internet,
this default MTU could be a real pain, because 1500 MTU is de-facto
standard out there in the big I.  

I'd suggest adding non-normative discussion text that clarifies
whichever position you want to make (e.g., describe when you really,
really should to use the MTU option if you stick with the default.)

a bit more substantial
----------------------

1. Introduction

==> Introduction is pretty much identical to the abstract.  This is typically considered 
a bad idea, and shows that either Abstract or Introduction has not been fully utilized 
and properly written.

   - The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC,
     0xD, 0xE, 0xF. Other Name_Identifier formats are not acceptable to
     support IPv6;

reword to:

   - The format of its N_Port_Name MUST be one of 0x1, 0x2, 0x5, 0xC,
     0xD, 0xE, 0xF. IPv6 support for other Name_Identifier formats is 
     outside the scope of this specification.

(similar in section 4.4)

...

   - It MUST be able to transmit and receive an FC-4 Information Unit
     at least 1304 octets long;

[not just issue in this sentence, but triggered by it because I 
started looking where the 1280+24 comes from..]

==> the doc is not clear (at least to someone not well versed with FC
:-) what Information Unit refers to; is it "Data field" or "Frame
payload" in figure 1?  There seems to be some confusing text because
fig 2 shows also the Optional Header but other text discusses this as
if this was different?

(maybe a terminology section could be considered, but I'm not sure if 
that'd actually help that much..)

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |  Length = 2   |           Reserved            |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    +-                         N_Port_Name                         -+
    |                                                               |
    +---------------+---------------+---------------+---------------+
    |                   N_Port_ID                   |   Reserved    |
    +---------------+---------------+---------------+---------------+

==> should maybe specify that Reserved fields MUST be zero when
transmitting, and MUST be ignored when receiving (the typical MBZ
rule) ?

   Receiving an FC Sequence carrying an IPv6 multicast packet MAY
   trigger some additional processing by the Nx_Port if that IPv6 packet
   requires a reply. In this case, if a valid Port Login to the Nx_Port
   that sent the IPv6 multicast packet does not exist, the Nx_Port MUST
   perform such a Port Login, and then use it for the unicast IPv6
   reply. In the case of Neighbor Discovery messages [DISC], the 
   N_Port_ID to which the Port Login is directed is taken from the    
   N_Port_ID field of the Source/Target Link-layer Address option. 

==> is it needed to specify "unicast" here?  Isn't it at least
theoretically possible that you'd receive a multicast packet, and want
to reply with a multicast packet of your own?  (similar later in the
spec)

mostly editorial issues
-----------------------

==> ID-nits: no references in the abstract, please.

                           IPv6 over Fibre Channel

==> maybe reword this to: "Transmission of IPv6 Packets over Fibre
Channel"  (more similar to other IPv6-over-FOO document names) ?

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [KEYWORDS].

==> I'd put that at the end of the Introduction section; that's where
it normally resides.

   Warning to readers familiar with Fibre Channel: both Fibre Channel
   and IETF standards use the same byte transmission order. However, the
   bit numbering is different. See Appendix C for guidance.

==> I'd rather place this in the Introduction.

   - F_CTL, SEQ_ID, SEQ_CNT, OX_ID, RX_ID: see section 10, section 11,
     and [FC-FS] for additional requirements.

==> D_ID, S_ID, and Parameter were not described here. 

typos or very minor nits
------------------------

IMSS Working Group                                       Claudio DeSanti

==> s/Claudio/C./ (that's just a convention, the same at the bottom of 
each page :-)

   transmission words that act as frame delimiters. The CRC is 4-octets
==> s/4-/4 /

   The FC Header is 24-octets long and contains several fields
==> s/24-/24 /

   ordering, that corresponds to the standard network byte order or

==> s/,// (or use "which", typically don't use comma before "that")

6. Stateless Autoconfiguration

==> s/Auto/Address Auto/ (similar elsewhere; the formal name is 
"stateless address autoconfiguration")

6.5 Generating an Interface ID from a EUI-64 mapped N_Port_Name

==> s/a EUI-64/an EUI-64/ (similar elsewhere)

   An Exchange Responder is not required to assign RX_IDs. If a RX_ID 
of

==> s/a RX_ID/an RX_ID/ (similar elsewhere?)

  The Exchange Originator MAY terminate Exchanges by setting the F_CTL
   LS bit [FC-FS]. Exchanges MAY be torn down by the Exchange Originator
   or Exchange Responder by using the ABTS protocol. IPv6 Exchanges
 
==> spell out ABTS, maybe refer to it (the only time the term is used 
in this document)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fred Templin <[email-masked]>
Date: Thu, 20 Nov 2003 13:11:34 -0800

~64KB MTU L2 media, huh? Sounds interesting.

Has there been any consideration given to L2 bridging
between FiberChannel and other media such as Gbps
and 10/100 Ethernet, or are you expecting everything
between dissimilar media to go through a router?

Thanks - Fred
[email-masked]

Elizabeth Rodriguez wrote:

>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
>  
>

---

From: Claudio DeSanti <[email-masked]>
Date: Thu, 20 Nov 2003 15:11:21 -0800

Hi Pekka,

thanks a lot for your comments. See in-line for my replies.

                             Claudio.

>the same order as the text.

The 65280 octects MTU size comes from the IPv4 over Fibre Channel 
specification, RFC 2625, and one of the goal of the IPv6 over FC spec is to 
reuse the encapsulation defined for IPv4.
It is clearly different than the ethernet MTU, but I do not see any 
particular issue with this number, considering that both Path MTU discovery 
and the MTU option in router advertisements may take care of it. In 
particular, I would assume that an IPv6 router connecting a Fibre Channel 
fabric with networks of different technologies would announce an 
appropriate MTU on the FC side.

>really should to use the MTU option if you stick with the default.)

I'll use your additional suggestions to differentiate the introduction 
section from the abstract section. Moreover, I could change the title 
"Introduction to Fibre Channel" to "Fibre Channel in a nutshell" (or 
something similar) to avoid two "Introduction" in a row.

>      outside the scope of this specification.

Ok.

>that'd actually help that much..)

This requirement translates in Fibre Channel terms the IPv6 requirement 
that each link must have an MTU equal or greater to 1280 octects. The 
number 1304 comes from Figure 2.
The Information Unit term is introduced in section 2.4, and used in section 
4.1 to explain the IPv6 - FC mapping. I recognize that sometimes I used the 
term "Information Unit" and sometimes the term "Sequence payload". Altough 
a Fibre Channel person is able to contextualize both terms, a more 
consistent terminology may be appropriate here.

Ok.
Additionally, I recently noticed that swapping the last reserved field with 
the N_Port_ID field could slightly facilitate the processing in 32 bit 
processors, because the N_Port_ID field would be in the "right" place to 
directly load the word in a register. The option would be as follows:

     |   Reserved    |                   N_Port_ID                   |

Any comment on this idea?

>to reply with a multicast packet of your own?  (similar later in the

I believe we need the unicast word. The case in which you want to reply 
with a multicast packet will be handled by the default broadcast login, and 
does not require a specific port login to be performed.

>mostly editorial issues

I may do that. The current title comes from RFC 2625: "IP and ARP over 
Fibre Channel"

>==> I'd rather place this in the Introduction.

Ok for both suggestions.

>==> D_ID, S_ID, and Parameter were not described here.

I may add them to this list.

>typos or very minor nits

I'm ok with all the above editorial comments. A small note on "which" and 
"that": "which" is almost forbidden in ANSI standards, so I'll remove the 
comma and keep the "that".
Thanks,

                         Claudio.

---

From: Claudio DeSanti <[email-masked]>
Date: Thu, 20 Nov 2003 15:29:14 -0800

Hi Fred,

the ~64KB MTU comes from RFC 2625 (IPv4 over Fibre Channel), and one of the 
goals of the IPv6 over FC specification is to keep unchanged the 
encapsulation technique between IPv4 and IPv6.

I understand that with IPv6 a bridge has no more the option to fragment a 
too big packet, as in IPv4, but I do not believe this is an issue, because:
- router advertisements may announce a proper MTU over a bridged network;
- current deployments are almost entirely based on routers instead than on 
bridges.

In any case, if the group believes this to be an issue, then we have the 
same issue also for RFC 2467 (Transmission of IPv6 Packets over FDDI 
Networks), where the default MTU is 4352 octets. If it is not a problem 
there, then it is neither a problem here.

Thanks,

                                     Claudio.

At 01:11 PM 11/20/2003 -0800, Fred Templin wrote:
>>[email-masked]. Editorial comments may be made directly to the draft 
>>author, Claudio

---

From: Bob Hinden <[email-masked]>
Date: Fri, 21 Nov 2003 09:48:26 -0800

Pekka,

>really should to use the MTU option if you stick with the default.)

I agree this is a good point.  It would also be good to mention that an 
IPv6 node is not required to reassemble fragments that total more than 1500 
bytes.  The text from RFC2460:

    A node must be able to accept a fragmented packet that, after
    reassembly, is as large as 1500 octets.  A node is permitted to
    accept fragmented packets that reassemble to more than 1500 octets.
    An upper-layer protocol or application that depends on IPv6
    fragmentation to send packets larger than the MTU of a path should
    not send packets larger than 1500 octets unless it has assurance that
    the destination is capable of reassembling packets of that larger
    size.

Running when with a MTU larger than 1500 a node can not assume that it can 
fragment a packet larger than 1500 sent to off link destinations.

Also, adding a note to the draft that when running with an MTU larger than 
1500, supporting path mtu discovery is a very good idea (i.e., SHOULD++++).

To make MTU's larger than 1500 more useful we might want a mode of 
operation where there was one MTU for on link communication and another MTU 
for off link communication.  As you point out that off link MTU would be 
1500 in today's Internet.  This isn't something that we have discussed 
before as far as I can remember.

Bob

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Nov 2003 04:35:31 +0200 (EET)

Hi,

Thanks for the very quick reply; I'll have a couple of more comments 
inline, and cut out the rest..

> appropriate MTU on the FC side.

There is no *specification* problem but there is IMO a very large 
*operational* problem.

Remember that the one thing where v6 differs from v4 is that there is 
no on the path fragmentation -- you have to rely on PMTUD or have MTU 
configured correctly; further I'm not sure if PMTUD would be performed 
only once (for the default route) or for every destination.  I hope 
the first, but even so, such cached state is typically subject to 
timeouts.

So, I'd consider adding some statement after that, like:

  As the default MTU size far exceeds the message sizes typically used 
  in the Internet, and Path MTU Discovery is a non-optiomal mechanism,
  extreme care should be observed if connecting a node to Internet 
  using FC; it is critically important to configure the MTU option in 
  the Route Advertisements.

(this spec is maybe not 100% correct place for this, but for the lack 
of a better one... :-)

> number 1304 comes from Figure 2.

Yep.

> consistent terminology may be appropriate here.

Thanks -- this will probably be clearer with a bit of rewording.
 
> does not require a specific port login to be performed.

Right.  I know nothing of that :-) .. but how I read the spec was
"replies to multicasts are unicasts, if any" -- which need not be
true.  Maybe worth checking whether minor rewording would clarify 
that.

---

From: "Chirayu Patel" <[email-masked]>
Date: Fri, 21 Nov 2003 08:40:55 +0530

On Thu, 20 Nov 2003 15:29:14 -0800, "Claudio DeSanti"
<[email-masked]> said:

> I understand that with IPv6 a bridge has no more the option to fragment
> a too big packet, as in IPv4, but I do not believe this is an issue,
> because:

ND-proxy draft has the same recommendation for handling MTU within a
subnet comprising of multiple L2-technologies.

You can find the draft at:
http://www.ietf.org/internet-drafts/draft-thaler-ipv6-ndproxy-01.txt
Section 4.1.3.3 covers processing of RA's.

CP

---

From: Claudio DeSanti <[email-masked]>
Date: Fri, 21 Nov 2003 14:55:39 -0800

Hi Bob,

thanks for your comments. I think we are hitting here a more general 
problem. FDDI has exactly the same issue, having a default MTU of 4352 octets.
May be the following text (taken from RFC 2467, IPv6 over FDDI), plus a 
strong recommendation that Fibre Channel hosts supporting IPv6 SHOULD also 
implement PMTU discovery is what that we need.

    Use of IPv6 in a
    bridged mixed-media environment must not depend on support from
    bridges, unless those bridges are known to correctly implement IPv6
    Path MTU Discovery [RFC 1981, ICMPV6].

    For correct operation when mixed media are bridged together by
    bridges which do not support IPv6 Path MTU Discovery, the smallest
    MTU of all the media must be advertised by routers in an MTU option.
    If there are no routers present, this MTU must be manually configured
    in each node which is connected to a medium with a default MTU larger
    than the smallest MTU.

Interestingly the "must" in this text are not written as "MUST".
Comments?

                   Claudio.

At 09:48 AM 11/21/2003 -0800, Bob Hinden wrote:
>IPv6 node is not required to reassemble fragments that total more than 
>1500 bytes.  The text from RFC2460:
>
>operation where there was one MTU for on link communication and another 
>MTU for off link communication.  As you point out that off link MTU would 
>be 1500 in today's Internet.  This isn't something that we have discussed

---

From: Pekka Savola <[email-masked]>
Date: Mon, 24 Nov 2003 14:23:46 +0200 (EET)

> implement PMTU discovery is what that we need.

Yep, but RFC 2467 was published 5 years ago, and now we should know 
better :-)

I think Bob's point about different MTU's for "on-link" and "off-link" 
might be a good idea.  Or at least describe issues that might result 
from the use of a MTU higher than 1500.

> Interestingly the "must" in this text are not written as "MUST".

The reason probably is that the "must" refers to an operational 
procedure by network administrators, not something IPv6 over FOO 
implementers can fix.

---

From: Claudio DeSanti <[email-masked]>
Date: Tue, 25 Nov 2003 11:22:25 -0800

Pekka, Bob,

I think the following text should capture all the suggestions. Are you ok 
with it?

   As the default MTU size far exceeds the message sizes typically used in the
   Internet, it is strongly recommended that an IPv6 over FC host implement 
Path
   MTU Discovery, or at least maintain different MTU values for on-link and
   off-link destinations.

   For correct operation in a routed environment, it is important to 
configure an
   appropriate MTU option in Router Advertisements.

   For correct operation when mixed media are bridged together, the 
smallest MTU
   of all the media must be advertised by routers in an MTU option. If 
there are
   no routers present, this MTU must be manually configured in each node which
   is connected to a medium with a default MTU larger than the smallest MTU.

Thanks,

                                Claudio.