Hi Elwyn, Thanks for reviewing this draft.
> s3.1: The encoding of the PT values is not specified. It's a 3-bit binary field (e.g., 6 is encoded as 110). I don't see a need to explain this. > Should an explicit error behaviour for control words with PT set to something > other than 1,2, 4 or 6 be specified? Yes, but the valid PT values are 0, 1, 2 and 6. A packet with an invalid PT value (3, 4, 5 or 7) needs to be discarded, as it's corrupt or otherwise invalid for the FC PW (cannot be turned into FC traffic or otherwise usefully processed). I'll add a sentence. > s3.1: I note that RFC 3985 fails to specify the unit of the Length > parameter (presumably bytes/octets, but since it seems to be used in > various different ways it might be application specific) and does not > specify the encoding for the parameter. This specification propagates > this omission. RFC 3985 is the wrong reference - the Length field is specified in RFC 4385, which is cited at the beginning of s3.1. The Length field is only used when the PW packet is shorter than 64 bytes because Ethernet will pad such a packet out to 64 bytes - the Length field allows the additional padding to be stripped. When the packet is 64 bytes or longer, the Length field is set to zero. > s3.3: FC Frames: How is the Length field in the control word used here? See RFC 4385. > Are there constraints on the Payload Type for this case? Yes, PT=0 or PT=1. The other PT values are not for frames. I'll add a sentence. > s3.3: Discussion of encoding of ordered sets: Is there an upper limit > on the number of ordered sets in a single PW packet? Yes, the total PW packet size can't exceed the MTU. I'll add a sentence that points back to the MTU discussion in s3.2 . > This isn't made > explicit but the size of the Length field which is supposed to be used > for 'short packets' possibly restricts the number of ordered sets. If > this is not the case how is the length specified if the total is more > then 64 whatevers (see the comment above on s3.1). The Length field does not impose a restriction smaller than the MTU - see RFC 4385. > s3.3: Discussion of encoding of ordered sets: What payload types are > allowed for this case? PT=2, I'll add a sentence. > s3.3: Discussion of FC PW Control Frames: How is the Length field in the > Control Word used in this case? > If it isn't used, how is the size of the frame determined? See RFC 4385. FC PW Control Frames are short enough that Length will always be non-zero. > Nits/editorial comments: If I make no comment below, I'll just fix it. > Abstract/Section 1: For whatever reason the RFC Editor deems MPLS-TP to > be a well-known abbreviation but not MPLS-TE.. so I guess MPLS-TE better > be expanded. I'll just reduce this to MPLS-TP. > s1, next to last para: s/by comparison to/by comparison with (or in > comparison to)/ > > s1.1, para 1: expand GFPT. > > s3: Is [FC-FS-2] a sufficient reference for the definition of 8b/10b > encoding? I can't see the full text so I can't tell. There are lots of > jargon items relating to 8b/10b later in s3. Yes, [FC-FS-2] is sufficient - let me know if you want a copy of FC-FS-2 (I am authorized by T11 to send you one). > s3: This section contains a number of FC jargon terms. Some of them (in > the first set of bullet points - FC-SW, FC-P2P, FC-AL) are not expanded > at all. Others in the second set of bullets (FLOGI, PLOGI, ELP) are > expanded on second appearance a little lower down. Towards the end > 10GFC and 16GFC may also need expansion or a reference. > > s3, next to last para: (just checking!) Is Service class F right? Others > are numbers. Service class F is correct. The numbered service classes are end-to-end in FC, whereas F is an inter-switch service class (F is for Fabric). > s3.3: Might be clearer if organized into three sub-sections for the > three types of item transported. That makes sense, will do. > s3.3: A reference for the definitions of the FC Service Class 4 values > mentioned (SOFi4, etc) is needed. It's [FC-FS-2] again - I'll add a citation. > s7, next to last para: RFC 3821 appears to prefer FCIP rather than FC/IP > as an abbreviation. Ok. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [email protected] Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Elwyn Davies > Sent: Wednesday, February 16, 2011 12:59 PM > To: General Area Review Team > Cc: [email protected] > Subject: [Gen-art] Gen-art LC review of draft-ietf-pwe3-fc-encap > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-pwe3-fc-encap-14.txt > Reviewer: Elwyn Davies > Review Date: 16 February 2011 > IETF LC End Date: 21 February 2011 > IESG Telechat date: (if known) - > > Summary: This document still has some minor issues mainly relating to > the (specification of the) usage of the Length and Payload Type fields > in the PW Control Word. There are also some editorial items that need > fixing. > > Major issues: > None > > Minor issues: > s3.1: The encoding of the PT values is not specified. Should an > explicit error behaviour for control words with PT set to something > other than 1,2, 4 or 6 be specified? > > s3.1: I note that RFC 3985 fails to specify the unit of the Length > parameter (presumably bytes/octets, but since it seems to be used in > various different ways it might be application specific) and does not > specify the encoding for the parameter. This specification propagates > this omission. > > s3.3: FC Frames: How is the Length field in the control word used here? > Are there constraints on the Payload Type for this case? > > s3.3: Discussion of encoding of ordered sets: Is there an upper limit > on the number of ordered sets in a single PW packet? This isn't made > explicit but the size of the Length field which is supposed to be used > for 'short packets' possibly restricts the number of ordered sets. If > this is not the case how is the length specified if the total is more > then 64 whatevers (see the comment above on s3.1). > > s3.3: Discussion of encoding of ordered sets: What payload types are > allowed for this case? > > s3.3: Discussion of FC PW Control Frames: How is the Length field in the > Control Word used in this case? If it isn't used, how is the size of > the frame determined? > > Nits/editorial comments: > Abstract/Section 1: For whatever reason the RFC Editor deems MPLS-TP to > be a well-known abbreviation but not MPLS-TE.. so I guess MPLS-TE better > be expanded. > > s1, next to last para: s/by comparison to/by comparison with (or in > comparison to)/ > > s1.1, para 1: expand GFPT. > > s3: Is [FC-FS-2] a sufficient reference for the definition of 8b/10b > encoding? I can't see the full text so I can't tell. There are lots of > jargon items relating to 8b/10b later in s3. > > s3: This section contains a number of FC jargon terms. Some of them (in > the first set of bullet points - FC-SW, FC-P2P, FC-AL) are not expanded > at all. Others in the second set of bullets (FLOGI, PLOGI, ELP) are > expanded on second appearance a little lower down. Towards the end > 10GFC and 16GFC may also need expansion or a reference. > > s3, next to last para: (just checking!) Is Service class F right? Others > are numbers. > > s3.3: Might be clearer if organized into three sub-sections for the > three types of item transported. > > s3.3: A reference for the definitions of the FC Service Class 4 values > mentioned (SOFi4, etc) is needed. > > s7, next to last para: RFC 3821 appears to prefer FCIP rather than FC/IP > as an abbreviation. > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
