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

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Mon, 22 Nov 2010 15:05:14 +0100

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

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 22 Nov 2010 16:00:34 -0600

Support. 

Linda Dunbar

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bocci, Matthew (Matthew)
Sent: Monday, November 22, 2010 8:05 AM
To: [email-masked]
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.

Best regards,

Matthew & Andy

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 22 Nov 2010 14:44:24 -0800

Hi,

This looks like a good document to me.

Thanks,
Vishwas

On Mon, Nov 22, 2010 at 6:05 AM, Bocci, Matthew (Matthew)
<[email-masked]> wrote:
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>
>

---

From: Yong Lucy <[email-masked]>
Date: Mon, 22 Nov 2010 17:02:21 -0600

Support!

Lucy

  _____  

Best regards,

Matthew & Andy

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 24 Nov 2010 14:49:21 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Monday, November 22, 2010 16:05
To: [email-masked]
Subject: [PWE3] Working Group Last Call for draft-ietf-pwe3-fc-encap-12.txt

Best regards,

Matthew & Andy

---

From: <[email-masked]>
Date: Wed, 24 Nov 2010 10:59:21 -0500

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.

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

> 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:[email-masked]]
Sent: Wednesday, November 24, 2010 9:49 AM
To: [email-masked]
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.

How about something like

Y(J)S

Best regards,

Matthew & Andy

---

From: Yaakov Stein <[email-masked]>
Date: Sat, 27 Nov 2010 16:54:22 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 24, 2010 17:59
To: Yaakov Stein; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] Working Group Last Call for draft-ietf-pwe3-fc-encap-12.txt

Hi Yaakov,

Thanks,
--David

I support, in general.

How about something like

Y(J)S

Best regards,

Matthew & Andy

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 27 Nov 2010 19:09:45 +0200

Yaakov,

I concur - on both counts.

Regards,
     Sasha

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

David

Thanks for the response.

Y(J)S

Hi Yaakov,

Thanks,
--David

I support, in general.

How about something like

Y(J)S

Best regards,

Matthew & Andy

---

From: <[email-masked]>
Date: Mon, 29 Nov 2010 10:43:41 -0500

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:[email-masked]]
Sent: Saturday, November 27, 2010 12:10 PM
To: Yaakov Stein
Cc: Black, David; [email-masked]
Subject: RE: [PWE3] Working Group Last Call for draft-ietf-pwe3-fc-encap-12.txt

Yaakov,

Regards,
     Sasha

David

Thanks for the response.

Y(J)S

Hi Yaakov,

Thanks,
--David

I support, in general.

How about something like

Y(J)S

Best regards,

Matthew & Andy

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 29 Nov 2010 11:10:59 -0600

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: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 24, 2010 9:59 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [PWE3] Working Group Last Call for
draft-ietf-pwe3-fc-encap-12.txt

Hi Yaakov,

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

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.

> 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:[email-masked]] 
Sent: Wednesday, November 24, 2010 9:49 AM
To: [email-masked]
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.

Instead of explaining what FC is and why we need to send it over a PW, it
starts

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

and then continue with FC/IP .   ?

I would also like, as early as possible in the document, for the reliability
requirements/features 

Yes, I saw the mention of reliability in the Abstract, but that was in the
context of TP

 

Y(J)S

Best regards,

Matthew & Andy

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 1 Dec 2010 06:41:15 +0000

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:[email-masked]]
Sent: Monday, November 29, 2010 19:11
To: [email-masked]; Yaakov Stein; [email-masked]
Cc: [email-masked]
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

________________________________

Hi Yaakov,

Thanks,
--David

I support, in general.

How about something like

Y(J)S

Best regards,

Matthew & Andy