Subject: [Gen-art] Gen-art LC review of draft-ietf-pwe3-fc-encap

From: Elwyn Davies <[email-masked]>
Date: Wed, 16 Feb 2011 17:59:21 +0000

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.

---

From: <[email-masked]>
Date: Fri, 18 Feb 2011 23:44:05 -0500

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

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.

> specify the encoding for the parameter.  This specification propagates

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.

> 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

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

PT=2, I'll add a sentence.

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

> be a well-known abbreviation but not MPLS-TE.. so I guess MPLS-TE better

I'll just reduce this to MPLS-TP.

> 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, next to last para: (just checking!) Is Service class F right? Others

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).

> three types of item transported.

That makes sense, will do.

> 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

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-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwyn Davies
> Sent: Wednesday, February 16, 2011 12:59 PM
> To: General Area Review Team
> Cc: [email-masked]
> Subject: [Gen-art] Gen-art LC review of draft-ietf-pwe3-fc-encap
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Elwyn Davies <[email-masked]>
Date: Sun, 20 Feb 2011 14:33:52 +0000

Hi, David.
> Thanks for reviewing this draft.
.. and for the responses.
> It's a 3-bit binary field (e.g., 6 is encoded as 110).  I don't see a need to explain this.
Maybe I am a bit pedantic here but it seems wise to be explicit about
the encoding since the values are sparse and the RFC 4385 defines these
bits as 'flags'.
> 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…
Fine.
> 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.
Actually RFC 4385 is also less than specific.  

In that case the paragraph:

>    A PW packet may contain one or more encoded FC Ordered sets [FC-BB-
>    6]. The length field in the FC PW Control Word is used to indicate
>    the packet length when the PW packet contains multiple Ordered Sets.
> 
is confusing as it implies that the Length field *always* tells you how 
many ordered sets are in the packet.

Overall the whole business of the packet length in PWE3 seems to be rather 
a mess (not the fault of the FC specification of course).  So one is reliant 
on the lower layers to tell you the packet lenghth (sometimes). Hmm! 
> See RFC 4385.  FC PW Control Frames are short enough that Length will always be non-zero.
Is a note about this a good idea?  If they were longer do you just have
to rely on the lower layer?  Is there any protection against corruption?
> If I make no comment below, I'll just fix it.
Fine.  Just one comment below.
> 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).
I'll trust you on this one! :-)

---

From: <[email-masked]>
Date: Tue, 22 Feb 2011 15:12:19 -0500

Elwyn,

> the encoding since the values are sparse and the RFC 4385 defines these

Ok, I'll point out that Figure 3 overlays a 3-bit binary PT field and a 1-bit unused field on RFC 4385's 4 bits Flags field.

> Actually RFC 4385 is also less than specific.

I can expand on this Length field slightly in this draft, but keep in mind that this is not causing PW interop problems in practice.

> many ordered sets are in the packet.
That sentence needs work, thanks for pointing it out.  In almost all cases, the number of ordered sets being sent is short enough that the Length field is non-zero, but it looks like there's a MUST requirement in here that an FC PW packet that carries ordered sets be less than 64 bytes long (would be capable of handling at most 15 ordered sets).  I'll add that.

> to rely on the lower layer?  Is there any protection against corruption?

I'll add the statement that the Length field is always used for FC PW Control frames.  The answer for longer FC PW control frames is that one would rely solely on lower layer checks, and there are .  The underlying received packet length is available from the PSN - the Length field is used to overcome an Ethernet limitation that may change that length between sender and receiver.

Thanks,
--David

> From: Elwyn Davies [mailto:[email-masked]]
> Sent: Sunday, February 20, 2011 9:34 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Gen-art] Gen-art LC review of draft-ietf-pwe3-fc-encap
> 
> Hi, David.
> > 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.
> >
> Fine.
> > 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).
> >

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 23 Feb 2011 13:19:08 +0000

Thanks.

Looks like we are done here.  I'll look out for the update.
Regards,
Elwyn