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

[<[e-mail]>]

Will do - a practical example is that the 8b/10b conversion to octets needs to be covered in order to explain what's going on with K-codes vs. D-codes (they're different sets of 10b codes on native FC links that have the same 8b codes, and the 8b codes are used in PW octets).

Thanks,
--David

From: Alexander Vainshtein [mailto:[e-mail]]
Sent: Saturday, November 27, 2010 12:10 PM
To: Yaakov Stein
Cc: Black, David; [e-mail]
Subject: RE: [PWE3] Working Group Last Call for draft-ietf-pwe3-fc-encap-12.txt

Yaakov,
We don't have a full explanation of ATM in 4717 or of TDM in 4553, and that is fine.
But FC is less known (at least to me), and the NSP more intricate.

I concur - on both counts.

Regards,
     Sasha

From: [e-mail] [mailto:[e-mail]] On Behalf Of Yaakov Stein
Sent: Saturday, November 27, 2010 6:54 PM
To: [e-mail]; [e-mail]
Subject: Re: [PWE3] Working Group Last Call for draft-ietf-pwe3-fc-encap-12.txt

David

Thanks for the response.

What I intended regarding the NSP is something less than
  "everything an implementer needs",
but more than
  "this is what the NSP is for" (which is what I believe you were trying to achieve with the wording you mention).

I understand in general that the NSP
but falls short as I have no idea how " selecting a subset of repetitive FC Primitive Sequences received" is done,
nor do I know what " Alternate Simple Flow Control (ASFC) protocol" is.

I am not trying to be a stickler here.
We don't have a full explanation of ATM in 4717 or of TDM in 4553, and that is fine.
But FC is less known (at least to me), and the NSP more intricate.

Y(J)S

From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, November 24, 2010 17:59
To: Yaakov Stein; [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