Subject: [imss] FW: INT Area Review: draft-ietf-imss-ip-over-fibre-channel-01.txt

From: [email-masked]
Date: Wed, 12 Oct 2005 15:17:44 -0400

Internet Area Expert Review comments on the new IP over FC
draft are below.  Based on further conversation w/Brian, it's
ok not to update the references (Section 17 comment below) in
order to avoid getting caught in a REF (reference) hold at
the RFC Editor.  Many thanks to Brian for doing this review.

The authors should prepare a -02 version of this draft
to address these comments (and update the boilerplate while
they're at it).  They should make sure it passes the ID nits
checker at: 

http://tools.ietf.org/tools/idnits/idnits.pyht

before submitting.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Wednesday, October 12, 2005 9:18 AM
To: Margaret Wasserman
Cc: Black, David; Bert Wijnen
Subject: Re: INT Area Review: draft-ietf-imss-ip-over-fibre-channel-01.txt

Margaret & Bert,
      Here are my comments on this draft.  Overall, I think it looks pretty
good.

General Comments
--------------------------

      - The document needs to be consistent in its terminology on
         whether it is updating or obsoleting RFCs 2625 and 3831.
         The language in the Introduction seems to contradict the
          information in the document header.

Section 3
------------

      - I would like to see some rationale/explanation for the values
        1304 (in the fourth bullet) and 1024 (In the fifth bullet).  How
        are those values derived and how are they related?

Section 4.1
---------------

      - The last paragraph allows more than one frame to be included
         in an IP FC Sequence.  It states that only the first frame has an
         FC Network Header and LLC/SNAP Header.  I assume that
         means that all frames in the sequence must be the same protocol.
         It would be nice if that was stated explicitly and some reasoning
         given.

Section 4.3
--------------

      - Does routing traffic need to be mentioned in this list?
Specifically,
         how does routing traffic get handled?

      - Can the exceptions to the SHOULD be spelled out?

Section 4.8
--------------

      - With an MTU of 65280 octets is Jumbogram support needed?

Section 5.2
--------------

      - There is an implication that the FC U/L bit has the same semantics
         as the Ethernet U/L.  I believe that is true, but it would help if
it were
         mentioned.

      - I don't see the benefit of having both figures 9 & 10.

Section 5.3
---------------

      - I don't see the benefit of having both figures 12 & 13.

      - The last sentence contains an example interface ID of
         3463:462A:BCDE:F789.  I don't see where the x789
         portion comes from?  Is it just an example?  It may be
         clearer to replace those with 'xxx'.

Section 7
------------

      - The discussion of ARP opcodes should probably reference the
         [ARP] spec.

Section 9.3
--------------

      - (bullet 4) Should the responder cache info from the Request packet?

Section 17
-------------

      - The references to [AARCH], [ACONF], [DISC], and [ICMPv6] should
         probably be updated to the latest versions that are done or nearly
         done within the IPv6 WG.

Regards,
Brian

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

---

From: Claudio DeSanti <[email-masked]>
Date: Wed, 12 Oct 2005 17:40:38 -0700

David,

thanks for the comments, in-line are my answers.
Please provide me feedback.

                    Claudio.

> http://tools.ietf.org/tools/idnits/idnits.pyht

The current text says:
"This document updates [RFC-2625] and, hence, replaces it."
"This document incorporates and updates [RFC-3831] and, hence, replaces it."

Would a more straightforward:
"This document replaces [RFC-2625]."
"This document replaces [RFC-3831]."
be better?

> Section 3

The 1304 bytes requirement just translates at layer 2 (with the 
Information Unit structure represented in figure 2) the minimum MTU 
required by IPv6 (as stated in the text). 1304 is 1280 (the minimum IPv6 
MTU) + 8 (LLC/SNAP Header) + 16 (Network_Header). I don't think further 
clarification is needed.

Th 1024 bytes requirement is needed for proper handling of multicast, 
and is discussed in detail in section 10. Would it be enough to add a 
reference to that section to the fifth bullet?

> Section 4.1

This is how the mapping of an IU to a Sequence is done, and is defined 
in FC-FS. FC-FS is referenced by this section, and I don't think we need 
to repeat here what is defined there. BTW, this section has the same 
text of RFC 3831.

> Section 4.3

The list is an e.g. list, and then it is not exhaustive. I can certainly 
add "IPv6/IPv4 Routing Protocols packets" to this list.

>       - Can the exceptions to the SHOULD be spelled out?

The reason for a SHOULD is to not completely close the door to Class 2 
for unicast data traffic, in the case somebody want to do it.

> Section 4.8

No, because Jumbogram support is required only for packets bigger than 
65536 bytes.

> Section 5.2

There is no concept of U/L bit in Fibre Channel, because the N_Port_Name 
is used only as an identifier, not as a locator (i.e., it is not used to 
forward frames). However FC-FS defines a way to map FC N_Port_Names in 
IEEE EUI-64 addresses, and in the EUI-64 addresses the U/L bit is 
present. This is the reason for having both figure 9 and 10, to show how 
the EUI-64 address is derived, and then to use it for IPv6. BTW, the 
text in this section is the same as in RFC 3831.

> Section 5.3

Please see my comment above.

>          clearer to replace those with 'xxx'.

The x789 are the second to fourth nibbles in the originating 
N_Port_Name. All the examples in section 5 are carefully crafted to show 
how the addresses are manipulated.

> Section 7

Would it be enough to change the line:
"- Opcode: 0x0001 for ARP Request, 0x0002 for ARP Reply;" to
"- Opcode: 0x0001 for ARP Request, 0x0002 for ARP Reply (see [ARP]);"?

> Section 9.3

Yes, as required by [ARP]. What about changing the first sentence of 
bullet 4 from:
"When a broadcast FC ARP Request is received by the Nx_Port with the 
matching IPv4 address, it generates a unicast FC ARP Reply."
to:
"When a broadcast FC ARP Request is received by the Nx_Port with the 
matching IPv4 address, that Nx_Port caches the information carried in 
the FC ARP Request in its local mapping tables and generates a unicast 
FC ARP Reply."?

---

From: Claudio DeSanti <[email-masked]>
Date: Mon, 17 Oct 2005 15:53:33 -0700

An updated I-D has been submitted. While the secretariat processes it, 
it may be accessed on the T11 web site by following this link:

http://www.t11.org/t11/docreg.nsf/ufile/05-092v2

The resolution of the Internet Area Expert Review comments is also 
available on the T11 web site:

http://www.t11.org/t11/docreg.nsf/ufile/05-741v0

Thanks,

                          Claudio.