From nick.delregno@verizon.com Mon Jan 3 08:38:44 2011 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 AEE793A6985; Mon, 3 Jan 2011 08:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 5ZY8Sb9rSXbU; Mon, 3 Jan 2011 08:38:39 -0800 (PST) Received: from ashesmtp02.verizonbusiness.com (ashesmtp02.verizonbusiness.com [198.4.8.166]) by core3.amsl.com (Postfix) with ESMTP id 6F2903A698A; Mon, 3 Jan 2011 08:38:30 -0800 (PST) Received: from pdcismtp03.vzbi.com ([unknown] [166.40.77.73]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LEG00785GZNKLA0@firewall.verizonbusiness.com>; Mon, 03 Jan 2011 16:40:35 +0000 (GMT) Received: from pdcismtp03.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LEG007E9GZN7I00@pdcismtp03.vzbi.com>; Mon, 03 Jan 2011 16:40:35 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([unknown] [153.39.68.168]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LEG0076RGZM8V00@pdcismtp03.vzbi.com>; Mon, 03 Jan 2011 16:40:35 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 03 Jan 2011 16:40:35 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01CBAB64.F1302B7F" Date: Mon, 03 Jan 2011 16:40:26 +0000 Message-id: <14584D6EE26B314187A4F68BA2060600061FAF51@ASHEVS008.mcilink.com> In-reply-to: <14584D6EE26B314187A4F68BA206060005DB543A@ASHEVS008.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: PW / VCCV User Implementation Survey - Please Participate! Thread-index: Act8YpSEMMoOD4/+SCeRBwpsUYLmAgTfklMQBuDxc0A= References: <14584D6EE26B314187A4F68BA206060005AE91E1@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA206060005DB543A@ASHEVS008.mcilink.com> From: "Delregno, Christopher N (Nick DelRegno)" To: pwe3 , mpls@ietf.org, l2vpn@ietf.org X-OriginalArrivalTime: 03 Jan 2011 16:40:35.0156 (UTC) FILETIME=[F1C61140:01CBAB64] Subject: [PWE3] PW / VCCV User Implementation Survey - Please Participate! 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: Mon, 03 Jan 2011 16:38:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBAB64.F1302B7F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 Just a friendly reminder to complete (or ask your customers to complete) the PW/VCCV User Implementation Survey. =20 =20 We have 6 responses so far. =20 The deadline is February 25, 2011. =20 Thanks, Nick =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Delregno, Christopher N (Nick DelRegno) Sent: Thursday, November 04, 2010 3:55 PM To: pwe3; mpls@ietf.org; l2vpn@ietf.org Cc: Malis, Andrew G. (Andy) Subject: [PWE3] PW / VCCV Service Provider Implementation Survey =20 All: =20 Per the direction of the PWE3 working group, beginning in IETF77 and reinforced in IETF78, the PWE3 working group is conducting a Service Provider implementation survey related to: =20 - Pseudowire Encapsulations - Control Word Support - Control Word Use - VCCV Control Channel Support - VCCV Control Channel Use =20 http://www.surveymonkey.com/s/pwe3 =20 This is a short survey directed toward Service Providers who currently operate networks using any of the defined PWE3 encapsulations. The results of this survey will be used to determine the direction of the Control Word support in current and future encapsulations as well as solutions to VCCV interoperability challenges. =20 We sincerely urge all service providers to participate. We ask that all equipment providers encourage participation by their Service Provider customers. The more feedback we receive, the better view of the existing network we can have on which to base going-forward direction. =20 If you have any questions, regarding the survey, especially of a technical nature, please contact me. If you have non-technical questions, feel free to reach out to the PWE3 WG chairs and myself. =20 The results of the survey will be aggregated and shared at a high level. No low-level details of network implementations will be shared. All participant's responses will remain private, if not anonymous. =20 All responses will require a valid email address to help ensure the survey's validity. =20 Thanks, Nick =20 Christopher N. "Nick" DelRegno, PMTS CNT, Ethernet Network Architecture & Design 400 International Pkwy Richardson, TX 75081 Tel: 972-729-3411 Email: Nick.DelRegno@verizon.com =20 ------_=_NextPart_001_01CBAB64.F1302B7F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

Just a friendly reminder to complete (or ask = your customers to complete) the PW/VCCV User Implementation = Survey. 

 

We have 6 responses = so far.

 

The deadline is February = 25, 2011.

 

Thanks,

Nick

 

From:= = pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = Delregno, Christopher N (Nick DelRegno)
Sent: Thursday, = November 04, 2010 3:55 PM
To: pwe3; mpls@ietf.org; = l2vpn@ietf.org
Cc: Malis, Andrew G. (Andy)
Subject: = [PWE3] PW / VCCV Service Provider Implementation = Survey

 

All:

 

Per the = direction of the PWE3 working group, beginning in IETF77 and reinforced = in IETF78, the PWE3 working group is conducting a Service Provider = implementation survey related to:

 

-          = Pseudowire Encapsulations

-          = Control Word Support

-          = Control Word Use

-          = VCCV Control Channel Support

-          = VCCV Control Channel Use

 

http://www.surveymonkey.com/s= /pwe3

 

This is a short survey directed toward Service = Providers who currently operate networks using any of the defined PWE3 = encapsulations.  The results of this survey will be used to = determine the direction of the Control Word support in current and = future encapsulations as well as solutions to VCCV interoperability = challenges.

 

We sincerely urge all service providers to = participate.  We ask that all equipment providers encourage = participation by their Service Provider customers.  The more = feedback we receive, the better view of the existing network we can have = on which to base going-forward direction.

 

If you have = any questions, regarding the survey, especially of a technical nature, = please contact me.  If you have non-technical questions, feel free = to reach out to the PWE3 WG chairs and myself.

 

The results = of the survey will be aggregated and shared at a high level.  No = low-level details of network implementations will be shared.  All = participant’s responses will remain private, if not = anonymous.

 

All responses will require a valid email address to = help ensure the survey’s validity.

 

Thanks,

Nick

 

Christopher N. “Nick” DelRegno, = PMTS

CNT, Ethernet Network Architecture & = Design

400 International Pkwy

Richardson, TX  = 75081

Tel:  972-729-3411

Email:  = Nick.DelRegno@verizon.com

 

------_=_NextPart_001_01CBAB64.F1302B7F-- From yaakov_s@rad.com Tue Jan 4 08:25:03 2011 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 0D8C53A6CE3; Tue, 4 Jan 2011 08:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, 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 3youokUSrZ4n; Tue, 4 Jan 2011 08:25:01 -0800 (PST) Received: from antivir2.rad.co.il (mx2-q.rad.co.il [80.74.100.144]) by core3.amsl.com (Postfix) with ESMTP id 5EEAD3A6CC0; Tue, 4 Jan 2011 08:24:58 -0800 (PST) Received: from unknown (HELO EXRAD5.ad.rad.co.il) ([192.114.24.28]) by antivir2.rad.co.il with ESMTP; 04 Jan 2011 18:26:50 +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; Tue, 4 Jan 2011 18:26:28 +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 id 14.01.0270.001; Tue, 4 Jan 2011 18:26:28 +0200 From: Yaakov Stein To: "neil.2.harrison@bt.com" Thread-Topic: [PWE3] VCCV usage Thread-Index: AQHLhgiDxE/GLhOI3kefbzvPaVR2G5N1DKwAgAARnICAAAFMAIAAaBKggBL67gCAArdUEIAACG0ggDYHgUA= Date: Tue, 4 Jan 2011 16:26:26 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC919188C@EXRAD5.ad.rad.co.il> References: , <07F7D7DED63154409F13298786A2ADC9179B9C@EXRAD5.ad.rad.co.il> <4CF3C348.4000602@cisco.com> <07F7D7DED63154409F13298786A2ADC9186466@EXRAD5.ad.rad.co.il> <6D3D47CB84BDE349BC23BF1C94E316E440039D57EF@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <6D3D47CB84BDE349BC23BF1C94E316E440039D57EF@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [PWE3] VCCV usage 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: Tue, 04 Jan 2011 16:25:03 -0000 Neil Sorry that it took me some time to get back to reading PWE email ... First, what I questioned was not the CI per se, but the processing required for it. While I wholeheartedly agree with your remark on the value of consistent CI, I don't agree with the requirement that in every case the processing has to be the same. Second, as you mention yourself, very early on in PWE we decided to follow the MPLS tradition of not having self-describing packets. I was very much against this decision (you may recall that my early version of the control word had a type identifier), but once this decision was take= n=20 it obviated any further requirement of consistency. Third, I was not speaking specifically of MPLS-TP. I was speaking of the deployment of PWs over IP using RFC 4023. This has been around for years. Y(J)S -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: Wednesday, December 01, 2010 09:48 To: Yaakov Stein Cc: pwe3@ietf.org; mpls-tp@ietf.org Subject: RE: [PWE3] VCCV usage Hi Yaakov...you may like to ponder on this point (I have raised it several = times before, but for some reason it gets ignored...I wonder why? ;-)) .... Any layer network SHOULD (though this really ought to be MUST) have consist= ent CI (Characteristic Information). There are many reasons for this rathe= r obvious requirement statement, but a key one is that if misconnectivity o= ccurs, then wherever the misdirected DP traffic units and OAM arrive they c= an be correctly processed...this means that all the functional fields of DP= traffic units and DP OAM MUST have unambiguous functional meaning. I thin= k this statement is so obviously true that no sane person could disagree wi= th it. Aside=3D> The above requirement is true for all 3 network modes, but it is = most important in a co-ps mode network (as this has the richest potential s= et of misconnectivity defects) where short-cuts have been taken on child tr= affic unit labelling (ie omit SA label, DA label reduced to link significan= t, omit PID label) due to the a-priori-known single-source property of the = parent connection. However, this a-priori-known single-source property of = a parent connection is broken under misconnectivity defects and cannot, ind= eed MUST NOT, be assumed...ergo why child traffic units and OAM MUST have c= onsistent CI. You are raising one case below where there is non-consistent CI.....but the= re are many more. Even the 'label' (there is only one) in an MPLS traffic = unit is not consistent of its meaning. Then we have lots of choices for OA= M. Now factor-in mixed cases of LSP sublayering and LSP layering...the for= mer LSPs reside in the *same layer network* whilst the latter LSPs reside i= n *different layer networks* (this is a rather more serious self-inflicted = consequential problem BTW). Do you think it is sensible given the above is 'known' (and for some time) = that such mistakes should be carried over into MPLS-TP?....esp given this i= s supposed to be a transparent transport network (hint=3D> this should neve= r have sublayering and esp not PWs as all clients MUST be treated equally..= .else we do not have a transparent transport network). Please excuse me copying this to the MPLS-TP list as my observation is clea= rly germane to that WG too. regards, Neil =20 From Alexander.Vainshtein@ecitele.com Tue Jan 4 22:01:55 2011 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 217853A6B17 for ; Tue, 4 Jan 2011 22:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 o50YTnupWJWp for ; Tue, 4 Jan 2011 22:01:54 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 9644C3A6B39 for ; Tue, 4 Jan 2011 22:01:53 -0800 (PST) X-AuditID: 93eaf2e7-b7c02ae000005550-e2-4d2409d12603 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id AB.B2.21840.1D9042D4; Wed, 5 Jan 2011 08:04:02 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 5 Jan 2011 08:05:37 +0200 From: Alexander Vainshtein To: "Stewart Bryant (stbryant@cisco.com)" , "prayson.pate@overturenetworks.com" Date: Wed, 5 Jan 2011 08:03:24 +0200 Thread-Topic: A question regarding RFC 3985 Thread-Index: AQHLrJ3YZOeBPWhKg0aw7TOf/nFrDpPB40pw Message-ID: References: In-Reply-To: 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_A3C5DF08D38B6049839A6F553B331C76D6B83362FFILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "pwe3@ietf.org" Subject: Re: [PWE3] A question regarding RFC 3985 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, 05 Jan 2011 06:01:55 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D6B83362FFILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Resending to include the PWE3 list ________________________________ From: Alexander Vainshtein Sent: Wednesday, January 05, 2011 8:00 AM To: Stewart Bryant (stbryant@cisco.com); prayson.pate@overturenetworks.com Cc: pwe3@ietf.orgl Subject: A question regarding RFC 3985 Stewart, Prayson and all, I have a question regarding the following statement in RFC 3985: When a MPLS label is used as a PW Demultiplexer, setting of the TTL value [RFC3032] in the PW label is application specific. This statement seems to assume that the tunnel in which the PW crosses the = PSN MUST use either Pipe or Short Pipe TTL processing model, because with Uniform model = the TTL value would change when the PW label is exposed. Is this interpretation correct? Regards, and lots of thanks in advance, Sasha --_000_A3C5DF08D38B6049839A6F553B331C76D6B83362FFILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Resending to include the PWE3 list
 
From: Alexander V= ainshtein
Sent: Wednesday, January 05, 2011 8:00 AM
To: Stewart Bryant (stbryant@cisco.com); prayson.pate@overturenetwor= ks.com
Cc: pwe3@ietf.orgl
Subject: A question regarding RFC 3985

Stewart, Prayson and all,
I have a question regarding= the following statement in RFC 3985:
 
   W=
hen a MPLS label is used as a PW Demultiplexer, setting of the TTL
   value [RFC3032] in the PW label is application specific.
This statement seems to a=
ssume that the tunnel in which the PW crosses the PSN MUST use
either Pipe or Short Pipe=
 TTL processing model, because with Uniform model the TTL value 

would change when the PW =
label is exposed.


 


Is this interpretation co=
rrect?


 


Regards, and lots of than=
ks in advance,


     Sasha


 
--_000_A3C5DF08D38B6049839A6F553B331C76D6B83362FFILPTMAIL02eci_-- From stbryant@cisco.com Wed Jan 5 01:42:59 2011 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 CD43F3A6CD5 for ; Wed, 5 Jan 2011 01:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.535 X-Spam-Level: X-Spam-Status: No, score=-110.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 nvQO8MAeNwW5 for ; Wed, 5 Jan 2011 01:42:58 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 7A2B33A6B72 for ; Wed, 5 Jan 2011 01:42:58 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMFAOLMI01AZnwN/2dsb2JhbACCKZ0ehFxzpiOCTw4BlgWFSwSBYIko X-IronPort-AV: E=Sophos;i="4.60,277,1291593600"; d="scan'208,217";a="200098238" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 05 Jan 2011 09:45:03 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p059j2OM014694; Wed, 5 Jan 2011 09:45:02 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p059j0820912; Wed, 5 Jan 2011 09:45:00 GMT Message-ID: <4D243D9B.8050907@cisco.com> Date: Wed, 05 Jan 2011 09:44:59 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alexander Vainshtein References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050301050104030305020604" Cc: "pwe3@ietf.org" , "prayson.pate@overturenetworks.com" Subject: Re: [PWE3] A question regarding RFC 3985 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 09:42:59 -0000 This is a multi-part message in MIME format. --------------050301050104030305020604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The context at the time the RFC was written was a discussion on whether to set the TTL such that the packet could not wander off in the network if the PSN label got popped incorrectly. However it turned out be be difficult to pick a value that everyone agreed on, hence the text below. You could run the Uniform model if that is what you needed, but then you could not use TTL as an OAM exception mechanism for that PW. Stewart On 05/01/2011 06:03, Alexander Vainshtein wrote: > Resending to include the PWE3 list > ------------------------------------------------------------------------ > *From:* Alexander Vainshtein > *Sent:* Wednesday, January 05, 2011 8:00 AM > *To:* Stewart Bryant (stbryant@cisco.com); > prayson.pate@overturenetworks.com > *Cc:* pwe3@ietf.orgl > *Subject:* A question regarding RFC 3985 > > Stewart, Prayson and all, > I have a question regarding the following statement in RFC 3985: > > When a MPLS label is used as a PW Demultiplexer, setting of the TTL > value [RFC3032] in the PW label is application specific. > > This statement seems to assume that the tunnel in which the PW crosses the PSN MUST use > either Pipe or Short Pipe TTL processing model, because with Uniform model the TTL value > would change when the PW label is exposed. > > Is this interpretation correct? > > Regards, and lots of thanks in advance, > Sasha > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------050301050104030305020604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The context at the time the RFC was written was a discussion on whether to set the TTL such that the packet could not wander off in the network if the PSN label got popped incorrectly. However it turned out be be difficult to pick a value that everyone agreed on, hence the text below.

You could run the Uniform model if that is what you needed, but then you could not use TTL as an OAM exception mechanism for that PW.

Stewart


On 05/01/2011 06:03, Alexander Vainshtein wrote:
Resending to include the PWE3 list
 
From: Alexander Vainshtein
Sent: Wednesday, January 05, 2011 8:00 AM
To: Stewart Bryant (stbryant@cisco.com); prayson.pate@overturenetworks.com
Cc: pwe3@ietf.orgl
Subject: A question regarding RFC 3985

Stewart, Prayson and all,
I have a question regarding the following statement in RFC 3985:
 
   When a MPLS label is used as a PW Demultiplexer, setting of the TTL
   value [RFC3032] in the PW label is application specific.
This statement seems to assume that the tunnel in which the PW crosses the PSN MUST use
either Pipe or Short Pipe TTL processing model, because with Uniform model the TTL value 
would change when the PW label is exposed.
 
Is this interpretation correct?
 
Regards, and lots of thanks in advance,
     Sasha

 



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------050301050104030305020604-- From Alexander.Vainshtein@ecitele.com Wed Jan 5 07:55:47 2011 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 922163A6C77 for ; Wed, 5 Jan 2011 07:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 yUOQp5+VBUus for ; Wed, 5 Jan 2011 07:55:46 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 5E1493A6AF4 for ; Wed, 5 Jan 2011 07:55:45 -0800 (PST) X-AuditID: 93eaf2e7-b7c02ae000005550-32-4d2494ff2071 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 2C.68.21840.FF4942D4; Wed, 5 Jan 2011 17:57:51 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 5 Jan 2011 17:57:44 +0200 From: Alexander Vainshtein To: "stbryant@cisco.com" Date: Wed, 5 Jan 2011 17:59:22 +0200 Thread-Topic: A question regarding RFC 3985 Thread-Index: AcusvUDwLKkG62zwRliKfZM99yxZmgAM6+6A Message-ID: References: <4D243D9B.8050907@cisco.com> In-Reply-To: <4D243D9B.8050907@cisco.com> 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_A3C5DF08D38B6049839A6F553B331C76D6B86B2712ILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "pwe3@ietf.org" , "prayson.pate@overturenetworks.com" Subject: Re: [PWE3] A question regarding RFC 3985 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, 05 Jan 2011 15:55:47 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D6B86B2712ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart, Lots of thanks for a prompt response. It matches my recollection from the e= arly PWE3 days long ago, namely that at that time we did not think about t= his detail of PWE3 architecture vs. MPLS one. This is probably not the only such missing detail, but, somehow, PWs work q= uite well today:). Regards, Sasha From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Wednesday, January 05, 2011 11:45 AM To: Alexander Vainshtein Cc: prayson.pate@overturenetworks.com; pwe3@ietf.org Subject: Re: A question regarding RFC 3985 The context at the time the RFC was written was a discussion on whether to = set the TTL such that the packet could not wander off in the network if the= PSN label got popped incorrectly. However it turned out be be difficult to= pick a value that everyone agreed on, hence the text below. You could run the Uniform model if that is what you needed, but then you co= uld not use TTL as an OAM exception mechanism for that PW. Stewart On 05/01/2011 06:03, Alexander Vainshtein wrote: Resending to include the PWE3 list ________________________________ From: Alexander Vainshtein Sent: Wednesday, January 05, 2011 8:00 AM To: Stewart Bryant (stbryant@cisco.com); prayson= .pate@overturenetworks.com Cc: pwe3@ietf.orgl Subject: A question regarding RFC 3985 Stewart, Prayson and all, I have a question regarding the following statement in RFC 3985: When a MPLS label is used as a PW Demultiplexer, setting of the TTL value [RFC3032] in the PW label is application specific. This statement seems to assume that the tunnel in which the PW crosses the = PSN MUST use either Pipe or Short Pipe TTL processing model, because with Uniform model = the TTL value would change when the PW label is exposed. Is this interpretation correct? Regards, and lots of thanks in advance, Sasha -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_A3C5DF08D38B6049839A6F553B331C76D6B86B2712ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Stewart,

Lots of th= anks for a prompt response. It matches my recollection from the early PWE3 = days long  ago, namely that at that time we did not think about this &= nbsp;detail of PWE3 architecture vs. MPLS one.

 

This is probably not the only such missing detail, but, somehow, PWs wor= k quite well todayJ.

 

Rega= rds,

   &nb= sp; Sasha

 = ;

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent:= Wednesday, January 05, 2011 11:45 AM
To: Alexander VainshteinCc: prayson.pate@overturenetworks.com; pwe3@ietf.org
Subject:= Re: A question regarding RFC 3985

 

The context at = the time the RFC was written was a discussion on whether to set the TTL suc= h that the packet could not wander off in the network if the PSN label got = popped incorrectly. However it turned out be be difficult to pick a value t= hat everyone agreed on, hence the text below.

You could run the Unif= orm model if that is what you needed, but then you could not use TTL as an = OAM exception mechanism for that PW.

Stewart


On 05/01/201= 1 06:03, Alexander Vainshtein wrote:

Resending to include the PWE3 list

 

From: Alexander Vainshtein
Sent: Wednesday, January 05, 201= 1 8:00 AM
To: Stewart Bryant (stbryant@cisco.com); prayson.pate@overturenetworks.com
Cc: pwe3@ietf.orgl
Subject: A question regarding= RFC 3985

St= ewart, Prayson and all,

= I have a question regarding the following statement in RFC 3985:=

 

   When a MPLS label is used as a PW =
Demultiplexer, setting of the TTL
   value [RFC3032] in the PW label is application specif=
ic.
This s=
tatement seems to assume that the tunnel in which the PW crosses the PSN MU=
ST use
either Pipe or =
Short Pipe TTL processing model, because with Uniform model the TTL value <=
/span>
would change when the =
PW label is exposed.
 =

Is this interpretation correct?
 
Regards, and lots of thanks in advance,
     Sasha=

 




-- 
For corporate=
 legal information go to:
 
=
http://www.cisco.com/web/about/doing_business/legal/cri/index.html<=
o:p>
 
= --_000_A3C5DF08D38B6049839A6F553B331C76D6B86B2712ILPTMAIL02eci_-- From Internet-Drafts@ietf.org Thu Jan 6 14:15:03 2011 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 20DF93A6D1A; Thu, 6 Jan 2011 14:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, 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 UIyvRngcf5aS; Thu, 6 Jan 2011 14:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DE23A6F48; Thu, 6 Jan 2011 14:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110106221502.30422.26974.idtracker@localhost> Date: Thu, 06 Jan 2011 14:15:02 -0800 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-fc-encap-13.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: Thu, 06 Jan 2011 22:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks Author(s) : D. Black, L. Dunbar Filename : draft-ietf-pwe3-fc-encap-13.txt Pages : 19 Date : 2011-1-6 A Fibre Channel pseudowire (PW) is used to carry Fibre Channel traffic over an MPLS network. This enables service providers to take advantage of the reliable transport of MPLS-TE/MPLS-TP to offer "emulated" Fibre Channel services. This document specifies the encapsulation of Fibre Channel traffic within a pseudowire. It also specifies the common procedures for using a PW to provide a Fibre Channel service. The mechanisms controlling the reliable transport of Fibre Channel PW over MPLS networks can be provided by MPLS-TP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fc-encap-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pwe3-fc-encap-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-1-6141040.I-D@ietf.org> --NextPart-- From lberger@labn.net Fri Jan 7 12:44:34 2011 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 715953A6945 for ; Fri, 7 Jan 2011 12:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.095 X-Spam-Level: X-Spam-Status: No, score=-102.095 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 RKz-oikUSXQj for ; Fri, 7 Jan 2011 12:44:33 -0800 (PST) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 3C7273A6920 for ; Fri, 7 Jan 2011 12:44:33 -0800 (PST) Received: (qmail 18795 invoked by uid 0); 7 Jan 2011 20:46:38 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 7 Jan 2011 20:46:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Hrg/O6JttTp3K9CBd2lq1by0X2HbLQYTQ9iSuGEXkNfU5sBtw3W9uRtJmJRVkaHg6YZFi4zinEIXesHs/kuGON/cotbNmH+INEzLvZnGttL3rxG3D12zrv4BixLXbBQr; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PbJCo-0008LS-Ji; Fri, 07 Jan 2011 13:46:38 -0700 Message-ID: <4D277BB9.80708@labn.net> Date: Fri, 07 Jan 2011 15:46:49 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} X-Mailman-Approved-At: Sun, 09 Jan 2011 09:36:43 -0800 Cc: PWE3 Subject: [PWE3] Fwd: New Version Notification for draft-ietf-ccamp-mpls-tp-cp-framework-05 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: Fri, 07 Jan 2011 20:44:34 -0000 FYI -- This update has been made to address issues raised by the (other) CCAMP WG chair as part of the normal post WG Last Call process. The changes fix a couple of nits, and add some clarifications on when GMPLS protocols are used and when PW protocols are used. Lou (as document co-editor) -------- Original Message -------- Subject: New Version Notification for draft-ietf-ccamp-mpls-tp-cp-framework-05 Date: Fri, 7 Jan 2011 12:35:54 -0800 (PST) From: IETF I-D Submission Tool To: lberger@labn.net CC: loa.andersson@ericsson.com,lufang@cisco.com,nabil.n.bitar@verizon.com,Eric.Gray@Ericsson.com,attila.takacs@ericsson.com,martin.vigoureux@alcatel-lucent.fr,elisa.bellagamba@ericsson.com A new version of I-D, draft-ietf-ccamp-mpls-tp-cp-framework-05.txt has been successfully submitted by Lou Berger and posted to the IETF repository. Filename: draft-ietf-ccamp-mpls-tp-cp-framework Revision: 05 Title: MPLS-TP Control Plane Framework Creation_date: 2011-01-07 WG ID: ccamp Number_of_pages: 54 Abstract: The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS), and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP LSPs. MPLS-TP also uses the Pseudowire (PW) control plane for Pseudowires (PWs). Management plane functions are out of scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF consensus.] The IETF Secretariat. From iesg-secretary@ietf.org Mon Jan 10 06:32:29 2011 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 B18A428C198; Mon, 10 Jan 2011 06:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, 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 sLBpZf5irndK; Mon, 10 Jan 2011 06:32:28 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCD33A6975; Mon, 10 Jan 2011 06:32:28 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110110143228.15009.38132.idtracker@localhost> Date: Mon, 10 Jan 2011 06:32:28 -0800 Cc: pwe3@ietf.org Subject: [PWE3] Last Call: (Pseudowire (PW) OAM Message Mapping) to Proposed Standard 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: Mon, 10 Jan 2011 14:32:29 -0000 The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Pseudowire (PW) OAM Message Mapping' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-01-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-oam-msg-map/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-oam-msg-map/ This is a second IETF Last call. The purpose of this second last call is to draw the attention of the IETF to the IPR disclosures. There are two disclosures: #863 (https://datatracker.ietf.org/ipr/863/) and #1311 https://datatracker.ietf.org/ipr/1311/ IPR disclosure #1311 states that this particular disclosure "has been removed at the submitter's request." IPR disclosure #863 is still active. The following IPR Declarations may be related to this I-D: /ipr/863/ /ipr/1311/ From matthew.bocci@alcatel-lucent.com Mon Jan 10 07:54:38 2011 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 6AFAE3A6973 for ; Mon, 10 Jan 2011 07:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.892 X-Spam-Level: X-Spam-Status: No, score=-105.892 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 UieWERwIxuPU for ; Mon, 10 Jan 2011 07:54:37 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 61F7B3A67ED for ; Mon, 10 Jan 2011 07:54:37 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0AFumaI012099 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 10 Jan 2011 16:56:48 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 10 Jan 2011 16:56:48 +0100 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" , Stewart Bryant , "Andrew. Malis" Date: Mon, 10 Jan 2011 16:56:46 +0100 Thread-Topic: [PWE3] WG poll on draft-bryant-pwe3-packet-pw-04.txt Thread-Index: Acuw3vyjHjsDITmPRBS0smKm+Uo4Mw== Message-ID: In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A004D43DB5@S4DE9JSAANI.ost.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [PWE3] WG poll on draft-bryant-pwe3-packet-pw-04.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: Mon, 10 Jan 2011 15:54:38 -0000 Authors, Please upload a new revision of this draft as a PWE3 WG draft. Please do not make any other changes to this version. Best regards Matthew On 27/10/2010 14:22, "Manuel.Paul@telekom.de" wrote: >Support. > > >Best regards, >Manuel=20 > > >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >> Bocci, Matthew (Matthew) >> Sent: Thursday, October 21, 2010 6:10 PM >> To: pwe3@ietf.org >> Subject: [PWE3] WG poll on draft-bryant-pwe3-packet-pw-04.txt >>=20 >> The authors of draft-bryant-pwe3-packet-pw-04.txt have asked that this >> draft be made a PWE3 working group draft. >>=20 >> This email starts a two week poll, closing Friday 5th November, to help >> judge consensus on this. >>=20 >> I would ask that the working group participants take into consideration >> the fact that this draft is intended as a BCP. It is not intended to >> define new protocol. If this document becomes a WG draft, it does not >> preclude other solutions to this problem that require protocol >>extensions >> to be adopted in the future, but the WG will need to be convinced that >> they should be adopted. >>=20 >> Regards >>=20 >> Matthew >>=20 >>=20 >>=20 >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 From matthew.bocci@alcatel-lucent.com Tue Jan 11 03:05:57 2011 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 E55AF28C275 for ; Tue, 11 Jan 2011 03:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.91 X-Spam-Level: X-Spam-Status: No, score=-105.91 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 AvXLuzxUFtUC for ; Tue, 11 Jan 2011 03:05:56 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 463E928C26E for ; Tue, 11 Jan 2011 03:05:55 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0BB6rHF017940 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 11 Jan 2011 12:08:11 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 11 Jan 2011 12:08:01 +0100 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Tue, 11 Jan 2011 12:07:56 +0100 Thread-Topic: Revised Milestones Thread-Index: Acuxf89PQ2SeKRtgSf6J+BSlqhdjzQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C951EA8C6D9Cmatthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [PWE3] Revised Milestones 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: Tue, 11 Jan 2011 11:05:58 -0000 --_000_C951EA8C6D9Cmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, It is time that we revised our milestones. Please find below a proposed upd= ated set of milestones. Please let me know if you have any comments by Frid= ay 21st January. Best regards, Matthew Done - PWE3 WG started, organize editing teams. Done - Hold interim meeting, including discussion of priority of serv= ice-specific documents and considerpruning some deliverables Done - Accept drafts of service-specific documents as WG items Done - PW Requirements Document Last Call Done - TDM Circuit Documents Last Call Done - ATM Documents Last Call Done - Ethernet Documents Last Call Done - Fragmentation LC Done - TDM Requirements LC Done - SONET Documents Last Call Done - TDM Documents Last Call Done - Frame Relay Documents Last Call Done - FCS retention Last Call Done - Multi-Segment PW Requirements LC Done - VCCV LC Done - PWE3 Services MIBs LC Done - PPP/HDLC PW LC Done - Wildcard FEC LC Done - TDM Signaling LC Done- Multi-Segment Architecture LC Done - Basic Pseudowire MIBs LC Done - PW OAM Mapping LC Done - Multi-Segment PW LC Done - PW Protection and Restoration Requirements LC Done - PW Protection and Restoration Architecture Done - Generic Associated Channel Header LC Done - PW Protection and Restoration LC Done - Fiber Channel Encap LC Done - Multipath PW LC March 2011 - Packet PW Requirements / solution March 2011 - P2MP Requirements LC March 2011 =96 PW Status signalling in static/MPLS-TP March 2011 - Enhanced PW OAM March 2011 =96 Signaling extensions for MPLS-TP OAM July 2011 - Dynamic MS PW LC July 2011 - Multisegment PW MIB July 2011 - Security Considerations LC July 2011 =96 Congestion Considerations July 2011 - P2MP PW Signaling (rootinitiated) Sept 2011 =96 P2MP PW Signaling (leaf initiated) --_000_C951EA8C6D9Cmatthewboccialcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
All,

It is = time that we revised our milestones. Please find below a proposed updated s= et of milestones. Please let me know if you have any comments by Friday 21s= t January.

Best regards,

= Matthew

Done     - PWE3 WG started, organize editing teams.

  Done     - Hold interim meeting, including discussion of priority of service-specific documents and consider= pruning some deliverables

  Done     - Accept drafts of service-specific documents as WG items

  Done     - PW Requirements Document Last Call

  Done     - TDM Circuit Documents Last Call

  Done     - ATM Documents Last Call

  Done     - Ethernet Documents Last Call

  Done     - Fragmentation LC

  Done     - TDM Requirements LC

  Done     - SONET Documents Last Call

  Done     - TDM Documents Last Call

  Done     - Frame Relay Documents Last Call

  Done     - FCS retention Last Call

  Done     - Multi-Segment PW Requirements LC

  Done   &nbs= p; - VCCV LC

  Done     - PWE3 Services MIBs LC

  Done     - PPP/HDLC PW LC

  Done     - Wildcard FEC LC

  Done     - TDM Signaling LC

  Done- Multi-Se= gment Architecture LC

  Done     - Basic Pseudowire MIBs LC

  Done - PW OAM Mapping LC

  Done - Multi-Segment PW LC

 Done - PW Protection and Restoration Requirements LC

  Done - PW Protection and Restoration Architecture

  Done - Generic Associated Channel Header LC

 Done - PW Protection and Restoration LC

 Done - Fiber Channel Encap LC

 Done - Multipath PW LC

 March 2011 - Packet PW Requirements / solution

  March 2011 - P2MP Requirements LC

 March 2011 =96 PW Status signalling in static/MPLS-TP

 March 2011 - Enhanced PW OAM

 March 2011 =96 Signaling extensions for MPLS-TP OAM

 July 2011 - Dynamic MS PW LC

 July 2011 - Multisegment PW MIB

 July 2011 - Security Considerations LC

 July 2011 =96 Congestion Considerations

July 2011 - P2MP PW Signaling (= rootinitiated)

Sept 2011 =96 P2MP PW Signaling= (leaf initiated)

--_000_C951EA8C6D9Cmatthewboccialcatellucentcom_-- From Internet-Drafts@ietf.org Tue Jan 11 07:30:08 2011 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 2F7333A6A40; Tue, 11 Jan 2011 07:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, 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 bdKs9ZNqfCNQ; Tue, 11 Jan 2011 07:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B50C3A6A3D; Tue, 11 Jan 2011 07:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111153002.10361.14028.idtracker@localhost> Date: Tue, 11 Jan 2011 07:30:02 -0800 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-packet-pw-00.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: Tue, 11 Jan 2011 15:30:09 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Packet Pseudowire Encapsulation over an MPLS PSN Author(s) : S. Bryant, et al. Filename : draft-ietf-pwe3-packet-pw-00.txt Pages : 14 Date : 2011-01-11 This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN is the case where the client LSR and the server PE are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-packet-pw-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pwe3-packet-pw-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-11072923.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Tue Jan 11 15:30:04 2011 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 CC3813A67D9; Tue, 11 Jan 2011 15:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, 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 vKcMdptTccaQ; Tue, 11 Jan 2011 15:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A26A3A657C; Tue, 11 Jan 2011 15:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111233002.14551.4164.idtracker@localhost> Date: Tue, 11 Jan 2011 15:30:02 -0800 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-fc-encap-14.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: Tue, 11 Jan 2011 23:30:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks Author(s) : D. Black, L. Dunbar Filename : draft-ietf-pwe3-fc-encap-14.txt Pages : 19 Date : 2011-1-11 A Fibre Channel pseudowire (PW) is used to carry Fibre Channel traffic over an MPLS network. This enables service providers to take advantage of the reliable transport of MPLS-TE/MPLS-TP to offer "emulated" Fibre Channel services. This document specifies the encapsulation of Fibre Channel traffic within a pseudowire. It also specifies the common procedures for using a PW to provide a Fibre Channel service. The mechanisms controlling the reliable transport of Fibre Channel PW over MPLS networks can be provided by MPLS-TP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fc-encap-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pwe3-fc-encap-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-1-11152216.I-D@ietf.org> --NextPart-- From lizhong.jin@zte.com.cn Tue Jan 11 17:14:15 2011 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 6C6E93A6819 for ; Tue, 11 Jan 2011 17:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 nxyc7woAp1qS for ; Tue, 11 Jan 2011 17:14:14 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id EAC103A680B for ; Tue, 11 Jan 2011 17:14:13 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205951397396305; Wed, 12 Jan 2011 09:12:15 +0800 (CST) Received: from [10.32.0.74] by [192.168.168.16] with StormMail ESMTP id 25080.8954942861; Wed, 12 Jan 2011 09:09:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse3.zte.com.cn with ESMTP id p0C1GIcM048156; Wed, 12 Jan 2011 09:16:19 +0800 (CST) (envelope-from lizhong.jin@zte.com.cn) To: pwe3@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Wed, 12 Jan 2011 09:15:56 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-01-12 09:16:11, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-01-12 09:16:11, Serialize complete at 2011-01-12 09:16:11, S/MIME Sign failed at 2011-01-12 09:16:11: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-01-12 09:16:13, Serialize complete at 2011-01-12 09:16:13 Content-Type: multipart/alternative; boundary="=_alternative 0006F9C248257816_=" X-MAIL: mse3.zte.com.cn p0C1GIcM048156 Cc: "raymond.key@hotmail.com" , Vishwas Manral , Thomas Nadeau Subject: [PWE3] draft-jin-pwe3-cbit-negotiation-02 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, 12 Jan 2011 01:14:15 -0000 This is a multipart message in MIME format. --=_alternative 0006F9C248257816_= Content-Type: text/plain; charset="US-ASCII" Hi all, As we introduced in draft-jin-pwe3-cbit-negotiation-02, label request message is used to do control word update. During the discussion of this draft, we got known that there were already some label request message implementations, althought there is no published standard to define the behavior of label request message for PW. In this draft, it is described that: if label withdraw is successfully processed before receiving label request (means PE has removed the remote information), PE should respond with label mapping with locally configured Cbit value. Authors would like to solicit more comments about this procedure. If anyone think such behavior is not reasonable or conflicts with existing implementations, please comment. Thanks Authors of the draft -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0006F9C248257816_= Content-Type: text/html; charset="US-ASCII"
Hi all,
As we introduced in draft-jin-pwe3-cbit-negotiation-02, label request message is used to do control word update. During the discussion of this draft, we got known that there were already some label request message implementations, althought there is no published standard to define the behavior of label request message for PW.
In this draft, it is described that: if label withdraw is successfully processed before receiving label request (means PE has removed the remote information), PE should respond with label mapping with locally configured Cbit value.
Authors would like to solicit more comments about this procedure. If anyone think such behavior is not reasonable or conflicts with existing implementations, please comment.

Thanks
Authors of the draft
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0006F9C248257816_=-- From Alexander.Vainshtein@ecitele.com Wed Jan 12 07:53:43 2011 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 E14533A69ED for ; Wed, 12 Jan 2011 07:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] 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 wKcC4lOlSvu7 for ; Wed, 12 Jan 2011 07:53:42 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id C169A3A681D for ; Wed, 12 Jan 2011 07:53:41 -0800 (PST) X-AuditID: 93eaf2e7-b7bbbae000003faf-00-4d2dcf123c0d Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 9F.49.16303.21FCD2D4; Wed, 12 Jan 2011 17:56:02 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 12 Jan 2011 17:55:59 +0200 From: Alexander Vainshtein To: "Luca Martini (lmartini)" , "Bocci, Matthew (Matthew)" , "swallow@cisco.com" , "giheron@cisco.com" Date: Wed, 12 Jan 2011 17:57:31 +0200 Thread-Topic: Usage of ACH TLV header in draft-ietf-pwe3-static-pw-status-01 Thread-Index: AcuycWu+nLJskZLnSF2hRm+aMw8w6A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {B7A32424-680A-42FB-9B9C-89F35B216302} x-cr-hashedpuzzle: AghT C/Zy GV6i HZBu H/Tm IcKJ LQun M1FE TY0x WIjM ZQeK eGFX l60E xcL4 yvfF zhYu; 5; ZwBpAGgAZQByAG8AbgBAAGMAaQBzAGMAbwAuAGMAbwBtADsAbABtAGEAcgB0AGkAbgBpAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBtAGEAdAB0AGgAZQB3AC4AYgBvAGMAYwBpAEAAYQBsAGMAYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0AOwBwAHcAZQAzAEAAaQBlAHQAZgAuAG8AcgBnADsAcwB3AGEAbABsAG8AdwBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Sosha1_v1; 7; {B7A32424-680A-42FB-9B9C-89F35B216302}; YQBsAGUAeABhAG4AZABlAHIALgB2AGEAaQBuAHMAaAB0AGUAaQBuAEAAZQBjAGkAdABlAGwAZQAuAGMAbwBtAA==; Wed, 12 Jan 2011 15:57:31 GMT; VQBzAGEAZwBlACAAbwBmACAAQQBDAEgAIABUAEwAVgAgAGgAZQBhAGQAZQByACAAaQBuACAAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AcAB3AGUAMwAtAHMAdABhAHQAaQBjAC0AcAB3AC0AcwB0AGEAdAB1AHMALQAwADEA acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: Andrew Sergeev , Sunil Malali , "pwe3@ietf.org" , Robert Rennison , Rotem Cohen Subject: [PWE3] Usage of ACH TLV header in draft-ietf-pwe3-static-pw-status-01 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, 12 Jan 2011 15:53:44 -0000 Luca, Matthew, George, Giles and all, I would highly appreciate a clarification regarding the following point in = the static PW status draft. The draft shows format of the static status PW message as following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | 0xZZ PW OAM Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh Timer | TLV Length |A| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The draft defines a new ACH type - PW OAM Message - and suggests a value of= 0x0022 for this type=20 (in its IANA Considerations section). The draft further explains that ACH TLV header is defined in RFC 5586, and= that it must be set to 0 since there are no ACH TLVs in this message. However, looking up RFC 5586, I've found the following text dealing with th= e ACH TLVs vs. ACH Type: If the G-ACh message MAY be preceded by one or more ACH TLVs, then this MUST be explicitly specified in the definition of an ACH Channel Type. If the ACH Channel Type definition does state that one or more ACH TLVs MAY precede the G-ACh message, an ACH TLV Header MUST follow the ACH. If no ACH TLVs are required in a specific associated channel packet, but the Channel Type nevertheless defines that ACH TLVs MAY be used, an ACH TLV Header MUST be present but with a length field set to zero to indicate that no ACH TLV follow this header. If an ACH Channel Type specification does not explicitly specify that ACH TLVs MAY be used, then the ACH TLV Header MUST NOT be used. Hence my question: Why is the ACH TLV header present in the static PW statu= s message? To the best of my understanding, the draft, in its present form, does not *= explicitly* specify that ACH TLVs=20 MAY be used with the new ACH Type defined for these messages: If anything, = its text suggests that they are not used. Hence the last para of the quoted text from RFC 5586 seems to apply, i.e., = the ACH TLV Header MUST NOT be used. Alternatively, if ACH TLVs MAY be used (in future) with the new ACH Type, t= his MUST at least be explicitly specified in the draft. (Personally I think that some explanation regarding= potential usage of ACH TLVs would be helpful, but this is not mandatory.) Regards, and lots of thanks in advance, Sasha From david.black@emc.com Wed Jan 12 23:48:06 2011 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 265C83A69C8 for ; Wed, 12 Jan 2011 23:48:06 -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.000, BAYES_00=-2.599, 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 svR-lwSlnCdH for ; Wed, 12 Jan 2011 23:48:04 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 4941A3A6998 for ; Wed, 12 Jan 2011 23:48:03 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0D7oOKo004475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Jan 2011 02:50:24 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Thu, 13 Jan 2011 02:50:19 -0500 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0D7kfGQ020547 for ; Thu, 13 Jan 2011 02:46:42 -0500 Received: from mx14a.corp.emc.com ([169.254.1.169]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Thu, 13 Jan 2011 02:46:42 -0500 From: To: Date: Thu, 13 Jan 2011 02:46:40 -0500 Thread-Topic: fc-encap draft, -14 version Thread-Index: Acuy9gOJmGDCGHxXQQ6nXauq2lCWZA== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03D75EF64F@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [PWE3] fc-encap draft, -14 version 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: Thu, 13 Jan 2011 07:48:06 -0000 The -14 version of draft-ietf-pwe3-fc-encap-14 contains changes that respon= d to the last call comments that the draft authors are aware of - we've che= cked with Yaakov Stein, and believe he's satisfied with the changes that ha= ve been made (actually, -13 contained most of the changes -- we had to quic= kly put together a -14 to include thanks to everyone who helped). I would ask the pwe3 WG chairs to please send this draft onward to the ADs = and request its publication as a Proposed Standard RFC. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From matthew.bocci@alcatel-lucent.com Mon Jan 17 09:14:27 2011 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 B98E928C169; Mon, 17 Jan 2011 09:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.311 X-Spam-Level: X-Spam-Status: No, score=-103.311 tagged_above=-999 required=5 tests=[AWL=-2.326, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, 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 UUAi14MtzHIo; Mon, 17 Jan 2011 09:14:26 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id C61E928C173; Mon, 17 Jan 2011 09:14:25 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0HHGafC030026 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 17 Jan 2011 18:16:37 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 17 Jan 2011 18:16:36 +0100 From: "Bocci, Matthew (Matthew)" To: Stewart Bryant Date: Mon, 17 Jan 2011 18:16:31 +0100 Thread-Topic: Request to publish draft-ietf-pwe3-fc-encap-14.txt Thread-Index: Acu2aks/ZNeojdZxT46qRAIsdXErZw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C95A29EE7713matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: The IESG , "pwe3@ietf.org" Subject: [PWE3] Request to publish draft-ietf-pwe3-fc-encap-14.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: Mon, 17 Jan 2011 17:14:27 -0000 --_000_C95A29EE7713matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-pwe3-fc-encap-14.txt Document Shepard Write-Up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Matthew Bocci (matthew.bocci@alcatel-lucent.com) Yes, I have reviewed the document and I believe it is ready for forwading to the IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, the document has received adequate review. The document received a number of comments during WG last call and been widely reviewed and discussed in the working group over a long period of time. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No specific concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG aprticipants. It has been devloped over a long period in the WG. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document passes ID nits. This document is not subject to MIB doctor or other reviews. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the references are split appropriately. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists, is consistent with the rest o= f the document, and with the style of the IANA registries that it requests allocations from. There are several requests for allocations from the= MPLS PW Type registry and for PW Interface Parameters. It does not request = any new registries or new processes for allocations from registries. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no sections that use a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary A Fibre Channel pseudowire (PW) is used to carry Fibre Channel traffic over an MPLS network. This enables service providers to take advantage of the reliable transport of MPLS-TE/MPLS-TP to offer "emulated" Fibre Channel services. This document specifies the encapsulation of Fibre Channel traffic within a pseudowire. It also specifies the common procedures for using a PW to provide a Fibre Channel service. This document is a product of the PWE3 working group. This document is STANDARDS TRACK. Working Group Summary This draft originated as draft-roth-pwe3-fc-encap-01 in 2005, which contained a basic specification for the transport of FC over MPLS using PWs. Subsequently, there was significant debate about the congestion control and QoS implications of FC, which requires a reliable underlying transport. The document was reviewed by the transport area resulting in the development of a TCP-friendly congestion control protocol. However, this protocol was felt to add significant complexity, and was removed from the draft and instead the applicability of FC PWs limited to controlled MPLS / MPLS-TP networks. Document Quality There are no concerns about protocol quality. Personnel Who is the Document Shepherd for this document? Matthew Bocci (matthew.bocci@alcatel-lucent.com) Who is the Responsible Area Director? Stewart Bryant --_000_C95A29EE7713matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
draft-ietf-pwe3-fc-= encap-14.txt

Document Shepard Write-Up
<= br>

    (1.a) Who is the Document S= hepherd for this document? Has the 
     &nbs= p;    Document Shepherd personally reviewed this version of the&n= bsp;
          document and, in par= ticular, does he or she believe this 
     &n= bsp;    version is ready for forwarding to the IESG for publicati= on? 

Matthew Bocci (matthew.bocci@alcatel-lucent.com)
        Yes, I have reviewed the document= and I believe it is ready for =0B        
&n= bsp;        forwading to the IESG.

=

    (1.b) Has the document had adequate = review both from key WG members 
       =    and from key non-WG members? Does the Document Shepherd have&n= bsp;
          any concerns about t= he depth or breadth of the reviews that 
    =      have been performed? 

&n= bsp;       Yes, the document has received adequate revi= ew. The document =0B        
   &nb= sp;    received a number of comments during WG last call and been= widely
        reviewed and discussed i= n the working group over a long period of
     &nb= sp;  time.
        

<= /div>

    (1.c) Does the Document Shepher= d have concerns that the document 
      = ;    needs more review from a particular or broader perspective,&= nbsp;
          e.g., security, ope= rational complexity, someone familiar with 
   &nb= sp;      AAA, internationalization or XML? 
<= br>
       No.


<= /div>
    (1.d) Does the Document Shepherd have any spec= ific concerns or 
          is= sues with this document that the Responsible Area Director 
=           and/or the IESG should be aware of?= For example, perhaps he 
         =  or she is uncomfortable with certain parts of the document, or <= /div>
          has concerns whether ther= e really is a need for it. In any 
      = ;    event, if the WG has discussed those issues and has indicate= d 
          that it still wis= hes to advance the document, detail those 
   &nbs= p;      concerns here. Has an IPR disclosure related to this= document 
          been file= d? If so, please include a reference to the 
   &n= bsp;      disclosure and summarize the WG discussion and con= clusion on 
          this iss= ue. 

       No specific c= oncerns. 


    (= 1.e) How solid is the WG consensus behind this document? Does it 
          represent the strong concurre= nce of a few individuals, with 
       &= nbsp;  others being silent, or does the WG as a whole understand and&n= bsp;
          agree with it? =

      I am comfortable that t= he document represents WG consensus and has=0B      
     been reviewed by a reasonable number of active WG ap= rticipants. It 
      has been devloped = over a long period in the WG. 

   &= nbsp;(1.f) Has anyone threatened an appeal or otherwise indicated extreme&n= bsp;
          discontent? If so, p= lease summarise the areas of conflict in 
    = ;      separate email messages to the Responsible Area Direc= tor. (It 
          should be = in a separate email because this questionnaire is 
 &nb= sp;        entered into the ID Tracker.) 

       None indicated.

<= /div>

    (1.g) Has the Document Shepherd= personally verified that the 
       &n= bsp;  document satisfies all ID nits? (See 
  = ;        http://www.ietf.org/ID-Checklist.html and = ;
          http://tools.ietf.org/t= ools/idnits/). Boilerplate checks are 
     &= nbsp;    not enough; this check needs to be thorough. Has the doc= ument 
          met all forma= l review criteria it needs to, such as the MIB 
  =        Doctor, media type and URI type reviews? <= /div>


       The docu= ment passes ID nits.
       This document is = not subject to MIB doctor or other reviews. 

=     (1.h) Has the document split its references into normati= ve and 
          informative?= Are there normative references to documents that 
 &nb= sp;        are not ready for advancement or are otherwi= se in an unclear 
          st= ate? If such normative references exist, what is the 
 =          strategy for their completion? Are there = normative references 
         &nbs= p;that are downward references, as described in [RFC3967]? If 
          so, list these downward referenc= es to support the Area 
         &n= bsp;Director in the Last Call procedure for them [RFC3967]. 

      Yes, the references are split app= ropriately. 

      
=

    (1.i) Has the Document Shepherd veri= fied that the document IANA 
       &nbs= p;  consideration section exists and is consistent with the body =
          of the document? If the = document specifies protocol 
       &nbs= p;  extensions, are reservations requested in appropriate IANA 
          registries? Are the IANA r= egistries clearly identified? If 
      =    the document creates a new registry, does it define the =
          proposed initial content= s of the registry and an allocation 
     &nb= sp;    procedure for future registrations? Does it suggest a = ;
          reasonable name for the= new registry? See [RFC5226]. If the 
     &n= bsp;    document describes an Expert Review process has Shepherd&= nbsp;
          conferred with the = Responsible Area Director so that the IESG 
   &nb= sp;      can appoint the needed Expert during the IESG Evalu= ation? 

      The IANA co= nsiderations section exists, is consistent with the rest of the 
=
      document, and with the style of the IANA reg= istries that it requests
      allocations fr= om. There are several requests for allocations from the MPLS 
     PW Type registry and for PW Interface Parameters. It = does not request any 
     new registries or = new processes for allocations from registries.

    (1.j) Has the Document Shepherd verified tha= t sections of the 
          d= ocument that are written in a formal language, such as XML 
=           code, BNF rules, MIB definitions, e= tc., validate correctly in 
        = ;  an automated checker? 

   &= nbsp;  There are no sections that use a formal language.

    (1.k) The IESG approval annou= ncement includes a Document 
       &nbs= p;  Announcement Write-Up. Please provide such a Document 
<= div>          Announcement Write-Up? Recent e= xamples can be found in the
         &nb= sp;"Action" announcements for approved documents. The approval 
<= div>          announcement contains the follo= wing sections: 

Technical Summary
<= br>
   A Fibre Channel pseudowire (PW) is used to carry= Fibre Channel
   traffic over an MPLS network. This en= ables service providers to take
   advantage of the rel= iable transport of MPLS-TE/MPLS-TP to offer
   "emulate= d" Fibre Channel services. This document specifies the
 &nbs= p; encapsulation of Fibre Channel traffic within a pseudowire. It also
   specifies the common procedures for using a PW to provid= e a Fibre
   Channel service. 

   This document is a product of the PWE3 working group.

   This document is STANDARDS TRACK.
=

Working Group Summary
   This draft= originated as draft-roth-pwe3-fc-encap-01 in 2005, which 
&= nbsp;  contained a basic specification for the transport of FC over MP= LS
   using PWs. Subsequently, there was significant de= bate about the
   congestion control and QoS implicatio= ns of FC, which requires a 
   reliable underlying= transport. The document was reviewed by the 
   t= ransport area resulting in the development of a TCP-friendly
&nbs= p;  congestion control protocol. However, this protocol was felt to&nb= sp;
   add significant complexity, and was removed from= the draft and instead
   the applicability of FC PWs l= imited to controlled MPLS / MPLS-TP
   networks.
<= div> 

Document Quality
There are no= concerns about protocol quality. 


=
Personnel
  Who is the Document Shepherd for this = document?

 Matthew Bocci (matthew.bocci@alcat= el-lucent.com)

Who is the Responsible Area Directo= r?
 Stewart Bryant --_000_C95A29EE7713matthewboccialcatellucentcom_-- From Internet-Drafts@ietf.org Tue Jan 18 10:00:07 2011 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 318CC3A705A; Tue, 18 Jan 2011 10:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 ZOzHmo-c-3eP; Tue, 18 Jan 2011 10:00:05 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086F83A7057; Tue, 18 Jan 2011 10:00:03 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110118180003.8071.57292.idtracker@localhost> Date: Tue, 18 Jan 2011 10:00:03 -0800 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-cep-mib-14.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: Tue, 18 Jan 2011 18:00:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base (MIB) Using SMIv2 Author(s) : D. Zelig, R. Cohen, T. Nadeau Filename : draft-ietf-pwe3-cep-mib-14.txt Pages : 65 Date : 2011-1-18 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling SONET/SDH circuits over a Packet Switch Network (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cep-mib-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pwe3-cep-mib-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-1-18095641.I-D@ietf.org> --NextPart-- From wwwrun@rfc-editor.org Tue Jan 18 12:30:13 2011 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 0941228C1A5; Tue, 18 Jan 2011 12:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.984 X-Spam-Level: X-Spam-Status: No, score=-101.984 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-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 ChP45bSKwZuW; Tue, 18 Jan 2011 12:30:10 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 1B2FE28C190; Tue, 18 Jan 2011 12:30:06 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 61547E0738; Tue, 18 Jan 2011 12:32:44 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110118203244.61547E0738@rfc-editor.org> Date: Tue, 18 Jan 2011 12:32:44 -0800 (PST) Cc: pwe3@ietf.org, rfc-editor@rfc-editor.org Subject: [PWE3] RFC 6073 on Segmented Pseudowire 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: Tue, 18 Jan 2011 20:30:13 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6073 Title: Segmented Pseudowire Author: L. Martini, C. Metz, T. Nadeau, M. Bocci, M. Aissaoui Status: Standards Track Stream: IETF Date: January 2011 Mailbox: lmartini@cisco.com, chmetz@cisco.com, tnadeau@lucidvision.com, matthew.bocci@alcatel-lucent.co.uk, mustapha.aissaoui@alcatel-lucent.com Pages: 43 Characters: 102428 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pwe3-segmented-pw-18.txt URL: http://www.rfc-editor.org/rfc/rfc6073.txt This document describes how to connect pseudowires (PWs) between different Packet Switched Network (PSN) domains or between two or more distinct PW control plane domains, where a control plane domain uses a common control plane protocol or instance of that protocol for a given PW. The different PW control plane domains may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload. [STANDARDS-TRACK] This document is a product of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From matthew.bocci@alcatel-lucent.com Wed Jan 19 01:27:20 2011 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 5952B3A7028; Wed, 19 Jan 2011 01:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=-2.220, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, 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 ejFxc0d5ZkIp; Wed, 19 Jan 2011 01:27:18 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 2A5EA3A6F03; Wed, 19 Jan 2011 01:27:17 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0J9Ta7q027248 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Jan 2011 10:29:51 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 19 Jan 2011 10:29:35 +0100 From: "Bocci, Matthew (Matthew)" To: Adrian Farrel , The IESG Date: Wed, 19 Jan 2011 10:29:31 +0100 Thread-Topic: Request to publish draft-ietf-pwe3-fat-pw-05.txt Thread-Index: Acu3u2KqaFMbaUarSOSCQS8amPlWYQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C95C5F7B7914matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "pwe3@ietf.org" Subject: [PWE3] Request to publish draft-ietf-pwe3-fat-pw-05.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, 19 Jan 2011 09:27:20 -0000 --_000_C95C5F7B7914matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-pwe3-fat-pw-05.txt Document Shepard Write-Up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Matthew Bocci (matthew.bocci@alcatel-lucent.com) Yes, I have reviewed the document and I believe it is ready for for= warding to the IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, the document has received adequate review. The document has been developed of a lengthy period of time with regular discussion within the working group. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No specific concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I am comfortable that the document represents WG consensus and has = been reviewed by a reasonable number of active WG participants. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the references are split appropriately. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists and seems reasonable. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no sections that use a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Where identifiable flows it can in some circumstances be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to hash based on label stacks and use this to balance flows over ECMPs. This draft describes a method of identifying the flows, or flow groups, to the label switched routers by including an additional label in the label stack. This document is a product of the PWE3 working group. This document is STANDARDS TRACK. Working Group Summary Network transport service providers and their users are seeking to rationalize their networks by migrating their existing services and platforms onto IP or MPLS enabled IP packet switched networks (PSN). This migration requires communications services that can emulate the essential properties of traditional communications links over a PSN. Some service providers wish to use MPLS technology to replace existing transport network infrastructure, relying upon pseudowire technology is an integral component of these network convergence architectures. Pseudowire Emulation Edge to Edge (PWE3) will specify the encapsulation, transport, control, management, interworking and security of services emulated over IETF-specified PSNs. Document Quality There are no concerns with document quality. Personnel Who is the Document Shepherd for this document? Matthew Bocci (matthew.bocci@alcatel-lucent.com) Who is the Responsible Area Director? Adrian Farrel --_000_C95C5F7B7914matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
draft-ietf-pwe3-fat= -pw-05.txt

Document Shepard Write-Up

    (1.a) Who is the Document She= pherd for this document? Has the 
      =    Document Shepherd personally reviewed this version of the&nbs= p;
          document and, in parti= cular, does he or she believe this 
     &nbs= p;    version is ready for forwarding to the IESG for publication= ? 

Matthew Bocci (matthew.bocci@alcatel-lucent.com)
        Yes, I have reviewed the document a= nd I believe it is ready for =0Bforwarding to the IESG.


    (1.b) Has the document had adequate= review both from key WG members 
      =    and from key non-WG members? Does the Document Shepherd have&= nbsp;
          any concerns about = the depth or breadth of the reviews that 
    = ;      have been performed? 

&= nbsp;       Yes, the document has received adequate rev= iew. The document has
        been devel= oped of a lengthy period of time with regular discussion
 &n= bsp;      within the working group.
   &= nbsp;    


   &n= bsp;(1.c) Does the Document Shepherd have concerns that the document <= /div>
          needs more review from a = particular or broader perspective, 
     &nbs= p;    e.g., security, operational complexity, someone familiar wi= th 
          AAA, internation= alization or XML? 

      = No.


    (1.d) Does = the Document Shepherd have any specific concerns or 
 &= nbsp;        issues with this document that the Respons= ible Area Director 
          = and/or the IESG should be aware of? For example, perhaps he 
          or she is uncomfortable with certa= in parts of the document, or 
       &nb= sp;  has concerns whether there really is a need for it. In any <= /div>
          event, if the WG has disc= ussed those issues and has indicated 
     &n= bsp;    that it still wishes to advance the document, detail thos= e 
          concerns here. Ha= s an IPR disclosure related to this document 
   &= nbsp;      been filed? If so, please include a reference to = the 
          disclosure and = summarize the WG discussion and conclusion on 
   =        this issue. 

 = ;      No specific concerns. 

=
    (1.e) How solid is the WG consensus behin= d this document? Does it 
         =  represent the strong concurrence of a few individuals, with 
          others being silent, or does= the WG as a whole understand and 
      = ;    agree with it? 

   &= nbsp;  I am comfortable that the document represents WG consensus and = has=0B      been reviewed by a reasonable number of active W= G participants.
 

   &nbs= p;(1.f) Has anyone threatened an appeal or otherwise indicated extreme = ;
          discontent? If so, plea= se summarise the areas of conflict in 
     &= nbsp;    separate email messages to the Responsible Area Director= . (It 
          should be in = a separate email because this questionnaire is 
  =        entered into the ID Tracker.) 
<= br>
       None indicated.


    (1.g) Has the Document Shepherd pe= rsonally verified that the 
        = ;  document satisfies all ID nits? (See 
   &= nbsp;      http://www.ietf.org/ID-Checklist.html and 
          http://tools.ietf.org/tool= s/idnits/). Boilerplate checks are 
     &nbs= p;    not enough; this check needs to be thorough. Has the docume= nt 
          met all formal r= eview criteria it needs to, such as the MIB 
   &n= bsp;      Doctor, media type and URI type reviews? 


       Yes

    (1.h) Has the document split its refer= ences into normative and 
         =  informative? Are there normative references to documents that 
          are not ready for advancem= ent or are otherwise in an unclear 
     &nbs= p;    state? If such normative references exist, what is the = ;
          strategy for their comp= letion? Are there normative references 
     =      that are downward references, as described in [RFC3967]= ? If 
          so, list these= downward references to support the Area 
    = ;      Director in the Last Call procedure for them [RFC3967= ]. 

      Yes, the refere= nces are split appropriately. 



    (1.i) Has the Document Shepherd verified= that the document IANA 
         &= nbsp;consideration section exists and is consistent with the body 
          of the document? If the docu= ment specifies protocol 
         &= nbsp;extensions, are reservations requested in appropriate IANA 
=
          registries? Are the IANA regis= tries clearly identified? If 
       &nb= sp;  the document creates a new registry, does it define the 
          proposed initial contents of= the registry and an allocation 
       =    procedure for future registrations? Does it suggest a 
          reasonable name for the new= registry? See [RFC5226]. If the 
      =    document describes an Expert Review process has Shepherd = ;
          conferred with the Resp= onsible Area Director so that the IESG 
     =      can appoint the needed Expert during the IESG Evaluatio= n? 

      The IANA consid= erations section exists and seems reasonable.


=
    (1.j) Has the Document Shepherd verified that= sections of the 
          do= cument that are written in a formal language, such as XML 
&= nbsp;         code, BNF rules, MIB definitions, et= c., validate correctly in 
        =  an automated checker? 

   &n= bsp;  There are no sections that use a formal language.

=

    (1.k) The IESG approval announ= cement includes a Document 
        = ;  Announcement Write-Up. Please provide such a Document 
          Announcement Write-Up? Recent ex= amples can be found in the
         &nbs= p;"Action" announcements for approved documents. The approval 
          announcement contains the follow= ing sections: 

Technical Summary
   Where identifiable flows it can in some circumsta= nces be desirable 
   to carry those flows over th= e equal cost multiple paths (ECMPs) that
   exist in th= e packet switched network. Most forwarding engines are able
 = ;  to hash based on label stacks and use this to balance flows over EC= MPs.
   This draft describes a method of identifying th= e flows, or flow groups,
   to the label switched route= rs by including an additional label in the 
   lab= el stack.

   This document is a product = of the PWE3 working group.

   This docum= ent is STANDARDS TRACK.

Working Group Summary

   Network transport service providers and t= heir users are
   seeking to rationalize their networks= by migrating their
   existing services and platforms = onto IP or MPLS enabled
   IP packet switched networks = (PSN). This migration requires
   communications servic= es that can emulate the essential
   properties of trad= itional communications links over a PSN.
   Some servic= e providers wish to use MPLS technology to
   replace e= xisting transport network infrastructure, relying
   up= on pseudowire technology is an integral component of
  = these network convergence architectures.

 &n= bsp; Pseudowire Emulation Edge to Edge (PWE3) will specify the
&n= bsp;  encapsulation, transport, control, management, interworking
   and security of services emulated over IETF-specified PS= Ns.

Document Quality

&nbs= p;  There are no concerns with document quality.

<= div>
Personnel
  Who is the Document Shepherd for t= his document?

 Matthew Bocci (matthew.bocci@alcatel-lucent.com)<= /div>

Who is the Responsible Area Director?
&n= bsp;Adrian Farrel

--_000_C95C5F7B7914matthewboccialcatellucentcom_-- From Adrian.Farrel@huawei.com Wed Jan 19 06:01:45 2011 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 0E9E93A6F30; Wed, 19 Jan 2011 06:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.541 X-Spam-Level: X-Spam-Status: No, score=-105.541 tagged_above=-999 required=5 tests=[AWL=1.058, BAYES_00=-2.599, 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 odtP5p87BPYr; Wed, 19 Jan 2011 06:01:43 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id C2B843A712B; Wed, 19 Jan 2011 06:01:43 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF900547WFBZN@usaga03-in.huawei.com>; Wed, 19 Jan 2011 08:04:23 -0600 (CST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF900JX1WF9G9@usaga03-in.huawei.com>; Wed, 19 Jan 2011 08:04:23 -0600 (CST) Date: Wed, 19 Jan 2011 14:04:20 +0000 From: Adrian Farrel To: mpls@ietf.org, 'CCAMP' , pce@ietf.org Message-id: <070501cbb7e1$c6436020$52ca2060$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: Acu34bm7+lB0frMlTquX736g5RjMjQ== Cc: l2vpn@ietf.org, itu-t-liaisons@iab.org, rtg-bfd@ietf.org, pwe3@ietf.org, opsawg@ietf.org Subject: [PWE3] Proposed liaison response on ITU-T Optical transport Network Work Plan X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 14:01:45 -0000 Hi, We received a liaison "SG15 OTNT standardization work plan" which you can see at https://datatracker.ietf.org/documents/LIAISON/file1054.pdf The document they would like us to review is "Draft Revised Optical Transport Networks & Technologies Standardization Work Plan, Issue 13" visible at https://datatracker.ietf.org/documents/LIAISON/file1055.pdf The liaison is addressed CCAMP, PCE, and MPLS, but it falls to me as liaison on the Optical Control Plane to respond. I am copying this email to BFD, OPSAWG, PWE3, and L2VPN as those WGs are explicitly mentioned in the document. A response is requested by February 1, 2011. Here is a draft of what I plan to send. Please send me any comments by January 28. Thanks, Adrian === The IETF thanks you for your liaison COM15-LS204-E received on 2010-06-24 titled "SG15 OTNT standardization work plan", and thanks you for sharing your plans. We have reviewed the document and have a number of comments. In general, it is becoming less and less clear that the title of this document is accurate! SG15 now embraces a number of non-optical transport technologies including Ethernet and MPLS-TP. Although those packet-based technologies can be transmitted over optical links, they are not limited to that medium. Maybe your document should be titled "Transport Networks & Technologies Standardization Work Plan" or maybe you should remove the non-optical material. The scope text in Section 5 and 5.1 might also need revision. The IETF has not position of this, but simply draws the matter to your attention. Table 5-1 We would like to suggest the inclusion of the MPLS Working Group in this table as that working group is responsible for many elements of the support of Ethernet "carrier-class" pseudowires over MPLS and MPLS-TP networks. Section 5.6.1 begins: "MPLS OAM was originally standardized by ITU-T SG13 (Q.5/13)." Although the section goes on to list IETF standardization of MPLS OAM, it may be considered that this first sentence implies that the ITU-T developed MPLS OAM before any MPLS OAM had been developed within the IETF. This would, of course, be a misrepresentation. Therefore, we suggest that you change this first sentence to read: "Within the ITU-T, MPLS OAM was originally standardized by SG13 (Q.5/13)." Table 5-3 Architectural Aspects of MPLS-TP Add RFC 5921, RFC 5950, RFC 5960 Equipment Functional Characteristics of MPLS-TP Add RFC 5960 OAM and Protection Switching of MPLS-TP Add RFC 5860 Management Aspects of MPLS Add RFC 4221 Management Aspects of MPLS-TP Add RFC 5950, RFC 5951 Performance of ATM Add RFC 3116 Performance of MPLS Add RFC 5695 Table 7-1-2 draft-ietf-mpls-tp-framework is now RFC 5921 draft-ietf-mpls-tp-nm-req is now RFC 5951 draft-ietf-mpls-tp-survive-fwk reached revision -06 and has been approved for publication as an RFC draft-ietf-mpls-tp-oam-framework reached revision -10 and has been approved for publication as an RFC draft-ietf-mpls-tp-nm-framework is now RFC 5950 draft-ietf-mpls-tp-rosetta-stone has reached revision -03 draft-ietf-mpls-tp-data-plane is now RFC 5960 draft-ietf-mpls-tp-identifiers has reached revision -03 draft-ietf-mpls-tp-ach-tlv is now abandoned draft-ietf-ccamp-mpls-tp-cp-framework has reached revision -05 Further relevant Internet-Drafts and RFCs can be found at: http://datatracker.ietf.org/wg/ccamp/ http://datatracker.ietf.org/wg/mpls http://datatracker.ietf.org/wg/pwe3 http://datatracker.ietf.org/wg/bfd http://datatracker.ietf.org/wg/pce Table 7-4-2 draft-ietf-gmpls-ason-routing-ospf is now RFC 5787 Table 7-8 should inherit changes to Table 7-1-2 and be updated according to the document status available at the IETF working group pages as listed above. Table 8-1 entry 3. Please be aware of the work on impairment-aware routing in the CCAMP and PCE working groups. (It may be your intention that this is covered under entry 5.) Annex A might usefully refer readers to RFC 4397 and draft-ietf-mpls-tp-rosetta-stone that provide terminology mapping and have been jointly developed by IETF and ITU-T experts. We would welcome it if you shared any future revisions of this work plan with us. Adrian Farrel IETF Liaison to the IETF on the Optical Control Plane Routing Area Director From javi@trajano.us.es Fri Jan 28 17:10:30 2011 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 0AF0E3A69A3 for ; Fri, 28 Jan 2011 17:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dib4kEoptgvN for ; Fri, 28 Jan 2011 17:10:29 -0800 (PST) Received: from mail.us.es (mail.us.es [193.147.175.20]) by core3.amsl.com (Postfix) with ESMTP id A0CC93A6998 for ; Fri, 28 Jan 2011 17:10:28 -0800 (PST) Received: (qmail 26488 invoked from network); 29 Jan 2011 02:13:33 +0100 Received: from unknown (HELO us.es) (192.168.2.11) by us.es with SMTP; 29 Jan 2011 02:13:33 +0100 Received: (qmail 16019 invoked by uid 507); 29 Jan 2011 01:13:32 -0000 Received: from 127.0.0.1 by antivirus1 (envelope-from , uid 501) with qmail-scanner-2.08 (clamdscan: 0.96.5/12583. Clear:RC:1(127.0.0.1):. Processed in 0.031697 secs); 29 Jan 2011 01:13:32 -0000 Received: from unknown (HELO antivirus1) (127.0.0.1) by us.es with SMTP; 29 Jan 2011 01:13:32 -0000 Received: from 192.168.1.13 (192.168.1.13) by antivirus1 (F-Secure/fsigk_smtp/403/antivirus1); Sat, 29 Jan 2011 02:13:32 +0100 (CET) X-Virus-Status: clean(F-Secure/fsigk_smtp/403/antivirus1) Received: (qmail 3953 invoked from network); 29 Jan 2011 02:13:32 +0100 Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 29 Jan 2011 02:13:32 +0100 Received: from [192.168.1.40] (10.Red-81-33-38.dynamicIP.rima-tde.net [81.33.38.10]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p0T1DVOo007706; Sat, 29 Jan 2011 02:13:32 +0100 Message-ID: <4D4369B5.9010102@trajano.us.es> Date: Sat, 29 Jan 2011 02:13:25 +0100 From: Javi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [PWE3] TDMPW and MeGaCo/SDP 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: Sat, 29 Jan 2011 01:10:30 -0000 Assuming the next situation: ISDN Terminal 1 - MG1 - [IP network] - MG2 - ISDN Terminal 2 where the MGs (Media Gateway) are controlled by a MGC (Media Gateway Controller) via MeGaCo[H.248.1]. [ITU-T Y.2262 / Annex IV] proposses that MGs may transport ISDN B-channels over the IP network: + By a single RTP session (when monochannels ISDN services) + Or by TDMoIP (= UDP TDMPWs), when multichannels ISDN services. How may MGC indicate to the MG that it uses PWs at the IP termination? It may be done by MeGaCo, using SDP[RFC4566] at Local/Remote descriptors. However, how may be that SDP description of TDMPWs? Thanks, Javier Muñoz From stbryant@cisco.com Sat Jan 29 01:28:03 2011 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 B01073A6959 for ; Sat, 29 Jan 2011 01:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.56 X-Spam-Level: X-Spam-Status: No, score=-110.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 3LtlDRarMCzl for ; Sat, 29 Jan 2011 01:28:02 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9799D3A6933 for ; Sat, 29 Jan 2011 01:28:02 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACJtQ01AZnwM/2dsb2JhbAClBHOfToJXDgGYSIVOBIwh Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Jan 2011 09:31:10 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0T9VA86025959; Sat, 29 Jan 2011 09:31:10 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p0T9V8818624; Sat, 29 Jan 2011 09:31:09 GMT Message-ID: <4D43DE5C.4090008@cisco.com> Date: Sat, 29 Jan 2011 09:31:08 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Javi References: <4D4369B5.9010102@trajano.us.es> In-Reply-To: <4D4369B5.9010102@trajano.us.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pwe3@ietf.org Subject: Re: [PWE3] TDMPW and MeGaCo/SDP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 09:28:03 -0000 That is outside the scope of the PW. The NSP (specifically excluded from the domain of the PW) would need to handle that. Stewart On 29/01/2011 01:13, Javi wrote: > Assuming the next situation: > > ISDN Terminal 1 - MG1 - [IP network] - MG2 - ISDN Terminal 2 > > where the MGs (Media Gateway) are controlled by a MGC (Media Gateway > Controller) via MeGaCo[H.248.1]. > > [ITU-T Y.2262 / Annex IV] proposses that MGs may transport ISDN > B-channels over the IP network: > > + By a single RTP session (when monochannels ISDN services) > > + Or by TDMoIP (= UDP TDMPWs), when multichannels ISDN services. > > > How may MGC indicate to the MG that it uses PWs at the IP termination? > > It may be done by MeGaCo, using SDP[RFC4566] at Local/Remote > descriptors. However, how may be that SDP description of TDMPWs? > > Thanks, > > Javier Muñoz > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From javi@trajano.us.es Sat Jan 29 04:06:51 2011 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 0D2CE3A679C for ; Sat, 29 Jan 2011 04:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 aBNan+BNScib for ; Sat, 29 Jan 2011 04:06:50 -0800 (PST) Received: from mail.us.es (mail.us.es [193.147.175.20]) by core3.amsl.com (Postfix) with ESMTP id 8255F3A6778 for ; Sat, 29 Jan 2011 04:06:49 -0800 (PST) Received: (qmail 10117 invoked from network); 29 Jan 2011 13:09:54 +0100 Received: from unknown (HELO us.es) (192.168.2.12) by us.es with SMTP; 29 Jan 2011 13:09:54 +0100 Received: (qmail 8712 invoked by uid 507); 29 Jan 2011 12:09:53 -0000 Received: from 127.0.0.1 by antivirus2 (envelope-from , uid 501) with qmail-scanner-2.08 (clamdscan: 0.96.5/12584. Clear:RC:1(127.0.0.1):. Processed in 0.038308 secs); 29 Jan 2011 12:09:53 -0000 Received: from unknown (HELO antivirus2) (127.0.0.1) by us.es with SMTP; 29 Jan 2011 12:09:53 -0000 Received: from 192.168.1.13 (192.168.1.13) by antivirus2 (F-Secure/fsigk_smtp/403/antivirus2); Sat, 29 Jan 2011 13:09:53 +0100 (CET) X-Virus-Status: clean(F-Secure/fsigk_smtp/403/antivirus2) Received: (qmail 29261 invoked from network); 29 Jan 2011 13:09:53 +0100 Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 29 Jan 2011 13:09:53 +0100 Received: from [192.168.1.40] (10.Red-81-33-38.dynamicIP.rima-tde.net [81.33.38.10]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p0TC9qlf015740; Sat, 29 Jan 2011 13:09:52 +0100 Message-ID: <4D440389.9040405@trajano.us.es> Date: Sat, 29 Jan 2011 13:09:45 +0100 From: Javi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pwe3@ietf.org References: <4D4369B5.9010102@trajano.us.es> <4D43DE5C.4090008@cisco.com> In-Reply-To: <4D43DE5C.4090008@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PWE3] TDMPW and MeGaCo/SDP 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: Sat, 29 Jan 2011 12:06:51 -0000 Possible, but it is necessary to define it. No working group, as mmusic, plans to define it in collaboration with PWE3? Normally, each transport proposal includes SDP extensions it needs. For instance: + IETF RFC4733 (RTP Payload for tones): codecs "telephone-event" (a=rtpmap:100 telephone-event/8000) and "tone" (a=rtpmap:101 tone/8000) + IETF RFC4734 (Events for Modem signals): codes (a=fmtp:101 0-15,32-41,43,46,48-49,52-68) + ITU-T V.152 (VBDoIP): clausule 7.1 (attribute "a=gpmd") + ITU-T T.38: Annex D and E (protocol "udptl" and "tcptl") + ITU-T V.150.1: Annex E (attribute and codec "a=sprtmap: v150mr/8000") + ITU-T V.151: Annex C (codec T.140: "a=rtpmap: t140c/8000") ... So, I think it would be logical that the SDP extensions needed to describe PWs weredone by a PW document. Thanks Javier Muñoz El 29/01/2011 10:31, Stewart Bryant escribió: > That is outside the scope of the PW. > > The NSP (specifically excluded from the domain of the PW) would need > to handle that. > > Stewart > > On 29/01/2011 01:13, Javi wrote: >> Assuming the next situation: >> >> ISDN Terminal 1 - MG1 - [IP network] - MG2 - ISDN Terminal 2 >> >> where the MGs (Media Gateway) are controlled by a MGC (Media Gateway >> Controller) via MeGaCo[H.248.1]. >> >> [ITU-T Y.2262 / Annex IV] proposses that MGs may transport ISDN >> B-channels over the IP network: >> >> + By a single RTP session (when monochannels ISDN services) >> >> + Or by TDMoIP (= UDP TDMPWs), when multichannels ISDN services. >> >> >> How may MGC indicate to the MG that it uses PWs at the IP termination? >> >> It may be done by MeGaCo, using SDP[RFC4566] at Local/Remote >> descriptors. However, how may be that SDP description of TDMPWs? >> >> Thanks, >> >> Javier Muñoz >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> > > From Adrian.Farrel@huawei.com Sat Jan 29 05:00:27 2011 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 BB8143A67B4 for ; Sat, 29 Jan 2011 05:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.53 X-Spam-Level: X-Spam-Status: No, score=-105.53 tagged_above=-999 required=5 tests=[AWL=1.069, BAYES_00=-2.599, 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 54hmZ0VPCpxR for ; Sat, 29 Jan 2011 05:00:25 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 710913A6767 for ; Sat, 29 Jan 2011 05:00:25 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFS00JP0C9XSE@usaga03-in.huawei.com> for pwe3@ietf.org; Sat, 29 Jan 2011 07:03:34 -0600 (CST) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFS00962C9VGB@usaga03-in.huawei.com> for pwe3@ietf.org; Sat, 29 Jan 2011 07:03:33 -0600 (CST) Date: Sat, 29 Jan 2011 13:03:32 +0000 From: Adrian Farrel To: draft-ietf-pwe3-fat-pw@tools.ietf.org Message-id: <031001cbbfb4$ef961500$cec23f00$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: Acu/tLfusOVHNsPoR2ax8avxMdX4ZQ== Cc: pwe3@ietf.org Subject: [PWE3] AD review of draft-ietf-pwe3-fat-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 13:00:27 -0000 Hi, I have performed an AD review of your draft. Don't panic! I review all drafts that I am responsible for before putting them forward for IETF last call. The main objective is to catch nits and minor issues that would show up during the last call or in IESG review. The intention is to help polish your document and make sure it is clean and shiny so that other reviewers will stick to the technical details. I am responsible for this I-D because Stewart Bryant is a co-author and therefore cannot take responsibility for the document. Your document describes a very small piece of function, and so there is very little of technical substance to discuss. As such, I was a bit surprised at the length and weight of this draft and I feel that it could usefully be heavily pruned. However, I doubt that there is energy or enthusiasm for that work, so I think you will just want to limit yourself to addressing my issues below. Most of my comments are pretty trivial: they are concerned with clarity and consistency of your text. But there are quite a lot of them, so I'd like to see a quick respin of the document before I issue the IETF last call. As soon as I see a new revision posted, I'll set the ball in motion. Of course, all of my issues are up for discussion. Thanks for the work, Adrian --- I found the use of language a little relaxed. You use the same word, "label", to refer to a label value and to an entry in the shim header. It would probably be helpful to use the term "label" to refer to the label itself, and "label entry" to indicate the label, TC bits, and TTL. --- It seems to me that the description of what can be in the additional label entry is conflicted. On receipt of the pseudowire packet at the egress PE (which knows this additional label is present) the flow label is discarded without processing. This means that the label will not be used for any purpose in the packet processing except in the DPI of ECMP hashing. The flow label can never become the top label in normal operation That is, you will never pop a label to discover the flow label except at the egress where it is expected and ignored. Note that the flow label MUST NOT be an MPLS reserved label (values in the range 0..15) [RFC3032], but is otherwise unconstrained by the protocol. And why is that restriction required given the two previous points? The flow label can never become the top label in normal operation, and hence the TTL in the flow label is never used to determine whether the packet should be discarded due to TTL expiry. Therefore there are no lower restrictions on the TTL value. Why do you call out "lower"? How about saying "there are no restrictions" The use of the TC bits (formerly known as the EXP bits) in the flow label is outside the scope of this document. Unless otherwise agreed by the ingress and egress PEs these bits MUST be set to zero by the ingress PE and MUST be ignored by the egress PE. "Out of scope" seems to be different from the subsequent statement about how he TC field must be treated. I am also not clear why the TTL discussion is different from the TC discussion. --- Document title: please spell out PSN --- Abstract: yuck! :-O Suggestion... OLD Where the payload carried over a pseudowire carries a number of identifiable flows it can in some circumstances be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to hash based on label stacks and use this to balance flows over ECMPs. This draft describes a method of identifying the flows, or flow groups, to the label switched routers by including an additional label in the label stack. NEW Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to hash based on MPLS label stacks and use this mechanism to balance MPLS flows over ECMPs. This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. END --- Try to avoid "ECMP paths" (or ECMPP as we call them ;-) --- Section 1 para 1 the use of ECMP paths for is known to be beneficial (and not harmful) to the operation of the PW. ?? --- Throughout... The plural of "pseudowire" is "pseudowires", not "pseudowire's". You may safely use "PWs" in your document. You have a number of other plurals formed as apostrophe-s. Please search for "'s" and fix as necessary. --- Section 1 Some pseudowires are used to transport large volumes of IP traffic between routers at two locations. I assume that, for some definition of "location" this is also true for routers at the same location. So how about... Some pseudowires are used to transport large volumes of IP traffic between routers. --- Section 1 Such pseudowire's do not require strict ordering to be preserved between packets of the pseudowire. They only require ordering to be preserved within the context of each individual transported IP flow. I see where this is going, but the first sentence is massively more relaxed than the second! How about turning it around... Such pseudowires only require packet ordering to be preserved within the context of each individual transported IP flow. They do not require packet ordering to be preserved between all packets of the across all IP flows within the pseudowire. --- Section 1 Some operators have requested the ability to explicitly configure such a pseudowire to leverage the availability of multiple ECMP paths. I wish you did not feel the need to include this assertion. Why not just get on and describe the benefits (as you do in the next sentence). Currently it really sounds like this is an idea that is strongly opposed and you are trying to justify it to the rest of the community. In fact, the community will judge according to the technical merits. --- Please don't use the word "draft" in the text as it creates work for the RFC Editor and might get missed in the publication process. Obviously, by the time this is published as an RFC it will no longer be a draft. Best thing to do is search and replace "draft" with "document". --- Section 1 Typically, forwarding hardware can deduce that an IP payload is being directly carried by an MPLS label stack, and is capable of looking at some fields in packets to construct hash buckets for conversations or flows. However, an intermediate node has no information on the type pseudowire being carried in the packet. Is the first sentence relevant to this document? I don't think so, but if you believe it is, I think you will need to add a statement about how this deduction is made. --- Section 1 In the case of a pseudowire emulating a high bandwidth trunk, the granularity obtained by hashing the default label stack is inadequate for satisfactory load-balancing. Is "the default label stack" intended to convey some special meaning? I suspect you are trying to say "the label stack that would be constructed if this I-D hasn't been implemented". You will simply have to go down the path of saying... In the case of a pseudowire emulating a high bandwidth trunk, the granularity obtained by hashing the label stack is inadequate for satisfactory load-balancing. --- Section 1 This draft proposes a method to introduce granularity on the hashing of traffic running over pseudowires by introducing an additional label, chosen by the ingress node, and placed at the bottom of the label stack. As above: s/draft/document/ Also, please be less timid. Your document defines a method. --- Section 1.1 s/1.1. ECMP in Label Switched Routers/1.1. ECMP in Label Switching Routers/ s/Label switched routers/Label Switching Routers (LSRs)/ --- Section 1.1 been proposed [I-D.kompella-mpls-entropy-label], however that is Reading would be significantly enhanced by forward reference to section 8. --- Section 3 It is recommended RECOMMENDED ? --- Section 3 It is recommended that the method chosen to generate the load balancing labels introduces a high degree of entropy in their values, to maximise the entropy presented to the ECMP path selection mechanism in the LSRs in the PSN, and hence distribute the flows as evenly as possible over the available PSN ECMP paths. It isn't clear to me that entropy is necessarily a good thing. It depends on the hash algorithm, doesn't it. --- Figure 2 Those four-octet things are not actually labels are they. --- What is the purpose of the T bit? Why would an implementation go to the trouble of including the flow-label TLV only to set T=0? --- Section 4 If PWE3 signalling [RFC4447] is not in use for a pseudowire, then whether the flow label is used MUST be identically provisioned in both PEs at the pseudowire endpoints. If there is no provisioning support for this option, the default behaviour is not to include the flow label. This paragraph is misplaced in the section on signaling. Please put it elsewhere. I am not convinced by the 2119 language in this paragraph since an implementation cannot control the behavior. --- Section 4 Do you not think that you should say that the new sub-TLV is carried in the Interface Parameters TLV, and on which messages? --- Section 4.1 o FL is the flow label sub-TLV identifier assigned by IANA. Can you either put in a [TBD] flag so the RFC Editor will catch this, or a forward pointer to section 10. --- Section 5 Consider an egress that doesn't support flow label, but previous S-PEs that do. In this case you are content to throw the baby out with the bath water? --- Section 6 We believe that this problem is addressed by the following two methods I would like you to be more definitive, please. But, that said, the subsequent bullets do not provide methods of addressing OAM in this case. Rather, the text attempts to say why the problem is not important. In my opinion it fails since, although ECMP is out of scope for MPLS-TP, a user has reasonable expectations that some of the flows on their PW will not be wiped out for the IGP convergence period, when (for example) rapid notification followed by change of the flow label could cause the traffic to be balanced differently and avoid the failure, or when a partial failure of a PW could trigger a switch to a different PW. --- Section 6 s/corruption of an/corruption of a/ --- You need to get rid of the reference to I-D.ietf-mpls-lsr-self-test This work has clearly been abandoned. --- s/Figure 4: Use of Router Alert LAbel/Figure 4: Use of Router Alert Label/ --- Figure 4 Shouldn't "payload" actually read "VCCV message"? Shouldn't you include the warning (from 5085) that inserting the router alert label probably breaks the ECMP hashing such that the packets will go another way. --- How funny that labels that are conventionally described as being "above" on the label stack are shown in your diagrams as below. --- Section 7 s/The methods describe/The methods described/ s/The method proposed/The method defined/ s/in those cased/in those cases/ s/The methods describe/The methods described/ --- Section 7 order is not maintained amongst packets of different flows. I know what you mean, but you have actually said something subtly different. --- Section 7 Ethernet may have this property, and for that reason this document focuses on Ethernet. Applications for other high- access-bandwidth PW's (e.g. Fibre Channel) may be defined in the future. Does the document really *focus* on Ethernet? There are a couple of places where Ethernet is cited as an example (but where the text says equally applicable, blah, blah) and two paragraphs a little below this statement that say "the Ethernet PW". Nothing else. Can't you generalise? --- Section 7 If sequence number support is required this mechanism is not applicable. It's stronger than that, isn't it? You need to prohibit the mechanism. But shouldn't you also prohibit ECMP? --- Section 7 Where it is known that the traffic carried by the Ethernet pseudowire is IP the method of identifying the flows are well known and can be applied. Such methods typically include hashing on the source and destination addresses, the protocol ID and higher-layer flow- dependent fields such as TCP/UDP ports, L2TPv3 Session ID's etc. Either s/method/methods/ or s/are/is/ If these methods are so well known, you will have no difficulty in supplying a reference or two. I think you have mixed the method of identifying the flows with the method of hashing the flows into buckets. --- Section 7.1 In the ECMP case and the link bundling case the NSP may attempt to take bandwidth into consideration when allocating groups of flows to a common path. That is permitted, but it must be borne in mind that the semantics of a label stack entry (LSE) as defined by [RFC3032] cannot be modified, the value of the flow label cannot be modified at any point on the LSP, and the interpretation of bit patterns in, or values of, the flow label by an LSR are undefined. If you have something to say, you should say it. Otherwise your paragraph is lost on your readers. I think you are trying to say "There is no mechanism currently defined to indicate the bandwidths in use by specific flows using the fields of the MPLS shim header. Furthermore, since the semantics of the MPLS shim header are fully defined in [RFC3032] and [RFC5462], those fields cannot be assigned semantics to carry this information. This document does not define any semantic for use in the TTL or TC fields of the label entry that carries the flow label, but requires that the flow label itself be selected with a high degree of entropy suggesting that the label value should not be overloaded with additional meaning in any subsequent specification." --- Section 7.1 A different type of load balancing is the desire to carry a pseudowire over a set of PSN links in which the bandwidth of members of the link set is less than the bandwidth of the pseudowire. This problem is addressed in [I-D.stein-pwe3-pwbonding]. Such a mechanism can be considered complementary to this mechanism. The referenced I-D seems to be dead. I'm not quite sure why you need to reference it here. How about just taking out the paragraph? --- Section 7.2 appears to describe exactly the link bundling case that you discussed in section 7. I have recently noticed considerable confusion between link bundles and LAG and suggest you restrict LAG to be a data link function that is below the level of an "interface" in the IP/MPLS world. That does not mean that an individual node, knowing (by unspecified means) that it is about to use an interface that is constructed from a LAG, can't hash the traffic across the LAG. Ultimately, you should consider ECMP (i.e. multiple IGP paths) where each hop on each path may be made a link bundle, and where each component link of a bundle may be supported by LAG. Can you go back and check that you have used the language precisely. --- Section 7.4 If the payload on a PW is made of a single inner flow (i.e. an encrypted connection between two routers), or the flow identifiers are too deeply buried in the packet, then the functionality described in this document does not give any benefits, though neither does it cause harm relative to the existing situation. Is that s/i.e./e.g./? "Too deeply buried" meaning "If the NSP cannot access sufficient information to distinguish flows, perhaps because the protocol stack is too deep for its capabilities..."? Is the statement about "no harm" necessary? After all, the mechanism will simply not be used in this case. --- Section 7.4 The most common case where a single flow dominated the traffic on a PW is when it is used to transport enterprise traffic. Enterprise traffic may well consist of a large single TCP flows, or encrypted flows that cannot be handled by the methods described in this document. s/dominated/dominates/ s/a large single TCP flows/large TCP flows/ Note that this second half of the paragraph is a non-sequitur from the first half. You probably need to wrap the whole paragraph with a thought about single or dominant large flows. --- Section 7.4 1. The operator can do nothing and the system will work as it does without the flow label. s/can do nothing/can choose to do nothing/ --- Section 7.4 An operator has six options under these circumstances: :-) You tease! There are only five listed. --- Section 7.4 s/an single flow/a single flow/ --- Section 7.4 5. The operator could configure the ingress to assign a label of special significance (such as a reserved label) to all high bandwidth flows so that some other action (not specified in this document) could be taken on the flow. I think you need to delete this as it contradicts two specific statements made elsewhere... 1. MUST NOT use a reserved label as the flow label 2. MUST NOT assign semantics to the flow label --- 8. Applicability to MPLS While I see where you are coming from, I must point out that the whole of your document is about MPLS. Could you come up with a better title? --- Section 9 The ingress PE SHOULD take steps to ensure that the load-balance label is not used as a covert channel. Again, you are saying something between the lines :-( Since the ingress PE allocates the label (isn't it called the flow label not the load-balance label?) the "SHOULD take steps" is very odd! And why is this a security requirement? How would security be compromised? --- Section 9 This document has signaling extensions in it, so you should reference RFC 4447 from this section. You should also reference RFC 5920. --- Section 9 The flow label TTL should therefore never be considered by the forwarder, and hence SHOULD be set to a value of 1. This will prevent the packet being inadvertently forwarded based on the value of the flow label. Note that this may be a departure from considerations that apply to the general MPLS case. But you have previously said that the flow label TTL is never used to discard a packet based on TTL expiry [section 1.2]. You need to make your mind up. And, if there are rules you wish to apply for setting fields, you need to put them in the main part of the protocol spec, not buried in the security section. And (while I'm at it) how is this a security feature? Oh, and another thing... The sequence of your logic is broken. It would be fine to say: If the flow label is inadvertently examined as if it were a normal label, the packet might be forwarded. This can be prevented by setting the associated TTL to 1. But I don't think that "should never be considered" leads to "should be set to 1". Finally, the note at the end is at best unhelpful. What are you trying to say, and why? --- Section 10 Please change this text to reference early allocation that has been made for you. Note that the value 17 has NOT been assigned (although the value 0x17 has).