Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D5D3A6C41 for ; Tue, 30 Nov 2010 23:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEo4wEYp85TM for ; Tue, 30 Nov 2010 23:14:48 -0800 (PST) Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id 899E63A6D08 for ; Tue, 30 Nov 2010 22:41:43 -0800 (PST) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir1.rad.co.il with ESMTP; 01 Dec 2010 08:42:32 +0200 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 1 Dec 2010 08:41:16 +0200 Received: from EXRAD5.ad.rad.co.il ([fe80::ec3e:feb5:8bef:e3ba]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi; Wed, 1 Dec 2010 08:41:16 +0200 From: Yaakov Stein To: Linda Dunbar , "david.black@emc.com" , "pwe3@ietf.org" Thread-Topic: [PWE3] Working Group Last Call for draft-ietf-pwe3-fc-encap-12.txt Thread-Index: AcuKTkzWoQvkNrnZTSC/iBHtAYXCngBlTpbwAAI9pQAA/tIiwABOFkFQ Date: Wed, 1 Dec 2010 06:41:15 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9186449@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC9183571@EXRAD5.ad.rad.co.il> <7C4DFCE962635144B8FAE8CA11D0BF1E03D5ACEA54@MX14A.corp.emc.com> <01de01cb8fe8$657da9b0$6c0c7c0a@china.huawei.com> In-Reply-To: <01de01cb8fe8$657da9b0$6c0c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC9186449EXRAD5adradcoil_" MIME-Version: 1.0 Subject: Re: [PWE3] Working Group Last Call for draft-ietf-pwe3-fc-encap-12.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 07:14:57 -0000 --_000_07F7D7DED63154409F13298786A2ADC9186449EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 requir= ed for all other PWs. Y(J)S From: Linda Dunbar [mailto:ldunbar@huawei.com] Sent: Monday, November 29, 2010 19:11 To: david.black@emc.com; Yaakov Stein; pwe3@ietf.org Cc: matthew.bocci@alcatel-lucent.com 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 reliabi= lity or the transport portion for FC (i.e. MPLS)? If you are asking for FC reliability, as David has explained, FC-6 has real= ly good explanation. I personally don't think it is a good idea to repeat F= C-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: david.black@emc.com [mailto:david.black@emc.com] Sent: Wednesday, November 24, 2010 9:59 AM To: yaakov_s@rad.com; pwe3@ietf.org Cc: matthew.bocci@alcatel-lucent.com; ldunbar@huawei.com; david.black@emc.c= om 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 reliabil= ity requirements/features > to be called out. The explanation of why there are unusual procedures he= re > (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, includi= ng an FC version of silence suppression (IDLE suppression). There is some = reliability functionality to ensure that the WAN link going down is reflect= ed to the FC fabric and to prevent bringing up a WAN link that has excessiv= e latency. 2) The K and D codes are part of the 8b/10b encoding used by the attached n= ative 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 w= ords - on the FC PW, this is handled directly by the PW Control Word and th= e underlying PW framing (PW PDU boundaries). 3) The timeouts come from the FC standards. I can expand the paragraph tha= t explains them, although the crucial governing requirement, one-way latenc= y must not exceed half of R_T_TOV, is actually explained - the NSP's link i= nitialization 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 pro= viding more explanation, but I'd like to understand the goal before I start= writing it ;-). Thanks, --David From: Yaakov Stein [mailto:yaakov_s@rad.com] Sent: Wednesday, November 24, 2010 9:49 AM To: pwe3@ietf.org 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 s= tarts 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 d= isaster. 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 importanc= e 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 reliabilit= y 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: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Boc= ci, Matthew (Matthew) Sent: Monday, November 22, 2010 16:05 To: pwe3@ietf.org 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 --_000_07F7D7DED63154409F13298786A2ADC9186449EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Linda

 

David's comments on the reliability issue is sufficient for = me

(what I meant was how the FC reliability requirements imping= e on the needed functionality at the PW level).

 

I didn't request repeating anything written in openly availa= ble documents.

However, not being a non-member of T11, I can not download t= he 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 tha= t is not required for all other PWs.

 

Y(J)S

 

From: Linda Dunbar [mailto:ldunbar@huawei.com]
Sent: Monday, November 29, 2010 19:11
To: david.black@emc.com; Yaakov Stein; pwe3@ietf.org
Cc: matthew.bocci@alcatel-lucent.com
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 IE= TF 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 goo= d idea.  

 

Linda

 

From: david.black@emc.com [mailto:david.black@emc.com]
Sent: Wednesday, November 24, 2010 9:59 AM
To: yaakov_s@rad.com; pwe3@ietf.org
Cc: matthew.bocci@alcatel-lucent.com; ldunbar@huawei.com; david.black@emc.com
Subject: RE: [PWE3] Working Group Last Call for draft-ietf-pwe3-fc-encap-12.txt

 

Hi Yaakov,

 

Thanks for taking a look at this dra= ft.

 

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

 

> I would also like, a= s 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.

 <= /p>

Sure, here's a brief summary of thos= e 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 u= p 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 on= e 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 becau= se it distinguishes control words from data words - on the FC PW, this is hand= led 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 th= e 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 an= d does not allow FC traffic if the round trip time exceeds R_T_TOV.

 

> The NSP function is specified in det=
ail by (s/by/in ?) [FC-BB-6].

> Could we have a full= er overview of the NSP in an (informational) Appendix ?

 <= /p>

Could you explain what you expect in= a "fuller overview" beyond what's on p.6 of the draft just before t= hat 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:yaakov_s@rad.com] =
Sent: Wednesday, November 24, 2010 9:49 AM
To: pwe3@ietf.org
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.

 <= /p>

However, the first paragr= aph was a shock for me.

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

  Fibre Channel Storage Area Netwo= rks (SAN) extension for disaster recovery

  has (sic.) be= come an important source of network traffic.<= /o:p>

 <= /p>

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

 <= /p>

How about something like<= o:p>

  Fibre Channel (FC) is a high-spe= ed communications technology, used mostly for Storage Area Networks (SANs),

  standardized by the T11 Technica= l committee of ANSI. Due to the importance of traffic carried over FC,

  backup over packet switched netw= orks is required. This document specifies a mechanism for transporting

  FC traffic over MPLS PWs.     

and then continue with FC= /IP …   ?

 <= /p>

I would also like, as ear= ly as possible in the document, for the reliability requirements/features

to be called out.  T= he explanation of why there are unusual procedures here

(the NSP, K-codes, timing constraints, etc) was not clear enough.

 <= /p>

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

(which I don't think belo= ngs in the Abstract at all).

 <= /p> 

The NSP function is specified in detail b=
y (s/by/in ?) [FC-BB-6].

Could we have a fuller overview of the NSP in an (informational) Appendix ?

 <= /p>

 <= /p>

Y(J)S

 <= /p>

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

 

This email begins a three w= eek 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 Mond= ay 13th December 2010.

 

Best regards,

 

Matthew & Andy

 

--_000_07F7D7DED63154409F13298786A2ADC9186449EXRAD5adradcoil_--