Re: [PWE3] Working Group Last Call for draft-ietf-pwe3-fc-encap-12.txt

[Yaakov Stein <[e-mail]>]

Linda

David's comments on the reliability issue is sufficient for me
(what I meant was how the FC reliability requirements impinge on the needed functionality at the PW level).

I didn't request repeating anything written in openly available documents.
However, not being a non-member of T11, I can not download the documents to which you refer.
So, the fact that there is a good explanation in FC-6
doesn't help me understand why this PW has functionality that is not required for all other PWs.

Y(J)S

From: Linda Dunbar [mailto:[e-mail]]
Sent: Monday, November 29, 2010 19:11
To: [e-mail]; Yaakov Stein; [e-mail]
Cc: [e-mail]
Subject: RE: [PWE3] Working Group Last Call for draft-ietf-pwe3-fc-encap-12.txt

Yaakov,

The "reliability requirements/features" you were asking is about FC reliability or the transport portion for FC (i.e. MPLS)?

If you are asking for FC reliability, as David has explained, FC-6 has really good explanation. I personally don't think it is a good idea to repeat FC-6 in IETF RFCs. FC-6 may change in the future; it will be a lot of effort for IETF to catch up with future changes made by T11.

NSP is also explained in FC-6. I would think reference to T11 document is a good idea.

Linda

________________________________
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, November 24, 2010 9:59 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [PWE3] Working Group Last Call for draft-ietf-pwe3-fc-encap-12.txt

Hi Yaakov,

Thanks for taking a look at this draft.

Your suggestions look reasonable - we can put them into a -13 version after the WGLC is over.

> I would also like, as early as possible in the document, for the reliability requirements/features
> to be called out.  The explanation of why there are unusual procedures here
> (the NSP, K-codes, timing constraints, etc) was not clear enough.

Sure, here's a brief summary of those three:

1) The NSP's primary job is adapting the native FC links to the PW, including an FC version of silence suppression (IDLE suppression).  There is some reliability functionality to ensure that the WAN link going down is reflected to the FC fabric and to prevent bringing up a WAN link that has excessive latency.

2) The K and D codes are part of the 8b/10b encoding used by the attached native FC links.  There's only one K-code in the draft, K28.5, and it's not a reliability measure for the PW, because the PW uses 8b codes, hence uses the same octet value for K28.5 and D28.5.  On a native 8b/10b FC link, K28.5 is a crucial character because it distinguishes control words from data words - on the FC PW, this is handled directly by the PW Control Word and the underlying PW framing (PW PDU boundaries).

3) The timeouts come from the FC standards.  I can expand the paragraph that explains them, although the crucial governing requirement, one-way latency must not exceed half of R_T_TOV, is actually explained - the NSP's link initialization protocol times out and does not allow FC traffic if the round trip time exceeds R_T_TOV.


> The NSP function is specified in detail by (s/by/in ?) [FC-BB-6].
> Could we have a fuller overview of the NSP in an (informational) Appendix ?

Could you explain what you expect in a "fuller overview" beyond what's on p.6 of the draft just before that sentence?  I don't have a problem with providing more explanation, but I'd like to understand the goal before I start writing it ;-).

Thanks,
--David

From: Yaakov Stein [mailto:[e-mail]]
Sent: Wednesday, November 24, 2010 9:49 AM
To: [e-mail]
Cc: Bocci, Matthew (Matthew); Linda Dunbar; Black, David
Subject: RE: [PWE3] Working Group Last Call for draft-ietf-pwe3-fc-encap-12.txt

I support, in general.

However, the first paragraph was a shock for me.
Instead of explaining what FC is and why we need to send it over a PW, it starts
  Fibre Channel Storage Area Networks (SAN) extension for disaster recovery
  has (sic.) become an important source of network traffic.

Wow. I don't even know what FC is yet, and I am already recovering from a disaster.

How about something like
  Fibre Channel (FC) is a high-speed communications technology, used mostly for Storage Area Networks (SANs),
  standardized by the T11 Technical committee of ANSI. Due to the importance of traffic carried over FC,
  backup over packet switched networks is required. This document specifies a mechanism for transporting
  FC traffic over MPLS PWs.
and then continue with FC/IP ...   ?

I would also like, as early as possible in the document, for the reliability requirements/features
to be called out.  The explanation of why there are unusual procedures here
(the NSP, K-codes, timing constraints, etc) was not clear enough.

Yes, I saw the mention of reliability in the Abstract, but that was in the context of TP
(which I don't think belongs in the Abstract at all).


The NSP function is specified in detail by (s/by/in ?) [FC-BB-6].
Could we have a fuller overview of the NSP in an (informational) Appendix ?


Y(J)S

From: [e-mail] [mailto:[e-mail]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Monday, November 22, 2010 16:05
To: [e-mail]
Subject: [PWE3] Working Group Last Call for draft-ietf-pwe3-fc-encap-12.txt

This email begins a three week WG Last Call for draft-ietf-pwe3-fc-encap-12.txt.

Please send any comments to the PWE3 mailing list.

This WG LC will end on Monday 13th December 2010.

Best regards,

Matthew & Andy