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 98A0528C113 for ; Wed, 24 Nov 2010 07:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 twQLj69ttHGB for ; Wed, 24 Nov 2010 07:59:18 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 2A6E728C137 for ; Wed, 24 Nov 2010 07:59:17 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oAOG02sk015056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Nov 2010 11:00:02 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Wed, 24 Nov 2010 10:59:52 -0500 Received: from corpussmtp5.corp.emc.com (corpussmtp5.corp.emc.com [128.221.166.229]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oAOFxipF026549; Wed, 24 Nov 2010 10:59:44 -0500 Received: from mxhub01.corp.emc.com ([10.254.141.103]) by corpussmtp5.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Nov 2010 10:59:23 -0500 Received: from mx14a.corp.emc.com ([169.254.1.117]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Wed, 24 Nov 2010 10:59:23 -0500 From: To: , Date: Wed, 24 Nov 2010 10:59:21 -0500 Thread-Topic: [PWE3] Working Group Last Call for draft-ietf-pwe3-fc-encap-12.txt Thread-Index: AcuKTkzWoQvkNrnZTSC/iBHtAYXCngBlTpbwAAI9pQA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03D5ACEA54@MX14A.corp.emc.com> References: <07F7D7DED63154409F13298786A2ADC9183571@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC9183571@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C4DFCE962635144B8FAE8CA11D0BF1E03D5ACEA54MX14Acorpemcc_" MIME-Version: 1.0 X-OriginalArrivalTime: 24 Nov 2010 15:59:23.0032 (UTC) FILETIME=[8FBFE180:01CB8BF0] X-EMM-MHVC: 1 X-EMM-MFVC: 1 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, 24 Nov 2010 15:59:25 -0000 --_000_7C4DFCE962635144B8FAE8CA11D0BF1E03D5ACEA54MX14Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_7C4DFCE962635144B8FAE8CA11D0BF1E03D5ACEA54MX14Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Yaakov,

 

Thanks for taking a look at this draft.

 

Your sug= gestions look reasonable - we can put them into a -13 version after the WGL= C is over.

 

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

> to be called out.  The explanat= ion of why there are unusual procedures here

> (the NSP, K-codes, timing constraints, etc) was no= t clear enough.

 = ;

Sure, here's a brief summary of those th= ree:

 

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

&nb= sp;

2) The K and D codes are part of the 8= b/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 an= d D28.5.  On a native 8b/10b FC link, K28.5 is a crucial character bec= ause 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 governi= ng requirement, one-way latency must not exceed half of R_T_TOV, is actuall= y 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].<=
/pre>
> Could we have a fuller overview of th=
e NSP in an (informational) Appendix ?
 
Could you expla=
in 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 nee=
d to send it over a PW, it starts
 =
 Fibre Channel Storage Area Networks (SAN) extension for disaster recovery<=
span style=3D'color:#1F497D'>
  has (sic.) become an important source of network tra=
ffic.
 
Wo=
w. I don't even know what FC is yet, and I am already recovering from a dis=
aster.
 
How about something like
  Fibre Channel (FC) is a high-speed communicati=
ons 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,<=
/p>
  backup over packet switched networks is required. T=
his document specifies a mechanism for transporting
  FC traffic over MPLS PWs.     <=
/o:p>
and then continue with FC/IP &#=
8230;   ?
 
I would also like, as e=
arly as possible in the document, for the reliability requirements/features=
 
to be called out.  =
The explanation of why there are unusual procedures here<=
/p>
(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).
&n=
bsp;
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 ?=

 <=
/p>
 
Y(J)S
&nb=
sp;
From: pwe3-bounces@iet=
f.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Ma=
tthew)
Sent: Monday, November 22, 2010 16:05
To: pwe3@i=
etf.org
Subject: [PWE3] Working Group Last Call for draft-ietf-pw=
e3-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.
 
B=
est regards,
=
 
Matthew & An=
dy
 
=

--_000_7C4DFCE962635144B8FAE8CA11D0BF1E03D5ACEA54MX14Acorpemcc_--