From pdutta@alcatel-lucent.com Wed Apr 1 00:51:53 2009 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 ACA653A680B; Wed, 1 Apr 2009 00:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 QzXCijsrRuy5; Wed, 1 Apr 2009 00:51:53 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id A83FD3A6860; Wed, 1 Apr 2009 00:51:51 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n317qXd9005521 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 1 Apr 2009 09:52:49 +0200 Received: from INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 1 Apr 2009 09:52:26 +0200 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 1 Apr 2009 13:19:37 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Date: Wed, 1 Apr 2009 13:19:34 +0530 Thread-Topic: draft-bryant-pwe3-packet-pw-00.txt to WG draft? Thread-Index: Acmx+FcP5L7TrJafSfatI2vSUDObcAApgpYA Message-ID: References: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.com> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.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_C584046466ED224CA92C1BC3313B963E0358E740D5INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "mpls-tp@ietf.org" Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 07:51:53 -0000 --_000_C584046466ED224CA92C1BC3313B963E0358E740D5INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOC= CI Matthew Sent: Tuesday, March 31, 2009 5:01 AM To: pwe3@ietf.org Cc: mpls-tp@ietf.org Subject: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? This is the start of a two week poll to judge the consensus to move draft-b= ryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft. Please can you respond, *to the PWE3 list only*, with your approval (or oth= erwise). This poll will close on 14th April 2009. Regards Matthew --_000_C584046466ED224CA92C1BC3313B963E0358E740D5INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-bryant-pwe3-packet-pw-00.txt to WG draft?

Support.

 


From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI Matthew
Sent: Tuesday, March 31, 200= 9 5:01 AM
To: pwe3@ietf.org
Cc: mpls-tp@ietf.org
Subject: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?

 

This is the start of a two week poll to judge the consensus to move draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft.

Please can you respond, *to the PWE3 list only*, with your approval (or otherwise)= .

This poll will close on 14th April 2009.

Regards

Matthew

 =

--_000_C584046466ED224CA92C1BC3313B963E0358E740D5INBANSXCHMBSA_-- From philippe.niger@orange-ftgroup.com Wed Apr 1 02:43:10 2009 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 83BB23A690B for ; Wed, 1 Apr 2009 02:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 SyxvbOYMnARs for ; Wed, 1 Apr 2009 02:43:09 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 46C643A6AF2 for ; Wed, 1 Apr 2009 02:43:09 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 11:44:08 +0200 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_01C9B2AE.66BD5B8B" Date: Wed, 1 Apr 2009 11:44:07 +0200 Message-ID: In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? Thread-Index: Acmx9uZY0mmoKvLIT1OqXckF2OpOJgAt1wpA References: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> From: To: X-OriginalArrivalTime: 01 Apr 2009 09:44:08.0162 (UTC) FILETIME=[6729DC20:01C9B2AE] Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 09:43:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B2AE.66BD5B8B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Support. =20 Regards =20 Philippe. ________________________________ De : pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] De la part de = BOCCI Matthew Envoy=E9 : mardi 31 mars 2009 13:51 =C0 : pwe3@ietf.org Objet : [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? This is the start of a two week poll to judge the consensus to move = draft-bryant-filsfils-fat-pw-03=20 to a PWE3 Working Group draft.=20 Please can you respond to the PWE3 list with your approval (or = otherwise).=20 This poll will close on 14th April 2009.=20 Regards=20 Matthew=20 ------_=_NextPart_001_01C9B2AE.66BD5B8B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-bryant-filsfils-fat-pw-03 to WG draft?
Support.
 
Regards
 
Philippe.


De : pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] De la part de BOCCI=20 Matthew
Envoy=E9 : mardi 31 mars 2009 = 13:51
=C0 :=20 pwe3@ietf.org
Objet : [PWE3] = draft-bryant-filsfils-fat-pw-03 to=20 WG draft?

This is the start of a two week poll to = judge the=20 consensus to move draft-bryant-filsfils-fat-pw-03
 to a PWE3 Working Group draft.

Please can you respond to the PWE3 list = with your=20 approval (or otherwise).

This poll will close on 14th April = 2009.

Regards

Matthew


------_=_NextPart_001_01C9B2AE.66BD5B8B-- From frederic.jounay@orange-ftgroup.com Wed Apr 1 03:06:30 2009 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 58F4228C181 for ; Wed, 1 Apr 2009 03:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 ptGS3rFSk0wR for ; Wed, 1 Apr 2009 03:06:29 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 1770928C18B for ; Wed, 1 Apr 2009 03:06:28 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 12:07:26 +0200 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_01C9B2B1.A8FF5677" Date: Wed, 1 Apr 2009 12:07:26 +0200 Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A155AF768@ftrdmel2> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? Thread-Index: Acmx9uZY0mmoKvLIT1OqXckF2OpOJgAt1wpAAADW1UA= References: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> From: To: X-OriginalArrivalTime: 01 Apr 2009 10:07:26.0970 (UTC) FILETIME=[A8EB05A0:01C9B2B1] Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 10:06:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B2B1.A8FF5677 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Support. Fred=20 ________________________________ De : pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] De la part de = BOCCI Matthew Envoy=E9 : mardi 31 mars 2009 13:51 =C0 : pwe3@ietf.org Objet : [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? This is the start of a two week poll to judge the consensus to move = draft-bryant-filsfils-fat-pw-03=20 to a PWE3 Working Group draft.=20 Please can you respond to the PWE3 list with your approval (or = otherwise).=20 This poll will close on 14th April 2009.=20 Regards=20 Matthew=20 ------_=_NextPart_001_01C9B2B1.A8FF5677 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-bryant-filsfils-fat-pw-03 to WG draft?
 Support.
Fred 

De : pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] De la part de BOCCI=20 Matthew
Envoy=E9 : mardi 31 mars 2009 = 13:51
=C0 :=20 pwe3@ietf.org
Objet : [PWE3] = draft-bryant-filsfils-fat-pw-03 to=20 WG draft?

This is the start of a two week poll to = judge the=20 consensus to move draft-bryant-filsfils-fat-pw-03
 to a PWE3 Working Group draft.

Please can you respond to the PWE3 list = with your=20 approval (or otherwise).

This poll will close on 14th April = 2009.

Regards

Matthew


------_=_NextPart_001_01C9B2B1.A8FF5677-- From stbryant@cisco.com Wed Apr 1 03:54:20 2009 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 74B8428C19C for ; Wed, 1 Apr 2009 03:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.646 X-Spam-Level: X-Spam-Status: No, score=-7.646 tagged_above=-999 required=5 tests=[AWL=-1.047, 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 pftzDprgezxw for ; Wed, 1 Apr 2009 03:54:19 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5C95B28C151 for ; Wed, 1 Apr 2009 03:54:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,305,1235952000"; d="scan'208";a="277999418" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2009 10:55:19 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n31AtIuP028632; Wed, 1 Apr 2009 12:55:18 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n31AtIcH000572; Wed, 1 Apr 2009 10:55:18 GMT Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n31AtHP17371; Wed, 1 Apr 2009 11:55:17 +0100 (BST) Message-ID: <49D34815.8080801@cisco.com> Date: Wed, 01 Apr 2009 11:55:17 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: neil.2.harrison@bt.com References: <2ECAA42C79676B42AEBAC11229CA7D0C045D50FE@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C045D50FE@E03MVB2-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2404; t=1238583318; x=1239447318; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20draft-bryant-filsfils-fat-pw-0 3=20to=20WG=20draft? |Sender:=20; bh=hVGWMdG0l82wQGkp4bHoJLb9qGCfbQ0xuo+T1FtzJ4Y=; b=MQHiSg7fHKxzjXeeKwp83s2o0ST9epSa7169CcBFUtIDv7jLXy7GB50RbJ lyEaVQNsL7/3XPDIHKZHV65BMZOTfNbt2w3+fWCRyrFxCJbz1wkHBitJyZHG 7Y5VduQU15; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? 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, 01 Apr 2009 10:54:20 -0000 The draft has applicability to Transport. I will come to the details below in a minute, but tell me how you propose to cope with ESSM in a client - surely you need to intervene rather than carry them transparently? Remember that the client layer performs the classification into protocol types so we just carry the classification over the server layer in a more convenient way. Remember if you don't like the pkt-pw you can always put a real interface in and use a L2 pw, and if you don't like that you can always but a clear fibre. What you do depends on how you wish to run the economics. neil.2.harrison@bt.com wrote: > Stewart, can I please ask if this draft would be applicable to MPLS-TP? > > I ask this because a transport network should satisfy the requirements > of transparency....which in brief means: > > - all client bits treated equally That happens here > - client bit ordering preserved That also happens here > - no attempt made to try understand semantics of client symbols (ie > client message/traffic-unit formed from N client bits) and never > change client bits In this mechanism it is the client layer that makes the changes - not the server layer. The client presents the packet and and metadata saying what pid the server is to write into the PID > - server ensures client X traffic behaviour cannot impact > performance experienced by client Y We pass that test > > ...and I cannot reconcile this with this draft. So perhaps this draft > is only intended to apply to 'classical' MPLS? It's not clear that it fails the test when you realize that the client is presenting the modified data to the server. Stewart > > regards, Neil > > ------------------------------------------------------------------------ > *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On > Behalf Of *BOCCI Matthew > *Sent:* 31 March 2009 12:51 > *To:* pwe3@ietf.org > *Subject:* [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? > > This is the start of a two week poll to judge the consensus to > move draft-bryant-filsfils-fat-pw-03 > to a PWE3 Working Group draft. > > Please can you respond to the PWE3 list with your approval (or > otherwise). > > This poll will close on 14th April 2009. > > Regards > > Matthew > > From neil.2.harrison@bt.com Wed Apr 1 07:26:12 2009 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 3C9CE3A6A1C for ; Wed, 1 Apr 2009 07:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, 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 NkSCabRYq5Gf for ; Wed, 1 Apr 2009 07:26:11 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id B73C93A691A for ; Wed, 1 Apr 2009 07:26:10 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 15:27:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Apr 2009 15:27:02 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C045D557A@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <49D34815.8080801@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? Thread-Index: AcmyuFzJ/cvlJ2SYTvCOm+hhU82F2QAFjVxA From: To: X-OriginalArrivalTime: 01 Apr 2009 14:27:10.0367 (UTC) FILETIME=[F158B2F0:01C9B2D5] Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 14:26:12 -0000 Thanks Stewart, =20 Stewart answered 01 April 2009 11:55 >=20 > The draft has applicability to Transport. >=20 > I will come to the details below in a minute, but tell me how you=20 > propose to cope with > ESSM in a client - surely you need to intervene rather than=20 > carry them=20 > transparently? NH=3D> I am not familiar with what you mean by ESSM .....are you meaning some of the Ethernet 'slow protocols'?...if so then yes, these belong to a p2p Ethernet section layer only. >=20 > Remember that the client layer performs the classification=20 > into protocol=20 > types > so we just carry the classification over the server layer in a more=20 > convenient way. NH=3D> Normally adaptation to a transport network passes down PID primitives and (esp for a co-cs server) attends to things like client traffic unit delineation and idle fill. One of the things we usually cannot do (and indeed don't want to do) is try and understand each specific ultimate application's QoS or (more importantly) survivability importance semantics....this is of course what a co-cs server does by 'default'....and this becomes of increasing importance when the client is not a top-of-stack layer network anyway (so one can't even see the top-level message/file/stream application conversations, and even if we could we would usually not be in any position to make value judgements on survivability importance). If we have a definite IP top-of-stack layer network that we can see then we can get at the end-end UDP/TCP/RTP adapted applications and thus keep conversations together. Now a top-of stack layer network is always present (has to be, else there is no communication happening), but this may not be the immediate client, and so may not be easily visible...the real top-of-stack layer network may be several layers removed from the immediate client.....so I am thinking of things like when we do MPLSoverMPLS, where the layers involved here could be something like this: Application_UDP/TCP/RTP_IP_MPLSclient_ETH_PW_MPLSserver_X. It's not at all clear to me that the MPLSserver network should be trying to figure out the end-end application flows above the MPLSclient network. Would you agree with that? >=20 > Remember if you don't like the pkt-pw you can always put a=20 > real interface in > and use a L2 pw, and if you don't like that you can always=20 > but a clear > fibre. What you do depends on how you wish to run the economics. NH=3D> Agreed. But when we start introducing inter-layer functional dependencies complexity rises.....increasing complexity usually means rapidly increasing marginal costs with increase in scale/scope of a system. This is why you will hear folks like me and Andy Reid talk about the importance of 'transparency' in client/server relationships, and esp so for transport networks....its not just important for the clients but its also important to control complexity costs of the server (and overall networking system). I was under the impression that ECMP would not be used in MPLS-TP, but if MPLS-TP is not supposed to be a emulating a true transport network then I guess one can do this. regards, Neil >=20 >=20 >=20 > neil.2.harrison@bt.com wrote: > > Stewart, can I please ask if this draft would be applicable=20 > to MPLS-TP? > > =20 > > I ask this because a transport network should satisfy the=20 > requirements=20 > > of transparency....which in brief means: > > =20 > > - all client bits treated equally > That happens here > > - client bit ordering preserved > That also happens here > > - no attempt made to try understand semantics of client=20 > symbols (ie=20 > > client message/traffic-unit formed from N client bits) and never=20 > > change client bits > In this mechanism it is the client layer that makes the changes - not=20 > the server layer. The client presents the packet and and=20 > metadata saying=20 > what pid the server is to write into the PID > > - server ensures client X traffic behaviour cannot impact=20 > > performance experienced by client Y > We pass that test > > =20 > > ...and I cannot reconcile this with this draft. So perhaps=20 > this draft=20 > > is only intended to apply to 'classical' MPLS? > It's not clear that it fails the test when you realize that=20 > the client=20 > is presenting the modified data to the server. >=20 > Stewart >=20 > > =20 > > regards, Neil > > > > =20 > -------------------------------------------------------------- > ---------- > > *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On > > Behalf Of *BOCCI Matthew > > *Sent:* 31 March 2009 12:51 > > *To:* pwe3@ietf.org > > *Subject:* [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? > > > > This is the start of a two week poll to judge the consensus to > > move draft-bryant-filsfils-fat-pw-03 > > to a PWE3 Working Group draft. > > > > Please can you respond to the PWE3 list with your approval (or > > otherwise). > > > > This poll will close on 14th April 2009. > > > > Regards > > > > Matthew > > > > >=20 >=20 From ping@pingpan.org Wed Apr 1 07:31:55 2009 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 030383A6DCA for ; Wed, 1 Apr 2009 07:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.75 X-Spam-Level: X-Spam-Status: No, score=-4.75 tagged_above=-999 required=5 tests=[AWL=1.226, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 vd8Nl8+L93io for ; Wed, 1 Apr 2009 07:31:51 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with SMTP id 18BEA3A6DAE for ; Wed, 1 Apr 2009 07:31:51 -0700 (PDT) Received: from source ([209.85.200.175]) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKSdN7EyyjogP5BGAMpYKMRf/Okz0blYvP@postini.com; Wed, 01 Apr 2009 07:32:51 PDT Received: by wf-out-1314.google.com with SMTP id 24so60543wfg.23 for ; Wed, 01 Apr 2009 07:32:51 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> References: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> Date: Wed, 1 Apr 2009 07:32:36 -0700 Received: by 10.143.156.12 with SMTP id i12mr3143070wfo.320.1238596371297; Wed, 01 Apr 2009 07:32:51 -0700 (PDT) Message-ID: <22d04a930904010732y2b7e4bd4u48e7f6fd95e1642d@mail.gmail.com> From: Ping Pan To: BOCCI Matthew Content-Type: multipart/alternative; boundary=001636e1fad1bb374e04667f304b Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 14:31:55 -0000 --001636e1fad1bb374e04667f304b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Support 2009/3/31 BOCCI Matthew > This is the start of a two week poll to judge the consensus to move > draft-bryant-filsfils-fat-pw-03 > to a PWE3 Working Group draft. > > Please can you respond to the PWE3 list with your approval (or otherwise). > > This poll will close on 14th April 2009. > > Regards > > Matthew > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --001636e1fad1bb374e04667f304b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Support

2009/3/31 BOCCI Matthew <Matthew.Bo= cci@alcatel-lucent.com>

This is the start of a two week poll to = judge the consensus to move draft-bryant-filsfils-fat-pw-03
=C2=A0to a PWE3 Working Group draft.

Please can you respond to the PWE3 list = with your approval (or otherwise).

This poll will close on 14th April 2009.=

Regards

Matthew



_______________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3


--001636e1fad1bb374e04667f304b-- From jk@ujo.de Wed Apr 1 02:37:11 2009 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 261453A6C5E for ; Wed, 1 Apr 2009 02:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 T2GwS90gwdnb for ; Wed, 1 Apr 2009 02:37:10 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 1273F3A6C5C for ; Wed, 1 Apr 2009 02:37:09 -0700 (PDT) Received: by ewy9 with SMTP id 9so2978158ewy.37 for ; Wed, 01 Apr 2009 02:38:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.210.33.3 with SMTP id g3mr5842347ebg.21.1238578688870; Wed, 01 Apr 2009 02:38:08 -0700 (PDT) Date: Wed, 1 Apr 2009 11:38:08 +0200 Message-ID: From: =?ISO-8859-1?Q?J=F6rg_K=FCchemann?= To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=0015174c1982c6cb9d04667b1258 X-Mailman-Approved-At: Wed, 01 Apr 2009 08:01:53 -0700 Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 12:05:44 -0000 --0015174c1982c6cb9d04667b1258 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable draft-bryant-filsfils-fat-pw-03 to WG draft? support* **From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On Behalf Of *BOCCI Matthew *Sent:* Dienstag, M=E4rz 31, 2009 13:51 *To:* pwe3@ietf.org *Subject:* [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? This is the start of a two week poll to judge the consensus to move draft-bryant-filsfils-fat-pw-03 to a PWE3 Working Group draft. Please can you respond to the PWE3 list with your approval (or otherwise). This poll will close on 14th April 2009. Regards Matthew --0015174c1982c6cb9d04667b1258 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable draft-bryant-filsfils-fat-pw-03 to WG draft?
support

From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org]= On Behalf Of BOCCI Matthew
Sent:=20 Dienstag, M=E4rz 31, 2009 13:51
= To: pwe3@ietf.org
Subject:=20 [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?


This is the= start of a two week poll to judge the=20 consensus to move draft-bryant-filsfils-fat-pw-03
=A0to a PWE3 Working Group draft.

Please can = you respond to the PWE3 list with your=20 approval (or otherwise).

This poll w= ill close on 14th April 2009.

Regards

Matthew

--0015174c1982c6cb9d04667b1258-- From hshah@ciena.com Wed Apr 1 08:07:54 2009 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 69B043A687C for ; Wed, 1 Apr 2009 08:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46] 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 2jkO5aQfshn3 for ; Wed, 1 Apr 2009 08:07:53 -0700 (PDT) Received: from ripley.ciena.com (ripley.ciena.com [63.118.34.24]) by core3.amsl.com (Postfix) with ESMTP id 4921B3A67F4 for ; Wed, 1 Apr 2009 08:07:53 -0700 (PDT) x-mimeole: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_4FA4DE_01C9B2BA.3C0806F0" Date: Wed, 1 Apr 2009 11:08:48 -0400 Message-ID: <6535C9CED6F87446B41D20EF170F2362327E5D@mamxm01.ciena.com> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? Importance: normal Thread-Index: Acmx+FcP5L7TrJafSfatI2vSUDObcAASdYRA Priority: normal References: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.com> From: "Shah, Himanshu" To: X-OriginalArrivalTime: 01 Apr 2009 15:08:49.0634 (UTC) FILETIME=[C3069420:01C9B2DB] Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 15:07:54 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_4FA4DE_01C9B2BA.3C0806F0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B2DB.C293E6A4" ------_=_NextPart_001_01C9B2DB.C293E6A4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I support the effort but I believe this draft needs mroe clarification text before it is accepted as WG draft. =20 This draft is shifting the paradigm, pw label no longer carries the forwarding symantics, instead PPP PID is used. The draft needs to expand on the packet processing aspects. =20 The PW setup needs more clarification text too. It seems that 'server' control plane is used to create PW and tunnels and once PW is created, 'client' forwarding plane (to backhaul MPLS) and control plane (perhaps the same protocols as 'server' protcols) is used to=20 splice the 'client' MPLS networks. I think authors need to expand on this along with=20 additional rules as break criteria so that such recurssions don't create stack overflow. For instance, once the PW is up and being used as virtual interface with an IP address, can a 'client' PE/S-PE/T-PE be used on that server-PW-come-virtual-interface? =20 Its bit amusing that we started with PW to go over MPLS, now we need PW to carry MPLS...:-) =20 regards, himanshu =20 =20 =20 =20 ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: Tuesday, March 31, 2009 8:01 AM To: pwe3@ietf.org Cc: mpls-tp@ietf.org Subject: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? This is the start of a two week poll to judge the consensus to move draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft. Please can you respond, *to the PWE3 list only*, with your approval (or otherwise).=20 This poll will close on 14th April 2009.=20 Regards=20 Matthew=20 ------_=_NextPart_001_01C9B2DB.C293E6A4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable draft-bryant-pwe3-packet-pw-00.txt to = WG draft?
I support the effort = but I believe this=20 draft needs mroe clarification text
before it is accepted = as WG=20 draft.
 
This draft is shifting = the paradigm, pw=20 label no longer carries the forwarding symantics,
instead PPP PID is = used.  The draft=20 needs to expand on the packet processing aspects.
 
The PW setup needs more = clarification text=20 too.  It seems that 'server' control plane is = used
to create PW and = tunnels and once PW is=20 created, 'client' forwarding plane (to backhaul
MPLS) and control plane = (perhaps the same=20 protocols as 'server' protcols) is used to
splice the 'client' = MPLS=20 networks.  I think authors need = to expand on this=20 along with
additional=20 rules as break criteria so that = such recurssions=20 don't create stack overflow. For instance, once
the PW is up and being = used as virtual=20 interface with an IP address, can a 'client'=20  PE/S-PE/T-PE
be used on that=20 server-PW-come-virtual-interface?
 
Its bit amusing that we = started with PW to=20 go over MPLS, now we need PW to carry MPLS...:-)
 
regards,
himanshu
 
 
 
 




From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI = Matthew
Sent:=20 Tuesday, March 31, 2009 8:01 AM
To: = pwe3@ietf.org
Cc:=20 mpls-tp@ietf.org
Subject: [PWE3] = draft-bryant-pwe3-packet-pw-00.txt to=20 WG draft?

This is the start of a two week poll to = judge the=20 consensus to move draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working = Group=20 draft.

Please can you respond, *to the PWE3 list = only*, with=20 your approval (or otherwise).

This poll will close on 14th April = 2009.

Regards

Matthew =




------_=_NextPart_001_01C9B2DB.C293E6A4-- ------=_NextPart_000_4FA4DE_01C9B2BA.3C0806F0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= ------=_NextPart_000_4FA4DE_01C9B2BA.3C0806F0-- From lucyyong@huawei.com Wed Apr 1 08:09:37 2009 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 7D97E3A687C for ; Wed, 1 Apr 2009 08:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=0.912, 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 xXPbgrzY5IUH for ; Wed, 1 Apr 2009 08:09:36 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id A65073A67F4 for ; Wed, 1 Apr 2009 08:09:36 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHF00ESZGTGUE@usaga02-in.huawei.com> for pwe3@ietf.org; Wed, 01 Apr 2009 08:10:29 -0700 (PDT) Received: from Y73674 ([10.124.12.103]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHF00HSHFSIO5@usaga02-in.huawei.com> for pwe3@ietf.org; Wed, 01 Apr 2009 07:48:18 -0700 (PDT) Date: Wed, 01 Apr 2009 09:48:18 -0500 From: Lucy Yong In-reply-to: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> To: 'BOCCI Matthew' , pwe3@ietf.org Message-id: <004601c9b2d8$e536e570$670c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_dBflhvWUJJ5HnnfQtJNodQ)" Thread-index: Acmx9uZY0mmoKvLIT1OqXckF2OpOJgA4fgIg References: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 15:09:37 -0000 This is a multi-part message in MIME format. --Boundary_(ID_dBflhvWUJJ5HnnfQtJNodQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Support. Lucy _____ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: Tuesday, March 31, 2009 6:51 AM To: pwe3@ietf.org Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? This is the start of a two week poll to judge the consensus to move draft-bryant-filsfils-fat-pw-03 to a PWE3 Working Group draft. Please can you respond to the PWE3 list with your approval (or otherwise). This poll will close on 14th April 2009. Regards Matthew --Boundary_(ID_dBflhvWUJJ5HnnfQtJNodQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT draft-bryant-filsfils-fat-pw-03 to WG draft?

Support.

Lucy

 


From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI Matthew
Sent: Tuesday, March 31, 2009 6:51 AM
To: pwe3@ietf.org
Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?

 

This is the start of a two week poll to judge the consensus to move draft-bryant-filsfils-fat-pw-03
 to a PWE3 Working Group draft.

Please can you respond to the PWE3 list with your approval (or otherwise).

This poll will close on 14th April 2009.

Regards

Matthew

 

--Boundary_(ID_dBflhvWUJJ5HnnfQtJNodQ)-- From Italo.Busi@alcatel-lucent.it Wed Apr 1 08:23:52 2009 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 75CFE28C0E7 for ; Wed, 1 Apr 2009 08:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 DPDoDDD4-CyT for ; Wed, 1 Apr 2009 08:23:51 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 488C73A6874 for ; Wed, 1 Apr 2009 08:23:51 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n31FOK6a017812; Wed, 1 Apr 2009 17:24:22 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 17:24:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Apr 2009 17:24:19 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4020EA390@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <49D34815.8080801@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? Thread-Index: AcmyuF/j95NkpkGlQ8eywnmv4VRefwAJPFjg References: <2ECAA42C79676B42AEBAC11229CA7D0C045D50FE@E03MVB2-UKBR.domain1.systemhost.net> <49D34815.8080801@cisco.com> From: "BUSI ITALO" To: , X-OriginalArrivalTime: 01 Apr 2009 15:24:21.0608 (UTC) FILETIME=[EE868680:01C9B2DD] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 15:23:52 -0000 Stewart, Could you please clarify the applicability of Fat PW to MPLS-TP? In SF, you stated that they are applicable to "ECMP and LAG case" and this matched with my understanding of the draft. Due to the fact that ECMP is not used in MPLS-TP, I had assumed this draft is not applicable in MPLS-TP. Did I miss/misunderstand anything? Thanks, Italo > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > Behalf Of Stewart Bryant > Sent: Wednesday, April 01, 2009 12:55 PM > To: neil.2.harrison@bt.com > Cc: pwe3@ietf.org > Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? >=20 > The draft has applicability to Transport. >=20 > I will come to the details below in a minute, but tell me how you=20 > propose to cope with > ESSM in a client - surely you need to intervene rather than=20 > carry them=20 > transparently? >=20 > Remember that the client layer performs the classification=20 > into protocol=20 > types > so we just carry the classification over the server layer in a more=20 > convenient way. >=20 > Remember if you don't like the pkt-pw you can always put a=20 > real interface in > and use a L2 pw, and if you don't like that you can always=20 > but a clear > fibre. What you do depends on how you wish to run the economics. >=20 >=20 >=20 > neil.2.harrison@bt.com wrote: > > Stewart, can I please ask if this draft would be applicable=20 > to MPLS-TP? > > =20 > > I ask this because a transport network should satisfy the=20 > requirements=20 > > of transparency....which in brief means: > > =20 > > - all client bits treated equally > That happens here > > - client bit ordering preserved > That also happens here > > - no attempt made to try understand semantics of client=20 > symbols (ie=20 > > client message/traffic-unit formed from N client bits) and never=20 > > change client bits > In this mechanism it is the client layer that makes the changes - not=20 > the server layer. The client presents the packet and and=20 > metadata saying=20 > what pid the server is to write into the PID > > - server ensures client X traffic behaviour cannot impact=20 > > performance experienced by client Y > We pass that test > > =20 > > ...and I cannot reconcile this with this draft. So perhaps=20 > this draft=20 > > is only intended to apply to 'classical' MPLS? > It's not clear that it fails the test when you realize that=20 > the client=20 > is presenting the modified data to the server. >=20 > Stewart >=20 > > =20 > > regards, Neil > > > > =20 > -------------------------------------------------------------- > ---------- > > *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On > > Behalf Of *BOCCI Matthew > > *Sent:* 31 March 2009 12:51 > > *To:* pwe3@ietf.org > > *Subject:* [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? > > > > This is the start of a two week poll to judge the consensus to > > move draft-bryant-filsfils-fat-pw-03 > > to a PWE3 Working Group draft. > > > > Please can you respond to the PWE3 list with your approval (or > > otherwise). > > > > This poll will close on 14th April 2009. > > > > Regards > > > > Matthew > > > > >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 From stbryant@cisco.com Wed Apr 1 08:34:42 2009 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 C19EF3A6B54 for ; Wed, 1 Apr 2009 08:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.622 X-Spam-Level: X-Spam-Status: No, score=-9.622 tagged_above=-999 required=5 tests=[AWL=0.977, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ufwDW2w0OiPJ for ; Wed, 1 Apr 2009 08:34:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 696163A6A36 for ; Wed, 1 Apr 2009 08:34:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,307,1235952000"; d="scan'208";a="37223083" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2009 15:35:35 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n31FZZVq010052; Wed, 1 Apr 2009 17:35:35 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n31FZZxh000790; Wed, 1 Apr 2009 15:35:35 GMT Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n31FZVP18588; Wed, 1 Apr 2009 16:35:32 +0100 (BST) Message-ID: <49D389C2.8010700@cisco.com> Date: Wed, 01 Apr 2009 16:35:30 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: neil.2.harrison@bt.com References: <2ECAA42C79676B42AEBAC11229CA7D0C045D50FE@E03MVB2-UKBR.domain1.systemhost.net> <49D34815.8080801@cisco.com> In-Reply-To: <49D34815.8080801@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2840; t=1238600135; x=1239464135; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20draft-bryant-filsfils-fat-pw-0 3=20to=20WG=20draft? |Sender:=20; bh=9Z77413g/NNFfeV0F0B5CDkoKf+/0bmgs2JKmHdmZxk=; b=XEXHDqfCJQ23SEM5cmsi2oOMbrAO0NqCNEG1IgHmTT3QLXsXM65uAcvItY M4J/UrH+atKepj9p+SMxuDUpD3JY1NmV7swk7gl8TrBQ34Qy5v1FB99zzLBK IIFta4O7Ta; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? 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, 01 Apr 2009 15:34:42 -0000 Actually I should rephrase this. It is the MEAD team that make recommendations as to what is applicable to MPLS-TP, not the PWE3 WG. The Packet PW represents a tool that is certainly of use in MPLS classic, and if the MEAD team deem it appropriate may also be used in MPLS-TP. Stewart Stewart Bryant wrote: > The draft has applicability to Transport. > > I will come to the details below in a minute, but tell me how you > propose to cope with > ESSM in a client - surely you need to intervene rather than carry them > transparently? > > Remember that the client layer performs the classification into > protocol types > so we just carry the classification over the server layer in a more > convenient way. > > Remember if you don't like the pkt-pw you can always put a real > interface in > and use a L2 pw, and if you don't like that you can always but a clear > fibre. What you do depends on how you wish to run the economics. > > > > neil.2.harrison@bt.com wrote: >> Stewart, can I please ask if this draft would be applicable to MPLS-TP? >> >> I ask this because a transport network should satisfy the >> requirements of transparency....which in brief means: >> >> - all client bits treated equally > That happens here >> - client bit ordering preserved > That also happens here >> - no attempt made to try understand semantics of client symbols >> (ie client message/traffic-unit formed from N client bits) and never >> change client bits > In this mechanism it is the client layer that makes the changes - not > the server layer. The client presents the packet and and metadata > saying what pid the server is to write into the PID >> - server ensures client X traffic behaviour cannot impact >> performance experienced by client Y > We pass that test >> >> ...and I cannot reconcile this with this draft. So perhaps this >> draft is only intended to apply to 'classical' MPLS? > It's not clear that it fails the test when you realize that the client > is presenting the modified data to the server. > > Stewart > >> >> regards, Neil >> >> >> ------------------------------------------------------------------------ >> *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On >> Behalf Of *BOCCI Matthew >> *Sent:* 31 March 2009 12:51 >> *To:* pwe3@ietf.org >> *Subject:* [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? >> >> This is the start of a two week poll to judge the consensus to >> move draft-bryant-filsfils-fat-pw-03 >> to a PWE3 Working Group draft. >> >> Please can you respond to the PWE3 list with your approval (or >> otherwise). >> >> This poll will close on 14th April 2009. >> >> Regards >> >> Matthew >> >> > > From lucyyong@huawei.com Wed Apr 1 09:07:26 2009 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 AB6D228C1DC for ; Wed, 1 Apr 2009 09:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.730, 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 gw7XXVW7tLJ2 for ; Wed, 1 Apr 2009 09:07:25 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id BDB3D28C1BF for ; Wed, 1 Apr 2009 09:07:25 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHF002NTJI1SG@usaga04-in.huawei.com> for pwe3@ietf.org; Wed, 01 Apr 2009 11:08:25 -0500 (CDT) Received: from Y73674 ([10.124.12.103]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHF009YBJHWKH@usaga04-in.huawei.com> for pwe3@ietf.org; Wed, 01 Apr 2009 11:08:25 -0500 (CDT) Date: Wed, 01 Apr 2009 11:08:20 -0500 From: Lucy Yong In-reply-to: <49D389C2.8010700@cisco.com> To: stbryant@cisco.com, neil.2.harrison@bt.com Message-id: <006b01c9b2e4$162f0e40$670c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acmy37WK/k4890eTQjqD6oSrS8yF+AABCZuA References: <2ECAA42C79676B42AEBAC11229CA7D0C045D50FE@E03MVB2-UKBR.domain1.systemhost.net> <49D34815.8080801@cisco.com> <49D389C2.8010700@cisco.com> Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 16:07:26 -0000 Are we mixing different subject together? Title is about flow label but the text is Packet PW. Lucy. > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Stewart Bryant > Sent: Wednesday, April 01, 2009 10:36 AM > To: neil.2.harrison@bt.com > Cc: pwe3@ietf.org > Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? > > Actually I should rephrase this. > > It is the MEAD team that make recommendations as to what is applicable > to MPLS-TP, > not the PWE3 WG. > > The Packet PW represents a tool that is certainly of use in MPLS > classic, and > if the MEAD team deem it appropriate may also be used in MPLS-TP. > > Stewart > > > > Stewart Bryant wrote: > > The draft has applicability to Transport. > > > > I will come to the details below in a minute, but tell me how you > > propose to cope with > > ESSM in a client - surely you need to intervene rather than carry them > > transparently? > > > > Remember that the client layer performs the classification into > > protocol types > > so we just carry the classification over the server layer in a more > > convenient way. > > > > Remember if you don't like the pkt-pw you can always put a real > > interface in > > and use a L2 pw, and if you don't like that you can always but a clear > > fibre. What you do depends on how you wish to run the economics. > > > > > > > > neil.2.harrison@bt.com wrote: > >> Stewart, can I please ask if this draft would be applicable to MPLS-TP? > >> > >> I ask this because a transport network should satisfy the > >> requirements of transparency....which in brief means: > >> > >> - all client bits treated equally > > That happens here > >> - client bit ordering preserved > > That also happens here > >> - no attempt made to try understand semantics of client symbols > >> (ie client message/traffic-unit formed from N client bits) and never > >> change client bits > > In this mechanism it is the client layer that makes the changes - not > > the server layer. The client presents the packet and and metadata > > saying what pid the server is to write into the PID > >> - server ensures client X traffic behaviour cannot impact > >> performance experienced by client Y > > We pass that test > >> > >> ...and I cannot reconcile this with this draft. So perhaps this > >> draft is only intended to apply to 'classical' MPLS? > > It's not clear that it fails the test when you realize that the client > > is presenting the modified data to the server. > > > > Stewart > > > >> > >> regards, Neil > >> > >> > >> ------------------------------------------------------------------------ > >> *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On > >> Behalf Of *BOCCI Matthew > >> *Sent:* 31 March 2009 12:51 > >> *To:* pwe3@ietf.org > >> *Subject:* [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? > >> > >> This is the start of a two week poll to judge the consensus to > >> move draft-bryant-filsfils-fat-pw-03 > >> to a PWE3 Working Group draft. > >> > >> Please can you respond to the PWE3 list with your approval (or > >> otherwise). > >> > >> This poll will close on 14th April 2009. > >> > >> Regards > >> > >> Matthew > >> > >> > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From vishwas.ietf@gmail.com Wed Apr 1 09:13:16 2009 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 863733A67F7 for ; Wed, 1 Apr 2009 09:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[AWL=1.295, 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 eWVa3yVmSyUy for ; Wed, 1 Apr 2009 09:13:15 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 843533A6DB7 for ; Wed, 1 Apr 2009 09:13:15 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so104784wfg.31 for ; Wed, 01 Apr 2009 09:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3arMIzplTWkO15bH2GmUQHNLQd1TzpcWrhu2S2VAwks=; b=xdRW+yap6zzp+g84ObdKb9hKbYeWm8d1+0UxHn4Rl/MVBl6im8foU8pxeQKg6dXgWh ciCCJDRuISLUeUvAu1dRWpsGI6hAmCciU0SCtdTzCJMTYXzJxdcmJethg/GW9CiRvMte 7Tf8JSlpg6rgo+NPmofqXvC10VQSTLMDtKSRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SGjHHDtMPaU6KTqU4o34YftgujORKsEAO1azWYQ6/oM8xiDKXrQz0ZYK+5VRQ/agqI gMWUgunCq+JmrBjKqv6YNmrFmy2WfcfWAFfjpR5OLW3LTI57AgqDkmACra1Fs+box9BV shvVxhpVFY2QZsGMC07mpI8RLgk9ugoKHJiQ8= MIME-Version: 1.0 Received: by 10.143.2.19 with SMTP id e19mr3188810wfi.96.1238602456139; Wed, 01 Apr 2009 09:14:16 -0700 (PDT) In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> References: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> Date: Wed, 1 Apr 2009 09:14:16 -0700 Message-ID: <77ead0ec0904010914r143bed3k9fac5e84d0603923@mail.gmail.com> From: Vishwas Manral To: BOCCI Matthew Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 16:13:16 -0000 Support. - Vishwas 2009/3/31 BOCCI Matthew : > This is the start of a two week poll to judge the consensus to move > draft-bryant-filsfils-fat-pw-03 > =A0to a PWE3 Working Group draft. > > Please can you respond to the PWE3 list with your approval (or otherwise)= . > > This poll will close on 14th April 2009. > > Regards > > Matthew > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > From stbryant@cisco.com Wed Apr 1 09:39:47 2009 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 17AEC3A6DE5 for ; Wed, 1 Apr 2009 09:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.679 X-Spam-Level: X-Spam-Status: No, score=-9.679 tagged_above=-999 required=5 tests=[AWL=0.920, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 yBFyusgCKPnn for ; Wed, 1 Apr 2009 09:39:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F18413A6B05 for ; Wed, 1 Apr 2009 09:37:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,307,1235952000"; d="scan'208";a="37230557" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2009 16:38:55 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n31GctfQ029296; Wed, 1 Apr 2009 18:38:55 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n31GctDZ019556; Wed, 1 Apr 2009 16:38:55 GMT Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n31GclP26705; Wed, 1 Apr 2009 17:38:48 +0100 (BST) Message-ID: <49D39892.9060808@cisco.com> Date: Wed, 01 Apr 2009 17:38:42 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: BUSI ITALO References: <2ECAA42C79676B42AEBAC11229CA7D0C045D50FE@E03MVB2-UKBR.domain1.systemhost.net> <49D34815.8080801@cisco.com> <6FD21B53861BF44AA90A288402036AB4020EA390@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <6FD21B53861BF44AA90A288402036AB4020EA390@FRVELSMBS21.ad2.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4247; t=1238603935; x=1239467935; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20draft-bryant-filsfils-fat-pw-0 3=20to=20WG=20draft? |Sender:=20; bh=qtNeHThN9oPd6z9VwZxdu8fDow49bDaqVmoPTKiVOpM=; b=wQap+SJkgdb6Eqt7xdN/uxr40kMUnvIkqeGoz72Jorgrhftl6mDJYFtViZ TAk4dqypbT7ByH8wqfGVvw8RJqgB6h8+vLHDs/hUOxruZovJI1poti6uPrfa wSAx+4FZWF; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: neil.2.harrison@bt.com, pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? 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, 01 Apr 2009 16:39:47 -0000 Sorry I misread the subject line - that's the problem with having two drafts running in parallel :) Pkt PW may apply to MPLS-TP that is a MEAD team call. Fat PW I assume is only applicable to classic. The only way that I can see to do LAG in a transport context is to do pw-bonding, otherwise you violate the ordering. Sorry for any confusion. Stewart BUSI ITALO wrote: > Stewart, > > Could you please clarify the applicability of Fat PW to MPLS-TP? > > In SF, you stated that they are applicable to "ECMP and LAG case" and > this matched with my understanding of the draft. > > Due to the fact that ECMP is not used in MPLS-TP, I had assumed this > draft is not applicable in MPLS-TP. > > Did I miss/misunderstand anything? > > Thanks, Italo > > >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On >> Behalf Of Stewart Bryant >> Sent: Wednesday, April 01, 2009 12:55 PM >> To: neil.2.harrison@bt.com >> Cc: pwe3@ietf.org >> Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? >> >> The draft has applicability to Transport. >> >> I will come to the details below in a minute, but tell me how you >> propose to cope with >> ESSM in a client - surely you need to intervene rather than >> carry them >> transparently? >> >> Remember that the client layer performs the classification >> into protocol >> types >> so we just carry the classification over the server layer in a more >> convenient way. >> >> Remember if you don't like the pkt-pw you can always put a >> real interface in >> and use a L2 pw, and if you don't like that you can always >> but a clear >> fibre. What you do depends on how you wish to run the economics. >> >> >> >> neil.2.harrison@bt.com wrote: >> >>> Stewart, can I please ask if this draft would be applicable >>> >> to MPLS-TP? >> >>> >>> I ask this because a transport network should satisfy the >>> >> requirements >> >>> of transparency....which in brief means: >>> >>> - all client bits treated equally >>> >> That happens here >> >>> - client bit ordering preserved >>> >> That also happens here >> >>> - no attempt made to try understand semantics of client >>> >> symbols (ie >> >>> client message/traffic-unit formed from N client bits) and never >>> change client bits >>> >> In this mechanism it is the client layer that makes the changes - not >> the server layer. The client presents the packet and and >> metadata saying >> what pid the server is to write into the PID >> >>> - server ensures client X traffic behaviour cannot impact >>> performance experienced by client Y >>> >> We pass that test >> >>> >>> ...and I cannot reconcile this with this draft. So perhaps >>> >> this draft >> >>> is only intended to apply to 'classical' MPLS? >>> >> It's not clear that it fails the test when you realize that >> the client >> is presenting the modified data to the server. >> >> Stewart >> >> >>> >>> regards, Neil >>> >>> >>> >> -------------------------------------------------------------- >> ---------- >> >>> *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On >>> Behalf Of *BOCCI Matthew >>> *Sent:* 31 March 2009 12:51 >>> *To:* pwe3@ietf.org >>> *Subject:* [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? >>> >>> This is the start of a two week poll to judge the consensus to >>> move draft-bryant-filsfils-fat-pw-03 >>> to a PWE3 Working Group draft. >>> >>> Please can you respond to the PWE3 list with your approval (or >>> otherwise). >>> >>> This poll will close on 14th April 2009. >>> >>> Regards >>> >>> Matthew >>> >>> >>> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> >> > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > From neil.2.harrison@bt.com Wed Apr 1 09:49:59 2009 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 983133A6949 for ; Wed, 1 Apr 2009 09:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, 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 S4MDl8MKqdNr for ; Wed, 1 Apr 2009 09:49:58 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 04B193A6842 for ; Wed, 1 Apr 2009 09:49:57 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 17:50:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Apr 2009 17:51:13 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C045D56AC@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <49D39892.9060808@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? Thread-Index: Acmy6FvmIRBFidGJQ6G/yIp595y+mgAAW6sA From: To: , X-OriginalArrivalTime: 01 Apr 2009 16:50:57.0414 (UTC) FILETIME=[07779A60:01C9B2EA] Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 16:49:59 -0000 Thanks Stewart.... > Fat PW I assume is only applicable to classic.=20 That certainly clears up a key concern I had with FAT PWs and MPLS-TP. regards, Neil > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com]=20 > Sent: 01 April 2009 17:39 > To: BUSI ITALO > Cc: Harrison,N,Neil,CXM R; pwe3@ietf.org > Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? >=20 > Sorry I misread the subject line - that's the problem with having > two drafts running in parallel :) >=20 > Pkt PW may apply to MPLS-TP that is a MEAD team call. >=20 > Fat PW I assume is only applicable to classic. The only way that > I can see to do LAG in a transport context is to do=20 > pw-bonding, otherwise > you violate the ordering. >=20 > Sorry for any confusion. >=20 > Stewart >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > BUSI ITALO wrote: > > Stewart, > > > > Could you please clarify the applicability of Fat PW to MPLS-TP? > > > > In SF, you stated that they are applicable to "ECMP and LAG=20 > case" and > > this matched with my understanding of the draft. > > > > Due to the fact that ECMP is not used in MPLS-TP, I had assumed this > > draft is not applicable in MPLS-TP. > > > > Did I miss/misunderstand anything? > > > > Thanks, Italo > > > > =20 > >> -----Original Message----- > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > >> Behalf Of Stewart Bryant > >> Sent: Wednesday, April 01, 2009 12:55 PM > >> To: neil.2.harrison@bt.com > >> Cc: pwe3@ietf.org > >> Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? > >> > >> The draft has applicability to Transport. > >> > >> I will come to the details below in a minute, but tell me how you=20 > >> propose to cope with > >> ESSM in a client - surely you need to intervene rather than=20 > >> carry them=20 > >> transparently? > >> > >> Remember that the client layer performs the classification=20 > >> into protocol=20 > >> types > >> so we just carry the classification over the server layer=20 > in a more=20 > >> convenient way. > >> > >> Remember if you don't like the pkt-pw you can always put a=20 > >> real interface in > >> and use a L2 pw, and if you don't like that you can always=20 > >> but a clear > >> fibre. What you do depends on how you wish to run the economics. > >> > >> > >> > >> neil.2.harrison@bt.com wrote: > >> =20 > >>> Stewart, can I please ask if this draft would be applicable=20 > >>> =20 > >> to MPLS-TP? > >> =20 > >>> =20 > >>> I ask this because a transport network should satisfy the=20 > >>> =20 > >> requirements=20 > >> =20 > >>> of transparency....which in brief means: > >>> =20 > >>> - all client bits treated equally > >>> =20 > >> That happens here > >> =20 > >>> - client bit ordering preserved > >>> =20 > >> That also happens here > >> =20 > >>> - no attempt made to try understand semantics of client=20 > >>> =20 > >> symbols (ie=20 > >> =20 > >>> client message/traffic-unit formed from N client bits) and never=20 > >>> change client bits > >>> =20 > >> In this mechanism it is the client layer that makes the=20 > changes - not=20 > >> the server layer. The client presents the packet and and=20 > >> metadata saying=20 > >> what pid the server is to write into the PID > >> =20 > >>> - server ensures client X traffic behaviour cannot impact=20 > >>> performance experienced by client Y > >>> =20 > >> We pass that test > >> =20 > >>> =20 > >>> ...and I cannot reconcile this with this draft. So perhaps=20 > >>> =20 > >> this draft=20 > >> =20 > >>> is only intended to apply to 'classical' MPLS? > >>> =20 > >> It's not clear that it fails the test when you realize that=20 > >> the client=20 > >> is presenting the modified data to the server. > >> > >> Stewart > >> > >> =20 > >>> =20 > >>> regards, Neil > >>> > >>> =20 > >>> =20 > >> -------------------------------------------------------------- > >> ---------- > >> =20 > >>> *From:* pwe3-bounces@ietf.org=20 > [mailto:pwe3-bounces@ietf.org] *On > >>> Behalf Of *BOCCI Matthew > >>> *Sent:* 31 March 2009 12:51 > >>> *To:* pwe3@ietf.org > >>> *Subject:* [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? > >>> > >>> This is the start of a two week poll to judge the consensus to > >>> move draft-bryant-filsfils-fat-pw-03 > >>> to a PWE3 Working Group draft. > >>> > >>> Please can you respond to the PWE3 list with your approval (or > >>> otherwise). > >>> > >>> This poll will close on 14th April 2009. > >>> > >>> Regards > >>> > >>> Matthew > >>> > >>> > >>> =20 > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www.ietf.org/mailman/listinfo/pwe3 > >> > >> =20 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > =20 >=20 >=20 From yaakov_s@rad.com Wed Apr 1 10:40:04 2009 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 BF51A3A6A1D for ; Wed, 1 Apr 2009 10:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.464, 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 wHgqpDFAco-r for ; Wed, 1 Apr 2009 10:40:02 -0700 (PDT) Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id 61B183A6829 for ; Wed, 1 Apr 2009 10:40:01 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 01 Apr 2009 20:41:01 +0300 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Wed, 1 Apr 2009 20:41:00 +0300 From: Yaakov Stein To: BOCCI Matthew , "pwe3@ietf.org" Date: Wed, 1 Apr 2009 20:40:59 +0300 Thread-Topic: draft-bryant-filsfils-fat-pw-03 to WG draft? Thread-Index: Acmx9uZY0mmoKvLIT1OqXckF2OpOJgA+DeCQ Message-ID: <424CDC689E5CEF4D9FEADE56A378D922021B07BAA9@exrad4.ad.rad.co.il> References: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.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_424CDC689E5CEF4D9FEADE56A378D922021B07BAA9exrad4adradco_" MIME-Version: 1.0 Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:40:04 -0000 --_000_424CDC689E5CEF4D9FEADE56A378D922021B07BAA9exrad4adradco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support the moving of the draft to WG status, and hope that this move will be the stimulus to put more work into it. Section 2, although describing an NSP, could benefit from a few simple exam= ples. The first paragraph of the intro mentions SAToP, but there is nowhere any discussion of what the mechanism does to packet interarrival times. The discussion of section 6.3 seems rather bloated and uninformative to me (as the mechanism basically can not handle the single fat flow case). Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOC= CI Matthew Sent: Tuesday, March 31, 2009 14:51 To: pwe3@ietf.org Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? This is the start of a two week poll to judge the consensus to move draft-b= ryant-filsfils-fat-pw-03 to a PWE3 Working Group draft. Please can you respond to the PWE3 list with your approval (or otherwise). This poll will close on 14th April 2009. Regards Matthew --_000_424CDC689E5CEF4D9FEADE56A378D922021B07BAA9exrad4adradco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-bryant-filsfils-fat-pw-03 to WG draft?

I support the moving of the draft to WG status,

and hope that this move will be the stimulus to  put mo= re work into it.

 

Section 2, although describing an NSP, could benefit from a = few simple examples.

 

The first paragraph of the intro mentions SAToP,<= /span>

but there is nowhere any discussion of what the mechanism

does to packet interarrival times.

 

The discussion of section 6.3 seems rather bloated and uninf= ormative to me

(as the mechanism basically can not handle the single fat fl= ow case).

 

Y(J)S

 

 

 

 

 

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BO= CCI Matthew
Sent: Tuesday, March 31, 2009 14:51
To: pwe3@ietf.org
Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?

 

This i= s the start of a two week poll to judge the consensus to move draft-bryant-filsfils-fat-pw-03
 to = a PWE3 Working Group draft.

Please= can you respond to the PWE3 list with your approval (or otherwise).

This p= oll will close on 14th April 2009.

Regard= s

Matthe= w

 

--_000_424CDC689E5CEF4D9FEADE56A378D922021B07BAA9exrad4adradco_-- From yaakov_s@rad.com Wed Apr 1 10:49:53 2009 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 43F9C3A689B for ; Wed, 1 Apr 2009 10:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.446, 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 xdxV9zzO2fuf for ; Wed, 1 Apr 2009 10:49:51 -0700 (PDT) Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id 6E7EE3A6DE8 for ; Wed, 1 Apr 2009 10:48:39 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 01 Apr 2009 20:49:38 +0300 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Wed, 1 Apr 2009 20:49:38 +0300 From: Yaakov Stein To: "pwe3@ietf.org" Date: Wed, 1 Apr 2009 20:49:37 +0300 Thread-Topic: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? Thread-Index: AcmyCwBBWRaHHSAhS2mypCO0ESnGzQA5i0QA Message-ID: <424CDC689E5CEF4D9FEADE56A378D922021B07BAAB@exrad4.ad.rad.co.il> References: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.com> <787be2780903310714x27eb62ccs3378efee8b2d1a2a@mail.gmail.com> In-Reply-To: <787be2780903310714x27eb62ccs3378efee8b2d1a2a@mail.gmail.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_424CDC689E5CEF4D9FEADE56A378D922021B07BAABexrad4adradco_" MIME-Version: 1.0 Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 17:49:53 -0000 --_000_424CDC689E5CEF4D9FEADE56A378D922021B07BAABexrad4adradco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support, but strongly do NOT support the name. "packet PW" does not mean anything to me. Do the other encaps not transport= packets ? Does this one only transport packets (and not e.g., frames?) How about "interface traffic PW" or "generic traffic PW" ? The latter name "generic PW" was the name that was used when this same idea was described a few years ago (see to lock onto the thread http://www.ietf.org/mail-archive/web/pwe3/curr= ent/msg08070.html ) Y(J)S 2009/3/31 BOCCI Matthew > This is the start of a two week poll to judge the consensus to move draft-b= ryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft. Please can you respond, *to the PWE3 list only*, with your approval (or oth= erwise). This poll will close on 14th April 2009. Regards Matthew _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_424CDC689E5CEF4D9FEADE56A378D922021B07BAABexrad4adradco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support, but strongly = do NOT support the name.

 =

"packet PW" do= es not mean anything to me. Do the other encaps not transport packets ?=

Does this one only trans= port packets (and not e.g., frames?)

 =

How about "interfac= e traffic PW" or "generic traffic PW" ?

 =

The latter name "ge= neric PW" was the name that was used

when this same idea was described a few years ago

(see to lock onto the th= read ht= tp://www.ietf.org/mail-archive/web/pwe3/current/msg08070.html )

 =

Y(J)S<= /p>

 =

 =

2009/3/31 BOCCI Matthew <Matthew.Bocci@alcatel-luce= nt.com>

This i= s the start of a two week poll to judge the consensus to move draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft.

Please= can you respond, *to the PWE3 list only*, with your approval (or otherwise).

This p= oll will close on 14th April 2009.

Regard= s

Matthe= w

 


_______________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3

 

--_000_424CDC689E5CEF4D9FEADE56A378D922021B07BAABexrad4adradco_-- From John.E.Drake2@boeing.com Wed Apr 1 11:12:29 2009 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 A9B983A68E5 for ; Wed, 1 Apr 2009 11:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.583 X-Spam-Level: X-Spam-Status: No, score=-5.583 tagged_above=-999 required=5 tests=[AWL=1.016, 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 bJeEhZw0b-KC for ; Wed, 1 Apr 2009 11:12:29 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 07D2E3A67E3 for ; Wed, 1 Apr 2009 11:12:29 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n31IDRNa009933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Apr 2009 11:13:27 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n31IDQU9018513 for ; Wed, 1 Apr 2009 11:13:27 -0700 (PDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n31IDP3B018416 for ; Wed, 1 Apr 2009 11:13:26 -0700 (PDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 11:12:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Apr 2009 11:12:47 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01979B1C@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? Thread-Index: Acmx+FcP5L7TrJafSfatI2vSUDObcAA/QntA References: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.com> From: "Drake, John E" To: X-OriginalArrivalTime: 01 Apr 2009 18:12:49.0843 (UTC) FILETIME=[7780C830:01C9B2F5] Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 18:12:29 -0000 No > -----Original Message----- > From: BOCCI Matthew [mailto:Matthew.Bocci@alcatel-lucent.com]=20 > Sent: Tuesday, March 31, 2009 5:01 AM > To: pwe3@ietf.org > Cc: mpls-tp@ietf.org > Subject: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? >=20 > This is the start of a two week poll to judge the consensus=20 > to move draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working=20 > Group draft. >=20 > Please can you respond, *to the PWE3 list only*, with your=20 > approval (or otherwise).=20 >=20 > This poll will close on 14th April 2009.=20 >=20 > Regards=20 >=20 > Matthew=20 >=20 >=20 >=20 >=20 From Florin.Balus@alcatel-lucent.com Wed Apr 1 11:13:27 2009 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 BC9183A68E5 for ; Wed, 1 Apr 2009 11:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 whrMZ0XViN+a for ; Wed, 1 Apr 2009 11:13:24 -0700 (PDT) Received: from audl953.usa.alcatel.com (audl953.usa.alcatel.com [143.209.238.162]) by core3.amsl.com (Postfix) with ESMTP id 04BD73A6829 for ; Wed, 1 Apr 2009 11:13:23 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id n31IEOdc009951 for ; Wed, 1 Apr 2009 12:14:24 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 13:14:23 -0500 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_01C9B2F5.AECFA227" Date: Wed, 1 Apr 2009 13:14:10 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B0549A678@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? thread-index: Acmx9uZY0mmoKvLIT1OqXckF2OpOJgA/rqqg References: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> From: "BALUS Florin" To: "BOCCI Matthew" , X-OriginalArrivalTime: 01 Apr 2009 18:14:23.0797 (UTC) FILETIME=[AF810650:01C9B2F5] X-Scanned-By: MIMEDefang 2.64 on 143.209.238.34 Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 18:13:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B2F5.AECFA227 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: Tuesday, March 31, 2009 4:51 AM To: pwe3@ietf.org Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? =20 This is the start of a two week poll to judge the consensus to move draft-bryant-filsfils-fat-pw-03=20 to a PWE3 Working Group draft.=20 Please can you respond to the PWE3 list with your approval (or otherwise).=20 This poll will close on 14th April 2009.=20 Regards=20 Matthew=20 =20 ------_=_NextPart_001_01C9B2F5.AECFA227 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-bryant-filsfils-fat-pw-03 to WG draft?

Support.

 

From:= pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = BOCCI Matthew
Sent: Tuesday, March 31, 2009 4:51 AM
To: pwe3@ietf.org
Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG = draft?

 

This is the start of a two week poll to judge the consensus to move draft-bryant-filsfils-fat-pw-03
 to a = PWE3 Working Group draft.

Please can you respond to the PWE3 list with your approval (or otherwise). =

This poll will close on 14th April 2009.

Regards

Matthew

 

------_=_NextPart_001_01C9B2F5.AECFA227-- From Florin.Balus@alcatel-lucent.com Wed Apr 1 11:15:18 2009 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 9B96B3A6AB5; Wed, 1 Apr 2009 11:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 jhQsHEXjlK5q; Wed, 1 Apr 2009 11:15:17 -0700 (PDT) Received: from audl951.usa.alcatel.com (audl951.usa.alcatel.com [143.209.238.161]) by core3.amsl.com (Postfix) with ESMTP id AC9683A67F7; Wed, 1 Apr 2009 11:15:17 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id n31IG3XC014593; Wed, 1 Apr 2009 12:16:18 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 13:16:13 -0500 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_01C9B2F5.F0677435" Date: Wed, 1 Apr 2009 13:16:00 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B0549A679@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? thread-index: Acmx+FcP5L7TrJafSfatI2vSUDObcAA/YvVw References: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.com> From: "BALUS Florin" To: "BOCCI Matthew" , X-OriginalArrivalTime: 01 Apr 2009 18:16:13.0172 (UTC) FILETIME=[F0B25340:01C9B2F5] X-Scanned-By: MIMEDefang 2.64 on 143.209.238.34 Cc: mpls-tp@ietf.org Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 18:15:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B2F5.F0677435 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. =20 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: Tuesday, March 31, 2009 5:01 AM To: pwe3@ietf.org Cc: mpls-tp@ietf.org Subject: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? =20 This is the start of a two week poll to judge the consensus to move draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft. Please can you respond, *to the PWE3 list only*, with your approval (or otherwise).=20 This poll will close on 14th April 2009.=20 Regards=20 Matthew=20 =20 ------_=_NextPart_001_01C9B2F5.F0677435 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-bryant-pwe3-packet-pw-00.txt to WG draft?

Support.

 

From:= pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = BOCCI Matthew
Sent: Tuesday, March 31, 2009 5:01 AM
To: pwe3@ietf.org
Cc: mpls-tp@ietf.org
Subject: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG = draft?

 

This is the start of a two week poll to judge the consensus to move draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group = draft.

Please can you respond, *to the PWE3 list only*, with your approval (or = otherwise).

This poll will close on 14th April 2009.

Regards

Matthew

 

------_=_NextPart_001_01C9B2F5.F0677435-- From neil.2.harrison@bt.com Wed Apr 1 11:40:21 2009 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 C24213A6A6C for ; Wed, 1 Apr 2009 11:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.152, 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 QC4dJadIbeJU for ; Wed, 1 Apr 2009 11:40:20 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id E6B203A67F7 for ; Wed, 1 Apr 2009 11:40:19 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Apr 2009 19:41:19 +0100 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_01C9B2F9.71E0322D" Date: Wed, 1 Apr 2009 19:41:49 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C045D570A@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] draft-bryant-pwe3-packet-pw-00.txt to WG draft? Thread-Index: Acmx+FcP5L7TrJafSfatI2vSUDObcAA8hKLw From: To: , X-OriginalArrivalTime: 01 Apr 2009 18:41:19.0358 (UTC) FILETIME=[727411E0:01C9B2F9] Subject: Re: [PWE3] [mpls-tp] draft-bryant-pwe3-packet-pw-00.txt to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 18:40:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B2F9.71E0322D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Matthew, =20 I am not clear why responses should only be sent to PWE3 as this draft seems most germane to MPLS-TP. =20 I support the concept of adding a PID field to MPLS-TP (though I think there are better ways to to this) but I am not sure how useful this is to existing MPLS deployments. ....so I am a little unclear as to what we are voting for here, ie classic MPLS or MPLS-TP? *This point needs clarifying.*=20 =20 My further observations are specifically for the case of applying this new DP structure to MPLS-TP.....but I accept that these observation may not be applicable if there is no intention to apply this draft to MPLS-TP (but then this begs the question of what MPLS-TP adaptation will look like?) =20 =20 1 The opening sentence of the Introduction says: "There is a need to provide a method of carrying a packet service over an MPLS PSN in a way that provides isolation between the two networks. " =20 I agree with this. And an important case is MPLS(TP)overMPLS-TP. I also think that in addition to client/server *functional separation* the server should be providing a *transparent transport service* to the client, if the server is supposed to be fulfilling a transport network role. =20 However I have a problem with what it says later in the Introduction about this same point: "A further consideration is that two adjacent MPLS LSRs do not simply exchange MPLS packets. They exchange IP packets for adjacency formation, control, routing, label exchange, management and monitoring purposes. In addition they may exchange data-link packets as part of routing (e.g. IS-IS hellos and IS-IS LSPs) and for OAM purposes (e.g. Cisco Discovery Protocol). Thus the two clients require an attachment mechanism that can be used to multiplex a number of protocols. In addition it is essential to the correct operation of the network layer that all of these protocols fate share. Where the client LSRs and server PEs are co-located in the same equipment the data-link layer can be simplified to a simple protocol identifier (PID) that is used to multiplex the various data-link types onto a pseudowire. This is the method that described in this document." =20 The whole point of a client/server relationship is to accomodate distinct layer networks (and hence distinct equipment) owned by differrent operating parties. So to place a restriction that the new DP format of using the PID can only be used when the client and server MPLS layer networks are co-resident in the same equipment kind-of defeats the whole purpose of what is said in the opening sentence of the Introduction IMO. =20 I don't see why we can't have a p2p server layer (the 'data-link' mentioned above) that fully terminates on the client and server MPLS nodes....indeed this is the key case to address IMO. Further, we should not place an undue restriction on what the technology used here (for this 'data-link'). It could be Ethernet or it could be SDH (using GFP adaptation to identify the client as MPLS) and it should be able to be different on each client/server end. =20 =20 2 If we are using the PID with MPLS-TP...where I am assuming the intention is to produce a transport network like behaviour......then we can make these observations: =20 - We should not have ECMP in MPLS-TP.......therefore the 1st nibble value 0000 of the CW is redundant. =20 - A transport network must preserve the sequence ordering of client symbol information.....therefore the Sequence Number field of the CW is redundant. =20 I can understand why these are required in 'classic' MPLS but we should note that if this DP format is used with MPLS-TP these fields are redundant and should be set to something like all 0s. More generally of course, we perhaps should even question whether we need the CW in MPLS-TP, as it is not offering any useful adaptation functions at all.....indeed we can observe that if the PID always followed the S=3D1 header case this ought to work fine in MPLS-TP (which is essentially what John Drake and I were proposing should be considered). =20 regards, Neil =20 ------_=_NextPart_001_01C9B2F9.71E0322D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-bryant-pwe3-packet-pw-00.txt to WG = draft?
Matthew,
 
 I am not clear why responses should = only be sent=20 to PWE3 as this draft seems most germane to MPLS-TP.
 
I support the concept of adding a PID field = to MPLS-TP=20 (though I think there are better ways to to this) but I am not sure how = useful=20 this is to existing MPLS deployments. ....so I am a little unclear = as to=20 what we are voting for here, ie classic MPLS or MPLS-TP?  *This = point needs=20 clarifying.* 
 
My further observations are specifically for = the case=20 of applying this new DP structure to MPLS-TP.....but I accept that these = observation may not be applicable if there is no intention to apply this = draft=20 to MPLS-TP (but then this begs the question of what MPLS-TP adaptation = will look=20 like?)
 
 
1    The opening sentence of = the=20 Introduction says:
"There is=20 a need to provide a method of carrying a packet service over an = MPLS PSN in=20 a way that provides isolation between the two networks.=20 "
 
I agree with this.  And an important = case is=20 MPLS(TP)overMPLS-TP.  I also think that in addition to = client/server=20 *functional separation* the server should be providing a *transparent = transport=20 service* to the client, if the server is supposed to be fulfilling a = transport=20 network role.
 
However I have a problem with what it says = later in the=20 Introduction about this same point:
"A=20 further consideration is that two adjacent MPLS LSRs do not = simply exchange=20 MPLS packets.  They exchange IP packets for = adjacency formation,=20 control, routing, label exchange, management and  monitoring=20 purposes.  In addition they may exchange data-link packets as = part of=20 routing (e.g.  IS-IS hellos and IS-IS LSPs) and for = OAM purposes=20 (e.g.  Cisco Discovery Protocol).  Thus the two = clients require=20 an attachment mechanism that can be used to multiplex a number of=20 protocols.  In addition it is essential to the = correct operation of=20 the network layer that all of these protocols = fate share.

Where the=20 client LSRs and server PEs are co-located in the same equipment the = data-link layer can be simplified to a simple protocol identifier (PID) = that is=20 used to multiplex the various data-link types onto a = pseudowire.  This=20 is the method that described in=20 this document.
"
 
The whole point of a client/server = relationship is to=20 accomodate distinct layer networks (and hence distinct equipment) owned = by=20 differrent operating parties.  So to place a restriction that the = new DP=20 format of using the PID can only be used when the client and server = MPLS=20 layer networks are co-resident in the same equipment kind-of defeats the = whole=20 purpose of what is said in the opening sentence of the Introduction=20 IMO.
 
I don't see why we can't have a p2p server = layer (the=20 'data-link' mentioned above) that fully terminates on the client and = server MPLS=20 nodes....indeed this is the key case to address IMO.  Further, we = should=20 not place an undue restriction on what the technology used here = (for this=20 'data-link').  It could be Ethernet or it could be SDH (using GFP=20 adaptation to identify the client as MPLS) and it should be able to be = different=20 on each client/server end.
 
 
2    If we are using the PID = with=20 MPLS-TP...where I am assuming the intention is to produce a transport = network=20 like behaviour......then we can make these = observations:
 
-    We should not have ECMP = in=20 MPLS-TP.......therefore the 1st nibble value 0000 of the CW is=20 redundant.
 
-    A transport network must = preserve=20 the sequence ordering of client symbol information.....therefore the = Sequence=20 Number field of the CW is redundant.
 
I can understand why these are required in = 'classic'=20 MPLS but we should note that if this DP format is used with MPLS-TP = these fields=20 are redundant and should be set to something like all 0s.   = More=20 generally of course, we perhaps should even question whether we need the = CW in=20 MPLS-TP, as it is not offering any useful adaptation functions at = all.....indeed=20 we can observe that if the PID always followed the S=3D1 header case = this ought to=20 work fine in MPLS-TP (which is essentially what John Drake and I were = proposing=20 should be considered).
 
regards, Neil
 
------_=_NextPart_001_01C9B2F9.71E0322D-- From John.E.Drake2@boeing.com Wed Apr 1 12:09:24 2009 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 2B4CB3A6911 for ; Wed, 1 Apr 2009 12:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.629 X-Spam-Level: X-Spam-Status: No, score=-5.629 tagged_above=-999 required=5 tests=[AWL=0.970, 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 f-VoqSA2nIeA for ; Wed, 1 Apr 2009 12:09:23 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 220AF3A6838 for ; Wed, 1 Apr 2009 12:09:23 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n31JAGni003937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 1 Apr 2009 14:10:16 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n31JAFwh026938 for ; Wed, 1 Apr 2009 14:10:15 -0500 (CDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n31JABW2026777 for ; Wed, 1 Apr 2009 14:10:15 -0500 (CDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 12:10:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Apr 2009 12:10:13 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01979B5A@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C045D570A@E03MVB2-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] [mpls-tp] draft-bryant-pwe3-packet-pw-00.txt to WG draft? Thread-Index: Acmx+FcP5L7TrJafSfatI2vSUDObcAA8hKLwAATB+PA= References: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.com> <2ECAA42C79676B42AEBAC11229CA7D0C045D570A@E03MVB2-UKBR.domain1.systemhost.net> From: "Drake, John E" To: X-OriginalArrivalTime: 01 Apr 2009 19:10:14.0743 (UTC) FILETIME=[7CD2CE70:01C9B2FD] Subject: Re: [PWE3] [mpls-tp] draft-bryant-pwe3-packet-pw-00.txt to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 19:09:24 -0000 +1=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > Sent: Wednesday, April 01, 2009 11:42 AM > To: Matthew.Bocci@alcatel-lucent.com; pwe3@ietf.org > Subject: Re: [PWE3] [mpls-tp]=20 > draft-bryant-pwe3-packet-pw-00.txt to WG draft? >=20 > Matthew, > =20 > I am not clear why responses should only be sent to PWE3 as=20 > this draft seems most germane to MPLS-TP. > =20 > I support the concept of adding a PID field to MPLS-TP=20 > (though I think there are better ways to to this) but I am=20 > not sure how useful this is to existing MPLS deployments.=20 > ....so I am a little unclear as to what we are voting for=20 > here, ie classic MPLS or MPLS-TP? *This point needs clarifying.*=20 > =20 > My further observations are specifically for the case of=20 > applying this new DP structure to MPLS-TP.....but I accept=20 > that these observation may not be applicable if there is no=20 > intention to apply this draft to MPLS-TP (but then this begs=20 > the question of what MPLS-TP adaptation will look like?) > =20 > =20 > 1 The opening sentence of the Introduction says: > "There is a need to provide a method of carrying a packet=20 > service over an MPLS PSN in a way that provides isolation=20 > between the two networks. " > =20 > I agree with this. And an important case is=20 > MPLS(TP)overMPLS-TP. I also think that in addition to=20 > client/server *functional separation* the server should be=20 > providing a *transparent transport service* to the client, if=20 > the server is supposed to be fulfilling a transport network role. > =20 > However I have a problem with what it says later in the=20 > Introduction about this same point: > "A further consideration is that two adjacent MPLS LSRs do=20 > not simply exchange MPLS packets. They exchange IP packets=20 > for adjacency formation, control, routing, label exchange,=20 > management and monitoring purposes. In addition they may=20 > exchange data-link packets as part of routing (e.g. IS-IS=20 > hellos and IS-IS LSPs) and for OAM purposes (e.g. Cisco=20 > Discovery Protocol). Thus the two clients require an=20 > attachment mechanism that can be used to multiplex a number=20 > of protocols. In addition it is essential to the correct=20 > operation of the network layer that all of these protocols fate share. >=20 > Where the client LSRs and server PEs are co-located in the=20 > same equipment the data-link layer can be simplified to a=20 > simple protocol identifier (PID) that is used to multiplex=20 > the various data-link types onto a pseudowire. This is the=20 > method that described in this document." > =20 > The whole point of a client/server relationship is to=20 > accomodate distinct layer networks (and hence distinct=20 > equipment) owned by differrent operating parties. So to=20 > place a restriction that the new DP format of using the PID=20 > can only be used when the client and server MPLS layer=20 > networks are co-resident in the same equipment kind-of=20 > defeats the whole purpose of what is said in the opening=20 > sentence of the Introduction IMO. > =20 > I don't see why we can't have a p2p server layer (the=20 > 'data-link' mentioned above) that fully terminates on the=20 > client and server MPLS nodes....indeed this is the key case=20 > to address IMO. Further, we should not place an undue=20 > restriction on what the technology used here (for this=20 > 'data-link'). It could be Ethernet or it could be SDH (using=20 > GFP adaptation to identify the client as MPLS) and it should=20 > be able to be different on each client/server end. > =20 > =20 > 2 If we are using the PID with MPLS-TP...where I am=20 > assuming the intention is to produce a transport network like=20 > behaviour......then we can make these observations: > =20 > - We should not have ECMP in MPLS-TP.......therefore the=20 > 1st nibble value 0000 of the CW is redundant. > =20 > - A transport network must preserve the sequence ordering=20 > of client symbol information.....therefore the Sequence=20 > Number field of the CW is redundant. > =20 > I can understand why these are required in 'classic' MPLS but=20 > we should note that if this DP format is used with MPLS-TP=20 > these fields are redundant and should be set to something=20 > like all 0s. More generally of course, we perhaps should=20 > even question whether we need the CW in MPLS-TP, as it is not=20 > offering any useful adaptation functions at all.....indeed we=20 > can observe that if the PID always followed the S=3D1 header=20 > case this ought to work fine in MPLS-TP (which is essentially=20 > what John Drake and I were proposing should be considered). > =20 > regards, Neil > =20 >=20 From rmanur@broadcom.com Wed Apr 1 13:51:57 2009 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 4DBFB3A6B22 for ; Wed, 1 Apr 2009 13:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 4-W5n+H+MOst for ; Wed, 1 Apr 2009 13:51:56 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 7F51A3A692A for ; Wed, 1 Apr 2009 13:51:56 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 01 Apr 2009 13:52:41 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Wed, 1 Apr 2009 13:52:41 -0700 From: "Rajeev Manur" To: "BOCCI Matthew" , "pwe3@ietf.org" Date: Wed, 1 Apr 2009 13:53:57 -0700 Thread-Topic: draft-bryant-filsfils-fat-pw-03 to WG draft? Thread-Index: Acmx9uZY0mmoKvLIT1OqXckF2OpOJgBEk7TA Message-ID: References: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 65CD0B935Y813859622-01-01 Content-Type: multipart/alternative; boundary=_000_FD96C117992C584DBC47231B1EB6F55649F0C842CFSJEXCHCCR02co_ Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 20:51:57 -0000 --_000_FD96C117992C584DBC47231B1EB6F55649F0C842CFSJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Support. --Rajeev Manur ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOC= CI Matthew Sent: Tuesday, March 31, 2009 4:51 AM To: pwe3@ietf.org Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? This is the start of a two week poll to judge the consensus to move draft-b= ryant-filsfils-fat-pw-03 to a PWE3 Working Group draft. Please can you respond to the PWE3 list with your approval (or otherwise). This poll will close on 14th April 2009. Regards Matthew --_000_FD96C117992C584DBC47231B1EB6F55649F0C842CFSJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable draft-bryant-filsfils-fat-pw-03 to WG draft?
Support.
 <= /DIV>
--Rajeev Manur
 
 <= /DIV>

From:=20 pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BO= CCI=20 Matthew
Sent: Tuesday, March 31, 2009 4:51 AM
To:=20 pwe3@ietf.org
Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to = WG=20 draft?

This is the start of a two week poll to judg= e the=20 consensus to move draft-bryant-filsfils-fat-pw-03
 to a PWE3 Working Group draft.

Please can you respond to the PWE3 list with= your=20 approval (or otherwise).

This poll will close on 14th April 2009.

Regards

Matthew


--_000_FD96C117992C584DBC47231B1EB6F55649F0C842CFSJEXCHCCR02co_-- From pdutta@alcatel-lucent.com Wed Apr 1 15:59:58 2009 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 410743A6A5A; Wed, 1 Apr 2009 15:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 maeYM-ASIsJq; Wed, 1 Apr 2009 15:59:57 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 2F6B53A6829; Wed, 1 Apr 2009 15:59:56 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n31N0t15027999 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 2 Apr 2009 01:00:55 +0200 Received: from INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Apr 2009 01:00:55 +0200 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 2 Apr 2009 04:30:53 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Date: Thu, 2 Apr 2009 04:30:47 +0530 Thread-Topic: draft-bryant-pwe3-packet-pw-00.txt to WG draft? Thread-Index: Acmx+FcP5L7TrJafSfatI2vSUDObcABJVivQ Message-ID: References: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.com> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.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_C584046466ED224CA92C1BC3313B963E0358E74284INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "mpls-tp@ietf.org" Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 22:59:58 -0000 --_000_C584046466ED224CA92C1BC3313B963E0358E74284INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOC= CI Matthew Sent: Tuesday, March 31, 2009 5:01 AM To: pwe3@ietf.org Cc: mpls-tp@ietf.org Subject: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? This is the start of a two week poll to judge the consensus to move draft-b= ryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft. Please can you respond, *to the PWE3 list only*, with your approval (or oth= erwise). This poll will close on 14th April 2009. Regards Matthew --_000_C584046466ED224CA92C1BC3313B963E0358E74284INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-bryant-pwe3-packet-pw-00.txt to WG draft?

Support

 


From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI Matthew
Sent: Tuesday, March 31, 200= 9 5:01 AM
To: pwe3@ietf.org
Cc: mpls-tp@ietf.org
Subject: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?

 

This is the start of a two week poll to judge the consensus to move draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft.

Please can you respond, *to the PWE3 list only*, with your approval (or otherwise)= .

This poll will close on 14th April 2009.

Regards

Matthew

 =

--_000_C584046466ED224CA92C1BC3313B963E0358E74284INBANSXCHMBSA_-- From jiang.xiaowei@zte.com.cn Wed Apr 1 18:48:38 2009 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 9E70D3A685D; Wed, 1 Apr 2009 18:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.756 X-Spam-Level: X-Spam-Status: No, score=-96.756 tagged_above=-999 required=5 tests=[AWL=0.879, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 AeaXdbiKpm4E; Wed, 1 Apr 2009 18:48:37 -0700 (PDT) Received: from out1.zte.com.cn (out1.zte.com.cn [202.103.147.172]) by core3.amsl.com (Postfix) with ESMTP id B48EE3A6A61; Wed, 1 Apr 2009 18:48:33 -0700 (PDT) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 29444.5993761570; Thu, 2 Apr 2009 09:46:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n321nYrC001052; Thu, 2 Apr 2009 09:49:34 +0800 (CST) (envelope-from jiang.xiaowei@zte.com.cn) In-Reply-To: <424CDC689E5CEF4D9FEADE56A378D922021B07BAA9@exrad4.ad.rad.co.il> To: yaakov_s@rad.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: jiang.xiaowei@zte.com.cn Date: Thu, 2 Apr 2009 09:49:24 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-02 09:49:44, Serialize by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-02 09:49:44, Serialize complete at 2009-04-02 09:49:44, S/MIME Sign failed at 2009-04-02 09:49:44: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-02 09:49:28, Serialize complete at 2009-04-02 09:49:28 Content-Type: multipart/alternative; boundary="=_alternative 000A0C104825758C_=" X-MAIL: mse2.zte.com.cn n321nYrC001052 Cc: pwe3-bounces@ietf.org, Matthew.Bocci@alcatel-lucent.com, pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? 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, 02 Apr 2009 01:48:38 -0000 This is a multipart message in MIME format. --=_alternative 000A0C104825758C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QXBwcmVjaWF0ZSB0aGUgZWZmb3J0IGFuZCBncmVlbiBkZXNpZ24gb2YgZmxvdyBiYXNlZCBsb2Fk IGJhbGFuY2Ugd2l0aG91dCANCmVncmVzcyByZW9yZGVyaW5nLg0KSSBoYXZlIGEgc21hbGwgcXVl c3Rpb246DQoNClRoZSAiRmF0IiBpbiB0aXRsZSBzZWVtcyBub3QgcmVsZXZhbnQgdG8gdGhlIGRl c2lnbi4NCkFjdHVhbGx5LCBpdCB0cmllcyB0byBpZGVudGlmeSBpbmRpdmlkdWFsIGZsb3cgaW5z aWRlIGEgImZhdCIgdHJhZmZpYywgYW5kIA0KbWFrZSBpdCAidGhpbiIgZW5vdWdoIHRvIGdvIHRo cm91Z2ggc2luZ2xlIGxpbmsuDQpXaGljaCBzZWVtcyBhIGtpbmQgb2YgZGVtdXhpbmcgZnVuY3Rp b24gYW5kIHNlZW0gdG8gbWUgdGhhdCBQVyBsYXllciBkb2VzIA0Kbm90IGhhdmUgYWRlcXVhdGUg bXV4aW5nIGNhcGFiaWxpdHkgc28gdGhhdCB3ZSBoYXZlIHRvIGFkZCBhbm90aGVyIGxheWVyIA0K YWJvdmUsIHJpZ2h0Pw0KQ291bGQgd2UganVzdCB1c2UgYSBtb3JlIHJlbGV2YW50IG5hbWUgZm9y IHRoZSBkb2N1bWVudCwgbGlrZSBmbG93IGJhc2VkIA0KcHcgbG9hZCBiYWxhbmNlPw0KDQpBbGJl cnQNCg0KDQoNCg0KWWFha292IFN0ZWluIDx5YWFrb3Zfc0ByYWQuY29tPiANCreivP7IyzogIHB3 ZTMtYm91bmNlc0BpZXRmLm9yZw0KMjAwOS0wNC0wMiAwMTo0MA0KDQrK1bz+yMsNCkJPQ0NJIE1h dHRoZXcgPE1hdHRoZXcuQm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tPiwgInB3ZTNAaWV0Zi5vcmci IA0KPHB3ZTNAaWV0Zi5vcmc+DQqzrcvNDQoNCtb3zOINClJlOiBbUFdFM10gZHJhZnQtYnJ5YW50 LWZpbHNmaWxzLWZhdC1wdy0wMyB0byBXRyBkcmFmdD8NCg0KDQoNCg0KDQoNCkkgc3VwcG9ydCB0 aGUgbW92aW5nIG9mIHRoZSBkcmFmdCB0byBXRyBzdGF0dXMsDQphbmQgaG9wZSB0aGF0IHRoaXMg bW92ZSB3aWxsIGJlIHRoZSBzdGltdWx1cyB0byAgcHV0IG1vcmUgd29yayBpbnRvIGl0Lg0KIA0K U2VjdGlvbiAyLCBhbHRob3VnaCBkZXNjcmliaW5nIGFuIE5TUCwgY291bGQgYmVuZWZpdCBmcm9t IGEgZmV3IHNpbXBsZSANCmV4YW1wbGVzLg0KIA0KVGhlIGZpcnN0IHBhcmFncmFwaCBvZiB0aGUg aW50cm8gbWVudGlvbnMgU0FUb1AsDQpidXQgdGhlcmUgaXMgbm93aGVyZSBhbnkgZGlzY3Vzc2lv biBvZiB3aGF0IHRoZSBtZWNoYW5pc20NCmRvZXMgdG8gcGFja2V0IGludGVyYXJyaXZhbCB0aW1l cy4NCiANClRoZSBkaXNjdXNzaW9uIG9mIHNlY3Rpb24gNi4zIHNlZW1zIHJhdGhlciBibG9hdGVk IGFuZCB1bmluZm9ybWF0aXZlIHRvIG1lDQooYXMgdGhlIG1lY2hhbmlzbSBiYXNpY2FsbHkgY2Fu IG5vdCBoYW5kbGUgdGhlIHNpbmdsZSBmYXQgZmxvdyBjYXNlKS4NCiANClkoSilTDQogDQogDQog DQogDQogDQogDQpGcm9tOiBwd2UzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwd2UzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANCkJPQ0NJIE1hdHRoZXcNClNlbnQ6IFR1ZXNkYXks IE1hcmNoIDMxLCAyMDA5IDE0OjUxDQpUbzogcHdlM0BpZXRmLm9yZw0KU3ViamVjdDogW1BXRTNd IGRyYWZ0LWJyeWFudC1maWxzZmlscy1mYXQtcHctMDMgdG8gV0cgZHJhZnQ/DQogDQpUaGlzIGlz IHRoZSBzdGFydCBvZiBhIHR3byB3ZWVrIHBvbGwgdG8ganVkZ2UgdGhlIGNvbnNlbnN1cyB0byBt b3ZlIA0KZHJhZnQtYnJ5YW50LWZpbHNmaWxzLWZhdC1wdy0wMyANCiB0byBhIFBXRTMgV29ya2lu ZyBHcm91cCBkcmFmdC4gDQpQbGVhc2UgY2FuIHlvdSByZXNwb25kIHRvIHRoZSBQV0UzIGxpc3Qg d2l0aCB5b3VyIGFwcHJvdmFsIChvciBvdGhlcndpc2UpLiANCg0KVGhpcyBwb2xsIHdpbGwgY2xv c2Ugb24gMTR0aCBBcHJpbCAyMDA5LiANClJlZ2FyZHMgDQpNYXR0aGV3IA0KIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwd2UzIG1haWxpbmcgbGlzdA0K cHdlM0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2Uz DQoNCg0K --=_alternative 000A0C104825758C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkFwcHJlY2lhdGUgdGhl IGVmZm9ydCBhbmQgZ3JlZW4gZGVzaWduIG9mIGZsb3cgYmFzZWQgbG9hZCBiYWxhbmNlIHdpdGhv dXQNCmVncmVzcyByZW9yZGVyaW5nLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+SSBoYXZlIGEgc21hbGwgcXVlc3Rpb246PC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgJnF1b3Q7RmF0JnF1b3Q7IGluIHRpdGxlIHNl ZW1zIG5vdA0KcmVsZXZhbnQgdG8gdGhlIGRlc2lnbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkFjdHVhbGx5LCBpdCB0cmllcyB0byBpZGVudGlmeSBpbmRpdmlk dWFsDQpmbG93IGluc2lkZSBhICZxdW90O2ZhdCZxdW90OyB0cmFmZmljLCBhbmQgbWFrZSBpdCAm cXVvdDt0aGluJnF1b3Q7IGVub3VnaA0KdG8gZ28gdGhyb3VnaCBzaW5nbGUgbGluay48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldoaWNoIHNlZW1zIGEga2luZCBv ZiBkZW11eGluZyBmdW5jdGlvbg0KYW5kIHNlZW0gdG8gbWUgdGhhdCBQVyBsYXllciBkb2VzIG5v dCBoYXZlIGFkZXF1YXRlIG11eGluZyBjYXBhYmlsaXR5IHNvDQp0aGF0IHdlIGhhdmUgdG8gYWRk IGFub3RoZXIgbGF5ZXIgYWJvdmUsIHJpZ2h0PzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Q291bGQgd2UganVzdCB1c2UgYSBtb3JlIHJlbGV2YW50IG5hbWUNCmZv ciB0aGUgZG9jdW1lbnQsIGxpa2UgZmxvdyBiYXNlZCBwdyBsb2FkIGJhbGFuY2U/PC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BbGJlcnQ8L2ZvbnQ+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+WWFha292 IFN0ZWluICZsdDt5YWFrb3Zfc0ByYWQuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtwd2UzLWJvdW5jZXNAaWV0Zi5v cmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wNC0wMiAw MTo0MDwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5CT0NDSSBNYXR0aGV3ICZsdDtNYXR0aGV3LkJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbSZn dDssDQomcXVvdDtwd2UzQGlldGYub3JnJnF1b3Q7ICZsdDtwd2UzQGlldGYub3JnJmd0OzwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ 1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6 IFtQV0UzXSBkcmFmdC1icnlhbnQtZmlsc2ZpbHMtZmF0LXB3LTAzDQp0byBXRyBkcmFmdD88L2Zv bnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwv dGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 IzFmNDk3ZCBmYWNlPSJzYW5zLXNlcmlmIj5JIHN1cHBvcnQgdGhlIG1vdmluZyBvZg0KdGhlIGRy YWZ0IHRvIFdHIHN0YXR1cyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2Qg ZmFjZT0ic2Fucy1zZXJpZiI+YW5kIGhvcGUgdGhhdCB0aGlzIG1vdmUNCndpbGwgYmUgdGhlIHN0 aW11bHVzIHRvICZuYnNwO3B1dCBtb3JlIHdvcmsgaW50byBpdC48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9InNhbnMtc2VyaWYiPlNlY3Rpb24gMiwg YWx0aG91Z2ggZGVzY3JpYmluZw0KYW4gTlNQLCBjb3VsZCBiZW5lZml0IGZyb20gYSBmZXcgc2lt cGxlIGV4YW1wbGVzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5 N2QgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIGZpcnN0IHBhcmFncmFwaCBvZg0KdGhlIGludHJvIG1l bnRpb25zIFNBVG9QLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNl PSJzYW5zLXNlcmlmIj5idXQgdGhlcmUgaXMgbm93aGVyZSBhbnkNCmRpc2N1c3Npb24gb2Ygd2hh dCB0aGUgbWVjaGFuaXNtPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh Y2U9InNhbnMtc2VyaWYiPmRvZXMgdG8gcGFja2V0IGludGVyYXJyaXZhbA0KdGltZXMuPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJzYW5zLXNlcmlm Ij5UaGUgZGlzY3Vzc2lvbiBvZiBzZWN0aW9uDQo2LjMgc2VlbXMgcmF0aGVyIGJsb2F0ZWQgYW5k IHVuaW5mb3JtYXRpdmUgdG8gbWU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5 N2QgZmFjZT0ic2Fucy1zZXJpZiI+KGFzIHRoZSBtZWNoYW5pc20gYmFzaWNhbGx5DQpjYW4gbm90 IGhhbmRsZSB0aGUgc2luZ2xlIGZhdCBmbG93IGNhc2UpLjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0ic2Fucy1zZXJpZiI+WShKKVM8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdk IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 IzFmNDk3ZCBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+IHB3ZTMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OnB3ZTMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Qk9DQ0kgTWF0dGhl dzxiPjxicj4NClNlbnQ6PC9iPiBUdWVzZGF5LCBNYXJjaCAzMSwgMjAwOSAxNDo1MTxiPjxicj4N ClRvOjwvYj4gcHdlM0BpZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiBbUFdFM10gZHJhZnQt YnJ5YW50LWZpbHNmaWxzLWZhdC1wdy0wMyB0byBXRyBkcmFmdD88L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj5UaGlzIGlzIHRoZSBzdGFydCBvZiBhIHR3byB3ZWVrIHBvbGwgdG8g anVkZ2UNCnRoZSBjb25zZW5zdXMgdG8gbW92ZSBkcmFmdC1icnlhbnQtZmlsc2ZpbHMtZmF0LXB3 LTAzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KIHRvIGEgUFdFMyBXb3JraW5nIEdyb3VwIGRy YWZ0LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD4N CjxwPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+UGxlYXNlIGNhbiB5b3UgcmVzcG9uZCB0byB0 aGUgUFdFMyBsaXN0IHdpdGgNCnlvdXIgYXBwcm92YWwgKG9yIG90aGVyd2lzZSkuPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj5UaGlzIHBvbGwgd2lsbCBjbG9zZSBvbiAxNHRoIEFwcmlsIDIwMDku PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5SZWdhcmRzPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij5NYXR0aGV3PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9m b250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTI+PHR0Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KcHdlMyBtYWlsaW5nIGxpc3Q8YnI+DQpwd2UzQGlldGYub3JnPGJyPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzPGJyPg0KPC90dD48L2Zv bnQ+DQo8YnI+DQo= --=_alternative 000A0C104825758C_=-- From stbryant@cisco.com Thu Apr 2 01:15:30 2009 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 27AD53A67A8; Thu, 2 Apr 2009 01:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.474 X-Spam-Level: X-Spam-Status: No, score=-8.474 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] 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 YgkPo-oDq4n1; Thu, 2 Apr 2009 01:15:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 794E63A6844; Thu, 2 Apr 2009 01:15:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,313,1235952000"; d="scan'208";a="37286387" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2009 08:16:27 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n328GRv7014805; Thu, 2 Apr 2009 10:16:27 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n328GR1F010378; Thu, 2 Apr 2009 08:16:27 GMT Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n328GPM27671; Thu, 2 Apr 2009 09:16:25 +0100 (BST) Message-ID: <49D47458.9090703@cisco.com> Date: Thu, 02 Apr 2009 09:16:24 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: jiang.xiaowei@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2616; t=1238660187; x=1239524187; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20draft-bryant-filsfils-fat-pw-0 3=20to=20WG=20draft? |Sender:=20; bh=2NMDiKpJx9eeuzpTjoIFLXxABCIHVQsWM5Voktx63ns=; b=YfwIzBqpq0OssKR4eWZwWF+8mhMBIktKJMy4+VTBIwMMzolqcyqPZYFlds sZm4QbXJKY0lU9Y0oloFUJaj7X33u8om2SQxLtsKvRhDv6BiA1ps+CgwAU1/ tgrijRHNvZ; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: pwe3-bounces@ietf.org, Matthew.Bocci@alcatel-lucent.com, yaakov_s@rad.com, pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? 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: Thu, 02 Apr 2009 08:15:30 -0000 FAT stands for the contrived name "Flow Aware Transport" - I think I spell that out in the draft. Note that we mean transport as in layer above network, not transport as in network below datalink. Stewart jiang.xiaowei@zte.com.cn wrote: > > > Appreciate the effort and green design of flow based load balance > without egress reordering. > I have a small question: > > The "Fat" in title seems not relevant to the design. > Actually, it tries to identify individual flow inside a "fat" traffic, > and make it "thin" enough to go through single link. > Which seems a kind of demuxing function and seem to me that PW layer > does not have adequate muxing capability so that we have to add > another layer above, right? > Could we just use a more relevant name for the document, like flow > based pw load balance? > > Albert > > > > *Yaakov Stein * > ·¢¼þÈË: pwe3-bounces@ietf.org > > 2009-04-02 01:40 > > > ÊÕ¼þÈË > BOCCI Matthew , "pwe3@ietf.org" > > ³­ËÍ > > Ö÷Ìâ > Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? > > > > > > > > > > I support the moving of the draft to WG status, > and hope that this move will be the stimulus to put more work into it. > > Section 2, although describing an NSP, could benefit from a few simple > examples. > > The first paragraph of the intro mentions SAToP, > but there is nowhere any discussion of what the mechanism > does to packet interarrival times. > > The discussion of section 6.3 seems rather bloated and uninformative > to me > (as the mechanism basically can not handle the single fat flow case). > > Y(J)S > > > > > > > *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On > Behalf Of *BOCCI Matthew* > Sent:* Tuesday, March 31, 2009 14:51* > To:* pwe3@ietf.org* > Subject:* [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? > > This is the start of a two week poll to judge the consensus to move > draft-bryant-filsfils-fat-pw-03 > to a PWE3 Working Group draft. > > Please can you respond to the PWE3 list with your approval (or > otherwise). > > This poll will close on 14th April 2009. > > Regards > > Matthew > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From stbryant@cisco.com Thu Apr 2 01:20:40 2009 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 0D4153A6CDA for ; Thu, 2 Apr 2009 01:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.467 X-Spam-Level: X-Spam-Status: No, score=-8.467 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] 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 fFDUf2GlINcq for ; Thu, 2 Apr 2009 01:20:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 60A983A6B18 for ; Thu, 2 Apr 2009 01:20:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,313,1235952000"; d="scan'208";a="37287200" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2009 08:21:38 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n328LcWn007188; Thu, 2 Apr 2009 10:21:38 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n328LcTk012396; Thu, 2 Apr 2009 08:21:38 GMT Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n328LbM28000; Thu, 2 Apr 2009 09:21:37 +0100 (BST) Message-ID: <49D47591.7020506@cisco.com> Date: Thu, 02 Apr 2009 09:21:37 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: liu.guoman@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6063; t=1238660498; x=1239524498; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20draft-bryant-filsfils-fat-pw-0 3=20to=20WG=20draft? |Sender:=20; bh=01Uu6hukgD0cziOnfJdoPp7TquD9X0JMLRR30Qag/Kw=; b=ZSiASrpyGVacjj76AZoj1SPZFQQfiBetqauERrhtQ+w2kPxKoc1vcJgDvz 29aGWnFUjStu0n3I5Qr+3AzDbGIfwG8gVAT3gwRrQBKeoqBhjYhp+5KZf8Yh m4+Ue32rfq; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? 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: Thu, 02 Apr 2009 08:20:40 -0000 Remember all packets that have a mutual order sensitivity go in the same flow - that is the definition of a flow. A flow is a group of packets that have a "ships in the night" relationship with another flow. An example would be two TCP sessions. Stewart liu.guoman@zte.com.cn wrote: > > stewart: > for FAT PW Draft, though it realize a "big" traffics will be > tranported by a few pw channel by ECMP. the key problem: how to keep > ordering for big traffics? > > regards > liu > > > *Stewart Bryant * > ·¢¼þÈË: pwe3-bounces@ietf.org > > 2009-04-02 00:38 > Çë´ð¸´ ¸ø > stbryant@cisco.com > > > > ÊÕ¼þÈË > BUSI ITALO > ³­ËÍ > neil.2.harrison@bt.com, pwe3@ietf.org > Ö÷Ìâ > Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? > > > > > > > > > > Sorry I misread the subject line - that's the problem with having > two drafts running in parallel :) > > Pkt PW may apply to MPLS-TP that is a MEAD team call. > > Fat PW I assume is only applicable to classic. The only way that > I can see to do LAG in a transport context is to do pw-bonding, otherwise > you violate the ordering. > > Sorry for any confusion. > > Stewart > > > > > > > > > BUSI ITALO wrote: > > Stewart, > > > > Could you please clarify the applicability of Fat PW to MPLS-TP? > > > > In SF, you stated that they are applicable to "ECMP and LAG case" and > > this matched with my understanding of the draft. > > > > Due to the fact that ECMP is not used in MPLS-TP, I had assumed this > > draft is not applicable in MPLS-TP. > > > > Did I miss/misunderstand anything? > > > > Thanks, Italo > > > > > >> -----Original Message----- > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > >> Behalf Of Stewart Bryant > >> Sent: Wednesday, April 01, 2009 12:55 PM > >> To: neil.2.harrison@bt.com > >> Cc: pwe3@ietf.org > >> Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? > >> > >> The draft has applicability to Transport. > >> > >> I will come to the details below in a minute, but tell me how you > >> propose to cope with > >> ESSM in a client - surely you need to intervene rather than > >> carry them > >> transparently? > >> > >> Remember that the client layer performs the classification > >> into protocol > >> types > >> so we just carry the classification over the server layer in a more > >> convenient way. > >> > >> Remember if you don't like the pkt-pw you can always put a > >> real interface in > >> and use a L2 pw, and if you don't like that you can always > >> but a clear > >> fibre. What you do depends on how you wish to run the economics. > >> > >> > >> > >> neil.2.harrison@bt.com wrote: > >> > >>> Stewart, can I please ask if this draft would be applicable > >>> > >> to MPLS-TP? > >> > >>> > >>> I ask this because a transport network should satisfy the > >>> > >> requirements > >> > >>> of transparency....which in brief means: > >>> > >>> - all client bits treated equally > >>> > >> That happens here > >> > >>> - client bit ordering preserved > >>> > >> That also happens here > >> > >>> - no attempt made to try understand semantics of client > >>> > >> symbols (ie > >> > >>> client message/traffic-unit formed from N client bits) and never > >>> change client bits > >>> > >> In this mechanism it is the client layer that makes the changes - not > >> the server layer. The client presents the packet and and > >> metadata saying > >> what pid the server is to write into the PID > >> > >>> - server ensures client X traffic behaviour cannot impact > >>> performance experienced by client Y > >>> > >> We pass that test > >> > >>> > >>> ...and I cannot reconcile this with this draft. So perhaps > >>> > >> this draft > >> > >>> is only intended to apply to 'classical' MPLS? > >>> > >> It's not clear that it fails the test when you realize that > >> the client > >> is presenting the modified data to the server. > >> > >> Stewart > >> > >> > >>> > >>> regards, Neil > >>> > >>> > >>> > >> -------------------------------------------------------------- > >> ---------- > >> > >>> *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On > >>> Behalf Of *BOCCI Matthew > >>> *Sent:* 31 March 2009 12:51 > >>> *To:* pwe3@ietf.org > >>> *Subject:* [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? > >>> > >>> This is the start of a two week poll to judge the consensus to > >>> move draft-bryant-filsfils-fat-pw-03 > >>> to a PWE3 Working Group draft. > >>> > >>> Please can you respond to the PWE3 list with your approval (or > >>> otherwise). > >>> > >>> This poll will close on 14th April 2009. > >>> > >>> Regards > >>> > >>> Matthew > >>> > >>> > >>> > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www.ietf.org/mailman/listinfo/pwe3 > >> > >> > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > -------------------------------------------------------- > 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. > From stbryant@cisco.com Thu Apr 2 04:23:39 2009 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 BBD583A6952 for ; Thu, 2 Apr 2009 04:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.686 X-Spam-Level: X-Spam-Status: No, score=-7.686 tagged_above=-999 required=5 tests=[AWL=-1.087, 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 gbJirZ5TVWZe for ; Thu, 2 Apr 2009 04:23:38 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D5FE23A680F for ; Thu, 2 Apr 2009 04:23:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,313,1235952000"; d="scan'208";a="70087084" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2009 11:24:39 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n32BOc9Y019474; Thu, 2 Apr 2009 13:24:38 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n32BOcll024072; Thu, 2 Apr 2009 11:24:38 GMT Received: from dhcp-gpk02-vlan300-64-103-65-45.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n32BOYM16470; Thu, 2 Apr 2009 12:24:38 +0100 (BST) Message-ID: <49D4A072.9090308@cisco.com> Date: Thu, 02 Apr 2009 12:24:34 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: liu.guoman@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1010; t=1238671479; x=1239535479; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20draft-bryant-filsfils-fat-pw-0 3=20to=20WG=20draft? |Sender:=20; bh=6TVXgDk//tYiX7Gn4LHCT7tQqNCQe+5BibuieCWYBNw=; b=nbWv/oXuEiwbVWb9ViH1fxsOjvflNIt7nbI9Q52U8gsH8kUQQcIEwe0WTL 1szf5om9Ss0CKxJf8OhRWQV19FGgGQiDowS/o/5uJh/+nYwcc6nbKiihO1xe e3UltdiDny; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? 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: Thu, 02 Apr 2009 11:23:39 -0000 liu.guoman@zte.com.cn wrote: > > Stewart: > my problem is : if there is a multimedia data flow, the flow must be > transported in order. or else it will not become a multimedia flow. > how to process the data flow by ECMP? > IMO, there are two solutions: > 1 at sink points, there are enough buffers to store the data flow. > 2 during transporting the data flow, it must transport in order. > > do you think so? > regards > liu > Yes Remember this draft is simply a tool that is used to spread out already identified flows over the ECMP set. The processing into and out of a fat pw is outside it's scope. Clearly you can enable s/n - apply the LB label - and put the flow back together at the egress if that suits you application otherwise as you say you have to have large enough end to end b/w. Remember what it says in the PWE3 charter - if the best effort emulation provided by PWE3 is not good enough, then either propose a better emulation, or use a real wire. Stewart From RonenS@orckit.com Wed Apr 1 23:05:27 2009 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 205AC3A6918 for ; Wed, 1 Apr 2009 23:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.685 X-Spam-Level: X-Spam-Status: No, score=-0.685 tagged_above=-999 required=5 tests=[AWL=1.913, 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 4FEROxlpNhAb for ; Wed, 1 Apr 2009 23:05:26 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by core3.amsl.com (Postfix) with ESMTP id 6C6A23A69BB for ; Wed, 1 Apr 2009 23:05:24 -0700 (PDT) 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_01C9B359.26FBB380" Date: Thu, 2 Apr 2009 09:06:23 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA081304DAD65F@tlvmail1> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? Thread-Index: Acmx9uZY0mmoKvLIT1OqXckF2OpOJgBEk7TAABPtoLA= References: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> From: "Ronen Solomon" To: "BOCCI Matthew" , X-Mailman-Approved-At: Thu, 02 Apr 2009 09:24:50 -0700 Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? 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, 02 Apr 2009 06:05:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B359.26FBB380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support=20 =20 Ronen Solomon =20 ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Rajeev Manur Sent: Wednesday, April 01, 2009 11:54 PM To: BOCCI Matthew; pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? =20 Support. =20 --Rajeev Manur =20 =20 ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: Tuesday, March 31, 2009 4:51 AM To: pwe3@ietf.org Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? This is the start of a two week poll to judge the consensus to move draft-bryant-filsfils-fat-pw-03=20 to a PWE3 Working Group draft.=20 Please can you respond to the PWE3 list with your approval (or otherwise).=20 This poll will close on 14th April 2009.=20 Regards=20 Matthew=20 =20 ------_=_NextPart_001_01C9B359.26FBB380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-bryant-filsfils-fat-pw-03 to WG draft?

Support =

 =

Ronen = Solomon

 =


From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Rajeev Manur
Sent: Wednesday, April = 01, 2009 11:54 PM
To: BOCCI Matthew; = pwe3@ietf.org
Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG = draft?

 

Support.

 

--Rajeev = Manur

 

 


From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI Matthew
Sent: Tuesday, March 31, = 2009 4:51 AM
To: pwe3@ietf.org
Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG = draft?

This is the start of a two = week poll to judge the consensus to move = draft-bryant-filsfils-fat-pw-03
 to a PWE3 Working Group draft.

Please can you respond to the PWE3 list with your approval (or otherwise).

This poll will close on 14th April 2009. =

Regards

Matthew

 

------_=_NextPart_001_01C9B359.26FBB380-- From Ulrich.Drafz@telekom.de Wed Apr 1 08:38:53 2009 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 9751B3A67F7 for ; Wed, 1 Apr 2009 08:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, 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 DKUlBNfggwOX for ; Wed, 1 Apr 2009 08:38:52 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 1F8463A63EB for ; Wed, 1 Apr 2009 08:38:51 -0700 (PDT) Received: from s4de8dsaamv.krf.telekom.de (HELO S4DE8DSAAMV.west.t-com.de) ([10.134.164.131]) by tcmail81.telekom.de with ESMTP; 01 Apr 2009 17:39:50 +0200 Received: from S4DE8DSAAGZ.west.t-com.de ([10.134.164.74]) by S4DE8DSAAMV.west.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 17:39:49 +0200 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_01C9B2E0.177DB098" Date: Wed, 1 Apr 2009 17:39:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? Thread-Index: Acmy4BKnjusgDHOzRa28GlSLSwKf6g== From: To: X-OriginalArrivalTime: 01 Apr 2009 15:39:49.0522 (UTC) FILETIME=[179AF720:01C9B2E0] X-Mailman-Approved-At: Thu, 02 Apr 2009 09:25:01 -0700 Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 16:41:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B2E0.177DB098 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable support Von: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] Im Auftrag von = BOCCI Matthew Gesendet: Dienstag, 31. M=E4rz 2009 13:51 An: pwe3@ietf.org Betreff: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? =09 =09 This is the start of a two week poll to judge the consensus to move = draft-bryant-filsfils-fat-pw-03=20 to a PWE3 Working Group draft.=20 Please can you respond to the PWE3 list with your approval (or = otherwise).=20 This poll will close on 14th April 2009.=20 Regards=20 Matthew=20 Deutsche Telekom Netzproduktion GmbH T-Com, Zentrum Technik Einf=FChrung Ulrich Drafz Leiter, TE142 Hammerstrasse 216 - 226, D-48153 M=FCnster +49 251 7985-400 (Tel.) +49 251 7985-109 (Fax) +49 171 2209397 (Mobil) E-Mail: Ulrich.Drafz@telekom.de http://www.telekom.de Registerrechtliche Unternehmensangaben: Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Timotheus H=F6=F6tges (Vorsitzender) Gesch=E4ftsleitung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190, Sitz der Gesellschaft: Bonn USt-IdNr. DE 814645262 Erleben, was verbindet. ------_=_NextPart_001_01C9B2E0.177DB098 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?

support


Von: pwe3-bounces@ietf.org = [mailto:pwe3-bounces@ietf.org] Im Auftrag von BOCCI Matthew
        Gesendet: Dienstag, 31. M=E4rz 2009 13:51
        An: pwe3@ietf.org
        Betreff: [PWE3] draft-bryant-filsfils-fat-pw-03 to = WG draft?
       =20
       =20

        This is the start of a two week poll to judge the = consensus to move draft-bryant-filsfils-fat-pw-03
         to a PWE3 Working Group draft.

        Please can you respond to the PWE3 list with your = approval (or otherwise).

        This poll will close on 14th April 2009.

        Regards

        Matthew



Deutsche Telekom Netzproduktion = GmbH
T-Com, Zentrum Technik = Einf=FChrung
Ulrich Drafz
Leiter, TE142
Hammerstrasse 216 - 226, D-48153 = M=FCnster
+49 251 7985-400 (Tel.)
+49 251 7985-109 (Fax)
+49 171 2209397 (Mobil)
E-Mail: = Ulrich.Drafz@telekom.de
http://www.telekom.de

Registerrechtliche = Unternehmensangaben:
Deutsche Telekom Netzproduktion = GmbH
Aufsichtsrat: Timotheus H=F6=F6tges (Vorsitzender)
Gesch=E4ftsleitung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190, Sitz der Gesellschaft: = Bonn

USt-IdNr. DE 814645262

Erleben, was verbindet.

------_=_NextPart_001_01C9B2E0.177DB098-- From riccardo.martinotti@ericsson.com Thu Apr 2 06:05:26 2009 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 3D4933A689E; Thu, 2 Apr 2009 06:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 5fus7QCT2caL; Thu, 2 Apr 2009 06:05:22 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id AC0293A6A5F; Thu, 2 Apr 2009 06:05:21 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 902B520EF7; Thu, 2 Apr 2009 15:06:21 +0200 (CEST) X-AuditID: c1b4fb3c-acf95bb0000004b9-f5-49d4b84c8040 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DDD8721142; Thu, 2 Apr 2009 15:06:20 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 15:04:47 +0200 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_01C9B393.999BD8FB" Date: Thu, 2 Apr 2009 15:08:00 +0200 Message-ID: <269AE8908A44C145A4745C3ED880B9A768C241@esealmw110.eemea.ericsson.se> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] draft-bryant-pwe3-packet-pw-00.txt to WG draft? Thread-Index: Acmx+FcP5L7TrJafSfatI2vSUDObcABmp8hQ References: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.com> From: "Riccardo Martinotti" To: "BOCCI Matthew" , X-OriginalArrivalTime: 02 Apr 2009 13:04:47.0367 (UTC) FILETIME=[99808170:01C9B393] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Thu, 02 Apr 2009 09:41:14 -0700 Cc: mpls-tp@ietf.org Subject: Re: [PWE3] [mpls-tp] draft-bryant-pwe3-packet-pw-00.txt to WG draft? 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, 02 Apr 2009 13:05:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B393.999BD8FB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The network scenario considered into the draft is certainly of interest, = the case where client is "classic" MPLS and server is MPLS-TP is also = described into draft-martinotti-mpls-tp-interworking-01, Section 7.1.3. = (IP/MPLS / MPLS-TP hybrid edge node) I have one comment/question to the authors: In section 2 there is = reference to RFC 3985, Figure 3, however it is not specified which of = the two interworking functions is referred to. I suppose, due to the = presence of virtual physical termination, that the one with = pre-processing is referred. How is it defined the relationship between = the Attachment Circuit and the PW, in term of Forwarder and Native = Service Processing? Thank you and regards, Riccardo =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of BOCCI Matthew Sent: marted=EC 31 marzo 2009 14.01 To: pwe3@ietf.org Cc: mpls-tp@ietf.org Subject: [mpls-tp] draft-bryant-pwe3-packet-pw-00.txt to WG draft? =20 This is the start of a two week poll to judge the consensus to move = draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft. Please can you respond, *to the PWE3 list only*, with your approval (or = otherwise).=20 This poll will close on 14th April 2009.=20 Regards=20 Matthew=20 =20 ------_=_NextPart_001_01C9B393.999BD8FB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-bryant-pwe3-packet-pw-00.txt to WG draft?

The network scenario considered into the draft is certainly of = interest, the case where client is “classic” MPLS and server is = MPLS-TP is also described into draft-martinotti-mpls-tp-interworking-01, Section = 7.1.3. (IP/MPLS / MPLS-TP hybrid edge node)

I have one comment/question to the authors: In section 2 there is = reference to RFC 3985, Figure 3, however it is not specified which of the two interworking functions is referred to. I suppose, due to the = presence of virtual physical termination, that the one with pre-processing is = referred. How is it defined the relationship between the Attachment Circuit and the = PW, in term of Forwarder and Native Service = Processing?

Thank you and regards,

Riccardo

 =


From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of BOCCI Matthew
Sent: marted=EC 31 marzo = 2009 14.01
To: pwe3@ietf.org
Cc: mpls-tp@ietf.org
Subject: [mpls-tp] = draft-bryant-pwe3-packet-pw-00.txt to WG draft?

 

This is the start of a two week poll to judge the consensus to move draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group = draft.

Please can you respond, *to the PWE3 list only*, with your approval (or = otherwise).

This poll will close on 14th April 2009.

Regards

Matthew

 

------_=_NextPart_001_01C9B393.999BD8FB-- From stbryant@cisco.com Thu Apr 2 10:07:43 2009 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 1D2DB3A6CA8 for ; Thu, 2 Apr 2009 10:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.647 X-Spam-Level: X-Spam-Status: No, score=-7.647 tagged_above=-999 required=5 tests=[AWL=-1.048, 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 dVbxd735Ttg7 for ; Thu, 2 Apr 2009 10:07:42 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 487CA3A6A14 for ; Thu, 2 Apr 2009 10:07:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,315,1235952000"; d="scan'208";a="149661848" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2009 17:08:43 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n32H8ggE005324 for ; Thu, 2 Apr 2009 19:08:42 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n32H8gnA027654 for ; Thu, 2 Apr 2009 17:08:42 GMT Received: from dhcp-gpk02-vlan300-64-103-65-45.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n32H8gM26772; Thu, 2 Apr 2009 18:08:42 +0100 (BST) Message-ID: <49D4F11A.1020905@cisco.com> Date: Thu, 02 Apr 2009 18:08:42 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=281; t=1238692122; x=1239556122; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Should=20draft-martini-pwe3-iccp-01=20be=20a=20 WG=20doc? |Sender:=20; bh=bV1omOMVv0CGXIAcMwECCBHWzl7D4L8c/7exYeWT3j8=; b=d52KzpiBIBz49cIoiWv5eeJQcqx2eL9xDe0iLivXD1aqlkivXTdUr594j8 jhVg3ZmBfm/VV3+Yv9ZW+w/tS1GrsOmE+o+oZ69tBKaftXctc9O81khf/0L1 APeomJWFET; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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: Thu, 02 Apr 2009 17:07:43 -0000 The authors of draft-martini-pwe3-iccp-01.txt http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt have requested that this become a PWE3 WG document. Please can you send comments to the list by 20th April so that the chairs can judge consensus. Thanks Stewart From DALLAN@nortel.com Thu Apr 2 10:17:20 2009 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 24F3E3A6DE5 for ; Thu, 2 Apr 2009 10:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 SHSNbR2ohizg for ; Thu, 2 Apr 2009 10:17:19 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 311443A67D2 for ; Thu, 2 Apr 2009 10:17:19 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n32HIE113929; Thu, 2 Apr 2009 17:18:14 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 13:17:58 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE193A8325@zcarhxm2.corp.nortel.com> In-Reply-To: <49D4F11A.1020905@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? Thread-Index: Acmzthrw3LRxxTp2RcW+PAjuVJIAHAAAEP9g References: <49D4F11A.1020905@cisco.com> From: "David Allan" To: , "pwe3" Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 02 Apr 2009 17:17:20 -0000 Hi Stewart Comment that most resonated with me in Dublin was "how frequently would mirrored nodes be multi-vendor", implying minimal interest from anyone in standardizing this... That seemed to be group consensus at the time, what has changed? Cheers Dave -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Thursday, April 02, 2009 1:09 PM To: pwe3 Subject: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? The authors of draft-martini-pwe3-iccp-01.txt http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt have requested that this become a PWE3 WG document. Please can you send comments to the list by 20th April so that the chairs can judge consensus. Thanks Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From tom.nadeau@bt.com Thu Apr 2 10:21:59 2009 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 6A4973A6D30 for ; Thu, 2 Apr 2009 10:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.183 X-Spam-Level: X-Spam-Status: No, score=-1.183 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] 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 j49VnfgG+suQ for ; Thu, 2 Apr 2009 10:21:58 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 72F9B3A6CE0 for ; Thu, 2 Apr 2009 10:21:58 -0700 (PDT) Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.103]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 18:22:58 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Apr 2009 17:22:41 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 02 Apr 2009 13:22:40 -0400 From: "Thomas D. Nadeau" To: David Allan , Stewart Bryant , pwe3 Message-ID: Thread-Topic: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? Thread-Index: Acmzthrw3LRxxTp2RcW+PAjuVJIAHAAAEP9gAABQPyw= In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE193A8325@zcarhxm2.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Apr 2009 17:22:58.0996 (UTC) FILETIME=[AB3B7F40:01C9B3B7] Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 02 Apr 2009 17:21:59 -0000 On 4/2/09 1:17 PM, "David Allan" wrote: > Hi Stewart > > Comment that most resonated with me in Dublin was "how frequently would > mirrored nodes be multi-vendor", implying minimal interest from anyone > in standardizing this... Speaking as a service provider interested in providing multi-vendor interoperability on this function, I'd disagree that there is minimal interest in standardizing this. I build and deploy multi-vendor networks and need this feature to work on different platforms. There might not be interest from vendors like youself (although the three I use are), having spoken to other colleagues on the SP side, they are interested. I hope they chime in on this thread to this effect. --Tom > That seemed to be group consensus at the time, what has changed? > > Cheers > Dave > > > > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Stewart Bryant > Sent: Thursday, April 02, 2009 1:09 PM > To: pwe3 > Subject: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? > > The authors of draft-martini-pwe3-iccp-01.txt > > http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt > > have requested that this become a PWE3 WG document. > > Please can you send comments to the list by 20th April so that the > chairs can judge consensus. > > Thanks > > Stewart > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 -- Principal Architect - 21CN Networks From sboutros@cisco.com Thu Apr 2 10:26:54 2009 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 A15AC3A6B36 for ; Thu, 2 Apr 2009 10:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 hMosDkO-qZNK for ; Thu, 2 Apr 2009 10:26:53 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CDD343A67E5 for ; Thu, 2 Apr 2009 10:26:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,315,1235952000"; d="scan'208";a="165747733" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 02 Apr 2009 17:27:55 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n32HRtOQ009843; Thu, 2 Apr 2009 10:27:55 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n32HRtPg020158; Thu, 2 Apr 2009 17:27:55 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 10:27:55 -0700 Received: from sboutros-wxp01.ciswco.com ([10.21.81.209]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 10:27:54 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Apr 2009 10:27:53 -0700 To: stbryant@cisco.com, pwe3 From: Sami Boutros In-Reply-To: <49D4F11A.1020905@cisco.com> References: <49D4F11A.1020905@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Apr 2009 17:27:54.0694 (UTC) FILETIME=[5B7B6E60:01C9B3B8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=498; t=1238693275; x=1239557275; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sboutros@cisco.com; z=From:=20Sami=20Boutros=20 |Subject:=20Re=3A=20[PWE3]=20Should=20draft-martini-pwe3-ic cp-01=20be=20a=20WG=20doc? |Sender:=20; bh=sg2mN33phsmgdUAu/KH9h1LcFr++zgEr7MIo2vmsmYU=; b=doQy8VCCmSfc9qNw5TzaqCDbL32INg15zZMAgGBAwo6RV6ShHXicY7zkfk d2BF+raJvxthpGeJc5/vNrrthhkXcv2egwn82XqvjsLwJ4CHKtHvrPI4UJJk tq20SJA7KBRnIQeZyaTAeQ2ffI8nn4RmswsOYP7ULSAuSo0lAhqbE=; Authentication-Results: sj-dkim-1; header.From=sboutros@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 02 Apr 2009 17:26:54 -0000 Support, Thanks, Sami At 10:08 AM 4/2/2009, Stewart Bryant wrote: >The authors of draft-martini-pwe3-iccp-01.txt > >http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt > >have requested that this become a PWE3 WG document. > >Please can you send comments to the list by 20th April >so that the chairs can judge consensus. > >Thanks > >Stewart >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 From msiva@cisco.com Thu Apr 2 10:57:22 2009 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 CE7CC3A6C49 for ; Thu, 2 Apr 2009 10:57:22 -0700 (PDT) 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 IxNfK5g01dNo for ; Thu, 2 Apr 2009 10:57:21 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E1EEB3A68DC for ; Thu, 2 Apr 2009 10:57:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,315,1235952000"; d="scan'208";a="165762311" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-1.cisco.com with ESMTP; 02 Apr 2009 17:58:23 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n32HwNS7010674; Thu, 2 Apr 2009 13:58:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n32HwN3E028482; Thu, 2 Apr 2009 17:58:23 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 13:58:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 13:58:22 -0400 Message-ID: <06CA4D9493AD874B8222AD078A7AD0A206D819B5@xmb-rtp-205.amer.cisco.com> In-Reply-To: <49D4F11A.1020905@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? Thread-Index: AcmztgL/0UADHU0NT4O1853m7MrDmAABpMTQ References: <49D4F11A.1020905@cisco.com> From: "Siva Sivabalan (msiva)" To: "Stewart Bryant (stbryant)" , "pwe3" X-OriginalArrivalTime: 02 Apr 2009 17:58:23.0162 (UTC) FILETIME=[9D5581A0:01C9B3BC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=667; t=1238695103; x=1239559103; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=msiva@cisco.com; z=From:=20=22Siva=20Sivabalan=20(msiva)=22=20 |Subject:=20RE=3A=20[PWE3]=20Should=20draft-martini-pwe3-ic cp-01=20be=20a=20WG=20doc? |Sender:=20 |To:=20=22Stewart=20Bryant=20(stbryant)=22=20,=20=22pwe3=22=20; bh=+mqFEU0v78oi28NfSquuKR7JbB3YezTbOTDyBASUdXk=; b=rk6w/axURf4WY2GFaFNAGj56697NWqiAJWPgXmNzh7v9f/oMiTwmO1Id6I bjX1RkUHeVOdTkAxSHBCqyN7TzOevoZGJHOoPMsLq751DaETpD1NuuLSRcPP ZZaAZuC7jL; Authentication-Results: rtp-dkim-1; header.From=msiva@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 02 Apr 2009 17:57:22 -0000 Support.=20 -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant (stbryant) Sent: Thursday, April 02, 2009 1:09 PM To: pwe3 Subject: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? The authors of draft-martini-pwe3-iccp-01.txt http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt have requested that this become a PWE3 WG document. Please can you send comments to the list by 20th April so that the chairs can judge consensus. Thanks Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From stbryant@cisco.com Thu Apr 2 11:51:46 2009 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 D1C743A6D56 for ; Thu, 2 Apr 2009 11:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.608 X-Spam-Level: X-Spam-Status: No, score=-7.608 tagged_above=-999 required=5 tests=[AWL=-1.009, 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 MAHaJZDmMJez for ; Thu, 2 Apr 2009 11:51:46 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0D40B3A6C32 for ; Thu, 2 Apr 2009 11:51:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,315,1235952000"; d="scan'208";a="149708965" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-3.cisco.com with ESMTP; 02 Apr 2009 18:52:47 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n32IqkFF025876; Thu, 2 Apr 2009 20:52:46 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n32IqkCZ017372; Thu, 2 Apr 2009 18:52:46 GMT Received: from dhcp-gpk02-vlan300-64-103-65-45.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n32IqjM06706; Thu, 2 Apr 2009 19:52:45 +0100 (BST) Message-ID: <49D5097D.1010806@cisco.com> Date: Thu, 02 Apr 2009 19:52:45 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: davarish@yahoo.com References: <49D4F11A.1020905@cisco.com> <87AC5F88F03E6249AEA68D40BD3E00BE193A8325@zcarhxm2.corp.nortel.com> <005201c9b3bc$691028a0$3b3079e0$@com> In-Reply-To: <005201c9b3bc$691028a0$3b3079e0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1062; t=1238698366; x=1239562366; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20Should=20draft-martini-pwe3-ic cp-01=20be=20a=20WG=20doc? |Sender:=20; bh=UwC+VKp87u1XEPofEvFIWCF2aRVhz8XsQwMPDhfeIYU=; b=arr3DclFz26c2tQGgB2jH+ECl3kXvTNpdNpfHjcrNbVLqSVIDlWqUR7ZZo 1Dha6sMLI1Gclw64uUshxA9HPkMuNxcI5y2DCihIEDEw+PoV+T2Y4ohKTBL/ R+3YmiBP+0; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 'pwe3' Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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: Thu, 02 Apr 2009 18:51:46 -0000 Please will the authors clarify the IPR position. Stewart Shahram Davari wrote: > Hi Stewart > > Could you please clarify whether there is any patent claim related to this > draft or not? > > Thanks, > Shahram > > > > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Stewart Bryant > Sent: Thursday, April 02, 2009 1:09 PM > To: pwe3 > Subject: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? > > The authors of draft-martini-pwe3-iccp-01.txt > > http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt > > have requested that this become a PWE3 WG document. > > Please can you send comments to the list by 20th April so that the > chairs can judge consensus. > > Thanks > > Stewart > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > From tom.nadeau@bt.com Thu Apr 2 11:57:02 2009 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 3AA4C3A6D31 for ; Thu, 2 Apr 2009 11:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] 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 8tf2SV7TYtQZ for ; Thu, 2 Apr 2009 11:57:01 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 2E60C3A686A for ; Thu, 2 Apr 2009 11:57:01 -0700 (PDT) Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.103]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 19:58:02 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Apr 2009 18:57:15 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 02 Apr 2009 14:57:14 -0400 From: "Thomas D. Nadeau" To: Stewart Bryant , Message-ID: Thread-Topic: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? Thread-Index: AcmzxNXgxW4cwO7+dk+apQr/VOd+9A== In-Reply-To: <49D5097D.1010806@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Apr 2009 18:58:02.0301 (UTC) FILETIME=[F2AAC6D0:01C9B3C4] Cc: 'pwe3' Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 02 Apr 2009 18:57:02 -0000 There are no claims from BT. --Tom On 4/2/09 2:52 PM, "Stewart Bryant" wrote: > Please will the authors clarify the IPR position. > > Stewart > > Shahram Davari wrote: >> Hi Stewart >> >> Could you please clarify whether there is any patent claim related to this >> draft or not? >> >> Thanks, >> Shahram >> >> >> >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >> Stewart Bryant >> Sent: Thursday, April 02, 2009 1:09 PM >> To: pwe3 >> Subject: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? >> >> The authors of draft-martini-pwe3-iccp-01.txt >> >> http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt >> >> have requested that this become a PWE3 WG document. >> >> Please can you send comments to the list by 20th April so that the >> chairs can judge consensus. >> >> Thanks >> >> Stewart >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> >> >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 -- Principal Architect - 21CN Networks From rrahman@cisco.com Thu Apr 2 12:14:10 2009 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 D9A543A6D3D for ; Thu, 2 Apr 2009 12:14:10 -0700 (PDT) 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 x4P+VnQNmTZr for ; Thu, 2 Apr 2009 12:14:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CD2EC3A6D16 for ; Thu, 2 Apr 2009 12:14:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,315,1235952000"; d="scan'208";a="165803550" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-1.cisco.com with ESMTP; 02 Apr 2009 19:14:59 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n32JExQG009186 for ; Thu, 2 Apr 2009 15:14:59 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n32JExhT016520 for ; Thu, 2 Apr 2009 19:14:59 GMT Received: from xmb-rtp-214.amer.cisco.com ([64.102.31.75]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 15:14:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 15:14:57 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? Thread-Index: AcmzxNXgxW4cwO7+dk+apQr/VOd+9AAAmu4g References: <49D5097D.1010806@cisco.com> From: "Reshad Rahman (rrahman)" To: "pwe3" X-OriginalArrivalTime: 02 Apr 2009 19:14:59.0726 (UTC) FILETIME=[511982E0:01C9B3C7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1905; t=1238699699; x=1239563699; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrahman@cisco.com; z=From:=20=22Reshad=20Rahman=20(rrahman)=22=20 |Subject:=20RE=3A=20[PWE3]=20Should=20draft-martini-pwe3-ic cp-01=20be=20a=20WG=20doc? |Sender:=20 |To:=20=22pwe3=22=20; bh=v8tovw2atP9W0eBHJm0at45qbbsyK70J1HXviuN5DTc=; b=lqqO0n0BYexRNntZONr77MFX9jESuZfoZ2xsFlucw3SspM65oGu4xdXqXl 442mlg4LYSn1rr4Olsn3KQfC55eGMau578GvwHW+EZpeJZCQHjUhP5Sv5aMX OQln74ML2C; Authentication-Results: rtp-dkim-1; header.From=rrahman@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 02 Apr 2009 19:14:10 -0000 Support. -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Thomas D. Nadeau Sent: Thursday, April 02, 2009 2:57 PM To: Stewart Bryant (stbryant); davarish@yahoo.com Cc: 'pwe3' Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? There are no claims from BT. --Tom On 4/2/09 2:52 PM, "Stewart Bryant" wrote: > Please will the authors clarify the IPR position. >=20 > Stewart >=20 > Shahram Davari wrote: >> Hi Stewart >>=20 >> Could you please clarify whether there is any patent claim related to >> this draft or not? >>=20 >> Thanks, >> Shahram >>=20 >>=20 >>=20 >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf=20 >> Of Stewart Bryant >> Sent: Thursday, April 02, 2009 1:09 PM >> To: pwe3 >> Subject: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? >>=20 >> The authors of draft-martini-pwe3-iccp-01.txt >>=20 >> http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt >>=20 >> have requested that this become a PWE3 WG document. >>=20 >> Please can you send comments to the list by 20th April so that the=20 >> chairs can judge consensus. >>=20 >> Thanks >>=20 >> Stewart >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >>=20 >>=20 >> =20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 -- Principal Architect - 21CN Networks _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From lmartini@cisco.com Thu Apr 2 12:30:31 2009 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 627683A6A6E for ; Thu, 2 Apr 2009 12:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 UJszwJxYiaLa for ; Thu, 2 Apr 2009 12:30:30 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [67.41.208.110]) by core3.amsl.com (Postfix) with ESMTP id 7143C3A6CE0 for ; Thu, 2 Apr 2009 12:30:30 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id n32JVO9f008058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 13:31:25 -0600 (MDT) Message-ID: <49D5128C.4040702@cisco.com> Date: Thu, 02 Apr 2009 13:31:24 -0600 From: Luca Martini User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: stbryant@cisco.com References: <49D4F11A.1020905@cisco.com> <87AC5F88F03E6249AEA68D40BD3E00BE193A8325@zcarhxm2.corp.nortel.com> <005201c9b3bc$691028a0$3b3079e0$@com> <49D5097D.1010806@cisco.com> In-Reply-To: <49D5097D.1010806@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 209.245.27.1 Cc: 'pwe3' , davarish@yahoo.com Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 02 Apr 2009 19:30:31 -0000 Stewart Bryant wrote: > Please will the authors clarify the IPR position. > > Stewart > > Shahram Davari wrote: >> Hi Stewart >> >> Could you please clarify whether there is any patent claim related to >> this >> draft or not? No , No patent claim has been filed at this time. Luca >> Thanks, >> Shahram >> >> >> >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >> Stewart Bryant >> Sent: Thursday, April 02, 2009 1:09 PM >> To: pwe3 >> Subject: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? >> >> The authors of draft-martini-pwe3-iccp-01.txt >> >> http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt >> >> have requested that this become a PWE3 WG document. >> >> Please can you send comments to the list by 20th April so that the >> chairs can judge consensus. >> >> Thanks >> >> Stewart >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> >> >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From danny@tcb.net Thu Apr 2 12:56:33 2009 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 799093A6D5F for ; Thu, 2 Apr 2009 12:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] 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 aNSVp8SXRBA2 for ; Thu, 2 Apr 2009 12:56:32 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id C23723A6A6E for ; Thu, 2 Apr 2009 12:56:32 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 99FB62684EA; Thu, 2 Apr 2009 13:57:34 -0600 (MDT) Received: from jchouinard-sim-102.eng.ellacoya.com (97-122-114-19.hlrn.qwest.net [97.122.114.19]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for pwe3@ietf.org; Thu, 02 Apr 2009 13:57:34 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.114.19; client-port=59972; syn-fingerprint=65535:55:1:64:M1408,N,W3,N,N,T,S; data-bytes=0 Message-Id: <5D71770F-B966-485B-A7CA-B5647B1ABA70@tcb.net> From: Danny McPherson To: pwe3 In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE193A8325@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 13:57:33 -0600 References: <49D4F11A.1020905@cisco.com> <87AC5F88F03E6249AEA68D40BD3E00BE193A8325@zcarhxm2.corp.nortel.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 02 Apr 2009 19:56:33 -0000 On Apr 2, 2009, at 11:17 AM, David Allan wrote: > Comment that most resonated with me in Dublin was "how frequently > would > mirrored nodes be multi-vendor", implying minimal interest from anyone > in standardizing this... The Dublin meeting minutes don't seem to support your statement above. Specifically, while the minutes are somewhat ambiguous as to the source, they do state "Several proprietary versions floating around, but providers want standardized version." I believe that was Luca [graciously proxying in his usual fashion for what providers want :-)], but it seems a valid point to me. In regard to your question, it's certainly safe to assume the answer is "MUCH LESS frequently absent a mechanism such as ICCP". -danny From DALLAN@nortel.com Thu Apr 2 13:17:22 2009 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 0BF4C3A6C62 for ; Thu, 2 Apr 2009 13:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 5ZRs4ankf35Z for ; Thu, 2 Apr 2009 13:17:21 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 1337A3A6B73 for ; Thu, 2 Apr 2009 13:17:20 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n32KIJ129542; Thu, 2 Apr 2009 20:18:19 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 16:17:53 -0400 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE193A8333@zcarhxm2.corp.nortel.com> In-Reply-To: <5D71770F-B966-485B-A7CA-B5647B1ABA70@tcb.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? Thread-Index: AcmzzUxVPztpM1wvRUGPwMe5QHIqCwAARyIw References: <49D4F11A.1020905@cisco.com><87AC5F88F03E6249AEA68D40BD3E00BE193A8325@zcarhxm2.corp.nortel.com> <5D71770F-B966-485B-A7CA-B5647B1ABA70@tcb.net> From: "David Allan" To: "Danny McPherson" , "pwe3" Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 02 Apr 2009 20:17:22 -0000 My meeting notes do not provide an attribution either ... It was simply the comment at the mike that stood out to me that best summarized and explained the apparent ambivilance of the room at the time.... If there is more to this than "gracious proxying of desire..." then I have no objections... ;-) D -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Danny McPherson Sent: Thursday, April 02, 2009 3:58 PM To: pwe3 Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? On Apr 2, 2009, at 11:17 AM, David Allan wrote: > Comment that most resonated with me in Dublin was "how frequently=20 > would mirrored nodes be multi-vendor", implying minimal interest from=20 > anyone in standardizing this... The Dublin meeting minutes don't seem to support your statement above. Specifically, while the minutes are somewhat ambiguous as to the source, they do state "Several proprietary versions floating around, but providers want standardized version." I believe that was Luca [graciously proxying in his usual fashion for what providers want :-)], but it seems a valid point to me. In regard to your question, it's certainly safe to assume the answer is "MUCH LESS frequently absent a mechanism such as ICCP". -danny _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From tom.nadeau@bt.com Thu Apr 2 13:45:51 2009 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 3B2DB3A6A6E for ; Thu, 2 Apr 2009 13:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] 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 lEU7He8zs6Kq for ; Thu, 2 Apr 2009 13:45:50 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 3DD643A6B3C for ; Thu, 2 Apr 2009 13:45:50 -0700 (PDT) Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.103]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 21:46:51 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Apr 2009 20:46:10 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 02 Apr 2009 16:46:08 -0400 From: "Thomas D. Nadeau" To: Danny McPherson , pwe3 Message-ID: Thread-Topic: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? Thread-Index: Acmz1AxxSPAsc+01fkevnoMe9KJCVg== In-Reply-To: <5D71770F-B966-485B-A7CA-B5647B1ABA70@tcb.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Apr 2009 20:46:51.0410 (UTC) FILETIME=[2651BF20:01C9B3D4] Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 02 Apr 2009 20:45:51 -0000 On 4/2/09 3:57 PM, "Danny McPherson" wrote: > > On Apr 2, 2009, at 11:17 AM, David Allan wrote: > >> Comment that most resonated with me in Dublin was "how frequently >> would >> mirrored nodes be multi-vendor", implying minimal interest from anyone >> in standardizing this... > > > The Dublin meeting minutes don't seem to support your statement > above. Specifically, while the minutes are somewhat ambiguous as > to the source, they do state "Several proprietary versions floating > around, but providers want standardized version." I believe that > was Luca [graciously proxying in his usual fashion for what providers > want :-)], but it seems a valid point to me. And I've clarified this, at least from one current operator using PWE3s. *) --Tom > In regard to your question, it's certainly safe to assume the answer > is "MUCH LESS frequently absent a mechanism such as ICCP". > > -danny > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 -- Principal Architect - 21CN Networks From nitinb@juniper.net Thu Apr 2 15:15:03 2009 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 6FFEA3A6A71 for ; Thu, 2 Apr 2009 15:15:03 -0700 (PDT) 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 j2P+ZvyIBCrN for ; Thu, 2 Apr 2009 15:15:02 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 304573A67A1 for ; Thu, 2 Apr 2009 15:14:51 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSdU5GQffLB5sAMWiV/n/t+9VREWdRjKk@postini.com; Thu, 02 Apr 2009 15:16:04 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 2 Apr 2009 15:13:20 -0700 Received: from emailcorp3.jnpr.net ([66.129.254.13]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 15:13:20 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 15:13:19 -0700 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E040E2121@emailcorp3.jnpr.net> In-Reply-To: <49D5097D.1010806@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? Thread-Index: AcmzxDnl+0tDp8v1TZyZNkbqdzbKDAAG0oUw References: <49D4F11A.1020905@cisco.com><87AC5F88F03E6249AEA68D40BD3E00BE193A8325@zcarhxm2.corp.nortel.com><005201c9b3bc$691028a0$3b3079e0$@com> <49D5097D.1010806@cisco.com> From: Nitin Bahadur To: X-OriginalArrivalTime: 02 Apr 2009 22:13:20.0524 (UTC) FILETIME=[3B45B4C0:01C9B3E0] Cc: pwe3 Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 02 Apr 2009 22:15:03 -0000 The draft addresses a good problem, but having it's applicability just to PW/LDP doesn't make sense. The transport mechansim for ICCP should be TCP and not LDP IMO. Then the draft and procedures can be used by any protocol that wants ICCP like behavior. Are we going the route of trying to come up with different standards for different inter-chassis communication needs? If yes, then I (personally), would rather come up with a proprietary solution that solves all my ICC needs using a single protocol. My 2 cents (speaking as an individual) Nitin > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]=20 > On Behalf=20 > > Of Stewart Bryant > > Sent: Thursday, April 02, 2009 1:09 PM > > To: pwe3 > > Subject: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? > > > > The authors of draft-martini-pwe3-iccp-01.txt > > > > http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt > > > > have requested that this become a PWE3 WG document. > > > > Please can you send comments to the list by 20th April so that the=20 > > chairs can judge consensus. > > > > Thanks > > > > Stewart From y.kamite@ntt.com Thu Apr 2 20:37:32 2009 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 29AF43A6962 for ; Thu, 2 Apr 2009 20:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 epb7RP8MYCcR for ; Thu, 2 Apr 2009 20:37:31 -0700 (PDT) Received: from mgw3.noc.ntt.com (mgw3.noc.ntt.com [210.160.15.14]) by core3.amsl.com (Postfix) with ESMTP id 3BCE33A6B67 for ; Thu, 2 Apr 2009 20:37:31 -0700 (PDT) Received: from mop1.noc.ntt.com by mgw3.noc.ntt.com (NTT-Com MailSV) with ESMTP id n333cVgx024726 for ; Fri, 3 Apr 2009 12:38:31 +0900 (JST) Received: from mip02.noc.ntt.com (mvi3.noc.ntt.com) by mop1.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0KHI002QRA42X0@ntt.com> for pwe3@ietf.org; Fri, 03 Apr 2009 12:38:31 +0900 (JST) Date: Fri, 03 Apr 2009 12:34:35 +0900 From: "Yuji KAMITE" In-reply-to: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> To: pwe3@ietf.org Message-id: <006001c9b40d$1c21ee10$b3d80e0a@coe.ntt.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1933 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: Acmx9uZY0mmoKvLIT1OqXckF2OpOJgCFSalA References: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? 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, 03 Apr 2009 03:37:32 -0000 Support. - Yuji ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: Tuesday, March 31, 2009 8:51 PM To: pwe3@ietf.org Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? This is the start of a two week poll to judge the consensus to move draft-bryant-filsfils-fat-pw-03 to a PWE3 Working Group draft. Please can you respond to the PWE3 list with your approval (or otherwise). This poll will close on 14th April 2009. Regards Matthew From y.kamite@ntt.com Thu Apr 2 20:39:47 2009 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 AF29C3A69F1 for ; Thu, 2 Apr 2009 20:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 0wDQqsUAPjPf for ; Thu, 2 Apr 2009 20:39:46 -0700 (PDT) Received: from mgw3.noc.ntt.com (mgw3.noc.ntt.com [210.160.15.14]) by core3.amsl.com (Postfix) with ESMTP id 969723A685E for ; Thu, 2 Apr 2009 20:39:46 -0700 (PDT) Received: from mop3.noc.ntt.com by mgw3.noc.ntt.com (NTT-Com MailSV) with ESMTP id n333emch024887 for ; Fri, 3 Apr 2009 12:40:48 +0900 (JST) Received: from mip02.noc.ntt.com (mvi2.noc.ntt.com) by mop3.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0KHI00H7AA80U5@ntt.com> for pwe3@ietf.org; Fri, 03 Apr 2009 12:40:48 +0900 (JST) Date: Fri, 03 Apr 2009 12:37:59 +0900 From: "Yuji KAMITE" In-reply-to: <49D4F11A.1020905@cisco.com> To: pwe3@ietf.org Message-id: <006101c9b40d$95dc0a10$b3d80e0a@coe.ntt.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1933 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Thread-index: AcmztgEPDu4z2nnlSS6DC36r2+XgLAAVLW8w References: <49D4F11A.1020905@cisco.com> Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 03 Apr 2009 03:39:47 -0000 I support this as very valuable work in general, as I believe most SPs now will have desire for multi-vendor possibility that supports redundancy. However, I still have questions and a little concern. Clarification is expected: - It looks like the current drafts focuses on mLACP a lot, but I'm wondering if this fully explains what this mechanism means in reality in terms of PW's native service (e.g., description about LAG forwarding behavior is missing). It needs to distinguish between PW-specific part (from the view of operators) and Ethernet MAC/PHY-specific part (from the view of CE), because the current draft seems to be mixing them up. Also this is also the case in other applications (multi-chassis APS etc.). - I couldn't find any statement why LDP is used for underlying protocol. The proposed method doesn't advertise any labels. Does ICCP has no relationship with data-path between redundant PEs? Please elaborate if there is any specific requirement or rationale from the view of protocol design, to adopt LDP. - This might be editorial, but it might be better to split more distinctly the common protocol part and the application-specific behavior and its TLVs (whether or not they are sepcified in one document). Best regards, -Yuji > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf Of Stewart Bryant > Sent: Friday, April 03, 2009 2:09 AM > To: pwe3 > Subject: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? > > The authors of draft-martini-pwe3-iccp-01.txt > > http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt > > have requested that this become a PWE3 WG document. > > Please can you send comments to the list by 20th April so > that the chairs can judge consensus. > > Thanks > > Stewart > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From jiang.xiaowei@zte.com.cn Fri Apr 3 00:09:22 2009 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 D46043A682D for ; Fri, 3 Apr 2009 00:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 MMt5hg9pwYl2 for ; Fri, 3 Apr 2009 00:09:21 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 4C6353A68A6 for ; Fri, 3 Apr 2009 00:08:19 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91101397396305; Fri, 3 Apr 2009 15:03:14 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 90033.3171924358; Fri, 3 Apr 2009 15:06:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n3378nb5015536; Fri, 3 Apr 2009 15:08:49 +0800 (CST) (envelope-from jiang.xiaowei@zte.com.cn) In-Reply-To: <424CDC689E5CEF4D9FEADE56A378D922021B07BAAB@exrad4.ad.rad.co.il> To: stbryant@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: jiang.xiaowei@zte.com.cn Date: Fri, 3 Apr 2009 15:08:29 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-03 15:08:53, Serialize by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-03 15:08:53, Serialize complete at 2009-04-03 15:08:53, S/MIME Sign failed at 2009-04-03 15:08:53: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-03 15:08:37, Serialize complete at 2009-04-03 15:08:37 Content-Type: multipart/alternative; boundary="=_alternative 002744344825758D_=" X-MAIL: mse1.zte.com.cn n3378nb5015536 Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? 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, 03 Apr 2009 07:09:22 -0000 This is a multipart message in MIME format. --=_alternative 002744344825758D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U2lyLA0KDQpDb3VsZCByZmM0NjE4IEVuY2Fwc3VsYXRpb24gTWV0aG9kcyBmb3IgVHJhbnNwb3J0 IG9mIFBQUC9IaWdoLUxldmVsIERhdGEgDQpMaW5rIENvbnRyb2wgKEhETEMpIG92ZXIgTVBMUyBO ZXR3b3JrcyANCmJlIHVzZWQgYXMgYSBzb2x1dGlvbiBmb3IgdGhlIHNjZW5hcmlvIGluIHRoaXMg ZHJhZnQ/IChhbHRob3VnaCBoYXZlIG1vcmUgDQplbmNhcHN1bGF0aW9uIG92ZXJoZWFkKQ0KDQpU aGFuayB5b3UhDQoNCg0KDQoNCllhYWtvdiBTdGVpbiA8eWFha292X3NAcmFkLmNvbT4gDQq3orz+ yMs6ICBwd2UzLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMDktMDQtMDIgMDE6NDkNCg0KytW8/sjLDQoi cHdlM0BpZXRmLm9yZyIgPHB3ZTNAaWV0Zi5vcmc+DQqzrcvNDQoNCtb3zOINClJlOiBbUFdFM10g ZHJhZnQtYnJ5YW50LXB3ZTMtcGFja2V0LXB3LTAwLnR4dCB0byBXRyBkcmFmdD8NCg0KDQoNCg0K DQoNCkkgc3VwcG9ydCwgYnV0IHN0cm9uZ2x5IGRvIE5PVCBzdXBwb3J0IHRoZSBuYW1lLg0KIA0K InBhY2tldCBQVyIgZG9lcyBub3QgbWVhbiBhbnl0aGluZyB0byBtZS4gRG8gdGhlIG90aGVyIGVu Y2FwcyBub3QgDQp0cmFuc3BvcnQgcGFja2V0cyA/DQpEb2VzIHRoaXMgb25lIG9ubHkgdHJhbnNw b3J0IHBhY2tldHMgKGFuZCBub3QgZS5nLiwgZnJhbWVzPykNCiANCkhvdyBhYm91dCAiaW50ZXJm YWNlIHRyYWZmaWMgUFciIG9yICJnZW5lcmljIHRyYWZmaWMgUFciID8NCiANClRoZSBsYXR0ZXIg bmFtZSAiZ2VuZXJpYyBQVyIgd2FzIHRoZSBuYW1lIHRoYXQgd2FzIHVzZWQNCndoZW4gdGhpcyBz YW1lIGlkZWEgd2FzIGRlc2NyaWJlZCBhIGZldyB5ZWFycyBhZ28NCihzZWUgdG8gbG9jayBvbnRv IHRoZSB0aHJlYWQgDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcHdlMy9j dXJyZW50L21zZzA4MDcwLmh0bWwgKQ0KIA0KWShKKVMNCiANCiANCjIwMDkvMy8zMSBCT0NDSSBN YXR0aGV3IDxNYXR0aGV3LkJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbT4NClRoaXMgaXMgdGhlIHN0 YXJ0IG9mIGEgdHdvIHdlZWsgcG9sbCB0byBqdWRnZSB0aGUgY29uc2Vuc3VzIHRvIG1vdmUgDQpk cmFmdC1icnlhbnQtcHdlMy1wYWNrZXQtcHctMDAudHh0IHRvIGEgUFdFMyBXb3JraW5nIEdyb3Vw IGRyYWZ0Lg0KUGxlYXNlIGNhbiB5b3UgcmVzcG9uZCwgKnRvIHRoZSBQV0UzIGxpc3Qgb25seSos IHdpdGggeW91ciBhcHByb3ZhbCAob3IgDQpvdGhlcndpc2UpLiANClRoaXMgcG9sbCB3aWxsIGNs b3NlIG9uIDE0dGggQXByaWwgMjAwOS4gDQpSZWdhcmRzIA0KTWF0dGhldyANCiANCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnB3ZTMgbWFpbGluZyBs aXN0DQpwd2UzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3B3ZTMNCiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K cHdlMyBtYWlsaW5nIGxpc3QNCnB3ZTNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcHdlMw0KDQoNCg== --=_alternative 002744344825758D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNpciw8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNvdWxkIHJmYzQ2MTggRW5jYXBzdWxh dGlvbiBNZXRob2RzDQpmb3IgVHJhbnNwb3J0IG9mIFBQUC9IaWdoLUxldmVsIERhdGEgTGluayBD b250cm9sIChIRExDKSBvdmVyIE1QTFMgTmV0d29ya3MNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YmUgdXNlZCBh cyBhIHNvbHV0aW9uIGZvciB0aGUgc2NlbmFyaW8NCmluIHRoaXMgZHJhZnQ/IChhbHRob3VnaCBo YXZlIG1vcmUgZW5jYXBzdWxhdGlvbiBvdmVyaGVhZCk8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rIHlvdSE8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRo PTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+WWFha292IFN0ZWluICZsdDt5 YWFrb3Zfc0ByYWQuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtwd2UzLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8 cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wNC0wMiAwMTo0OTwvZm9udD4N Cjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjL PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtw d2UzQGlldGYub3JnJnF1b3Q7ICZsdDtwd2UzQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtQV0UzXSBkcmFm dC1icnlhbnQtcHdlMy1wYWNrZXQtcHctMDAudHh0DQp0byBXRyBkcmFmdD88L2ZvbnQ+PC90YWJs ZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8 YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3ZCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPkkgc3VwcG9ydCwgYnV0IHN0cm9uZ2x5DQpkbyBOT1Qgc3Vw cG9ydCB0aGUgbmFtZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2QgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9y PSMxZjQ5N2QgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mcXVvdDtwYWNrZXQgUFcmcXVvdDsNCmRv ZXMgbm90IG1lYW4gYW55dGhpbmcgdG8gbWUuIERvIHRoZSBvdGhlciBlbmNhcHMgbm90IHRyYW5z cG9ydCBwYWNrZXRzDQo/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+RG9lcyB0aGlzIG9uZSBvbmx5DQp0cmFuc3BvcnQgcGFja2V0 cyAoYW5kIG5vdCBlLmcuLCBmcmFtZXM/KTwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9 IzFmNDk3ZCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz aXplPTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkhvdyBhYm91dCAmcXVv dDtpbnRlcmZhY2UNCnRyYWZmaWMgUFcmcXVvdDsgb3IgJnF1b3Q7Z2VuZXJpYyB0cmFmZmljIFBX JnF1b3Q7ID88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2QgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5 N2QgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5UaGUgbGF0dGVyIG5hbWUgJnF1b3Q7Z2VuZXJpYw0K UFcmcXVvdDsgd2FzIHRoZSBuYW1lIHRoYXQgd2FzIHVzZWQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0zIGNvbG9yPSMxZjQ5N2QgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj53aGVuIHRoaXMgc2FtZSBp ZGVhDQp3YXMgZGVzY3JpYmVkIGEgZmV3IHllYXJzIGFnbzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPihzZWUgdG8gbG9jayBvbnRv DQp0aGUgdGhyZWFkIDwvZm9udD48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvcHdlMy9jdXJyZW50L21zZzA4MDcwLmh0bWwiPjxmb250IHNpemU9MyBjb2xvcj1i bHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL3B3ZTMvY3VycmVudC9tc2cwODA3MC5odG1sPC91PjwvZm9udD48L2E+PGZvbnQg c2l6ZT0zIGNvbG9yPSMxZjQ5N2QgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCik8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2QgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2QgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj5ZKEopUzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3ZCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9 IzFmNDk3ZCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4yMDA5LzMvMzEgQk9DQ0kgTWF0dGhldyAmbHQ7 PC9mb250PjxhIGhyZWY9Im1haWx0bzpNYXR0aGV3LkJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbSI+ PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48dT5NYXR0aGV3 LkJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPiZndDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPlRoaXMgaXMgdGhlIHN0YXJ0IG9mIGEgdHdvIHdlZWsgcG9sbCB0byBqdWRnZQ0KdGhlIGNv bnNlbnN1cyB0byBtb3ZlIGRyYWZ0LWJyeWFudC1wd2UzLXBhY2tldC1wdy0wMC50eHQgdG8gYSBQ V0UzIFdvcmtpbmcNCkdyb3VwIGRyYWZ0LjwvZm9udD4NCjxwPjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+UGxlYXNlIGNhbiB5b3UgcmVzcG9uZCwgKnRvIHRoZSBQV0UzIGxpc3QNCm9ubHkqLCB3 aXRoIHlvdXIgYXBwcm92YWwgKG9yIG90aGVyd2lzZSkuPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij5UaGlzIHBvbGwgd2lsbCBjbG9zZSBvbiAxNHRoIEFwcmlsIDIwMDkuPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj5SZWdhcmRzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5NYXR0aGV3PC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnB3ZTMgbWFpbGluZyBsaXN0PC9mb250Pjxm b250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+PGJyPg0KPC91 PjwvZm9udD48YSBocmVmPW1haWx0bzpwd2UzQGlldGYub3JnPjxmb250IHNpemU9MyBjb2xvcj1i bHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+cHdlM0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9h Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+PGJyPg0K PC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cHdlMyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzPC91 PjwvZm9udD48L2E+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5i c3A7PC9mb250Pjxmb250IHNpemU9Mj48dHQ+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpwd2UzIG1haWxpbmcgbGlzdDxicj4NCnB3ZTNAaWV0Zi5v cmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTM8YnI+DQo8 L3R0PjwvZm9udD4NCjxicj4NCg== --=_alternative 002744344825758D_=-- From frederic.jounay@orange-ftgroup.com Fri Apr 3 00:13:33 2009 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 C62E03A68A6 for ; Fri, 3 Apr 2009 00:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 prym0P29s0Yj for ; Fri, 3 Apr 2009 00:13:33 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id A37123A65A6 for ; Fri, 3 Apr 2009 00:13:32 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 09:14:34 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 09:14:33 +0200 Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A155FF104@ftrdmel2> In-Reply-To: <006101c9b40d$95dc0a10$b3d80e0a@coe.ntt.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? Thread-Index: AcmztgEPDu4z2nnlSS6DC36r2+XgLAAVLW8wAAg/wCA= References: <49D4F11A.1020905@cisco.com> <006101c9b40d$95dc0a10$b3d80e0a@coe.ntt.com> From: To: X-OriginalArrivalTime: 03 Apr 2009 07:14:34.0745 (UTC) FILETIME=[D76A9690:01C9B42B] Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 03 Apr 2009 07:13:33 -0000 Support. Fred > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf=20 > Of Stewart Bryant > Sent: Friday, April 03, 2009 2:09 AM > To: pwe3 > Subject: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? >=20 > The authors of draft-martini-pwe3-iccp-01.txt >=20 > http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt >=20 > have requested that this become a PWE3 WG document. >=20 > Please can you send comments to the list by 20th April so that the=20 > chairs can judge consensus. >=20 > Thanks >=20 > Stewart > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From Matthew.Bocci@alcatel-lucent.com Fri Apr 3 02:09:25 2009 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 3D6FA3A6358 for ; Fri, 3 Apr 2009 02:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.053 X-Spam-Level: X-Spam-Status: No, score=-5.053 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MANGLED_EXTNSN=2.3, 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 n7Job38v66kh for ; Fri, 3 Apr 2009 02:09:24 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 3418A3A6979 for ; Fri, 3 Apr 2009 02:09:24 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n339AKgC007108 for ; Fri, 3 Apr 2009 11:10:25 +0200 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 11:10:24 +0200 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_01C9B43C.0585F177" Date: Fri, 3 Apr 2009 11:10:23 +0200 Message-ID: <0458D2EE0C36744BABB36BE37805C29A03930C40@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L2tpext WG last call on draft-ietf-l2tpext-circuit-status-extensions-03.txt Thread-Index: Acm0PAUf4KQIs4kJQAutePOoxDUR4w== From: "BOCCI Matthew" To: X-OriginalArrivalTime: 03 Apr 2009 09:10:24.0078 (UTC) FILETIME=[058AA6E0:01C9B43C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [PWE3] L2tpext WG last call on draft-ietf-l2tpext-circuit-status-extensions-03.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: Fri, 03 Apr 2009 09:09:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B43C.0585F177 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This is a heads-up that there is a working group last call in L2tpext for the following draft: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-circuit-status-ex tensions-03.txt The LC ends on 10th April. Please review the draft and address any comments to the L2tpext list. Regards Matthew ------_=_NextPart_001_01C9B43C.0585F177 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable L2tpext WG last call on = draft-ietf-l2tpext-circuit-status-extensions-03.txt

Folks,

This is a heads-up that there is a = working group last call in L2tpext for the following draft:

http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-cir= cuit-status-extensions-03.txt

The LC ends on 10th April.

Please review the draft and address any = comments to the L2tpext list.

Regards

Matthew

------_=_NextPart_001_01C9B43C.0585F177-- From Edwin.Mallette@bhnis.com Fri Apr 3 06:18:15 2009 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 6F7AC3A681F for ; Fri, 3 Apr 2009 06:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.373, 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 MMcRHSFY+ILb for ; Fri, 3 Apr 2009 06:18:14 -0700 (PDT) Received: from mx2.mybrighthouse.com (MX2.mybrighthouse.com [209.16.122.104]) by core3.amsl.com (Postfix) with ESMTP id B44E43A6E0A for ; Fri, 3 Apr 2009 06:18:11 -0700 (PDT) Received: from cntpacas2.corp.local ([10.225.1.125]) by mx2.mybrighthouse.com (8.14.1/8.14.1) with ESMTP id n33DJ9Pw009034 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 3 Apr 2009 09:19:09 -0400 Received: from CNEMAIL.corp.local ([10.225.1.128]) by cntpacas2.corp.local ([10.225.1.125]) with mapi; Fri, 3 Apr 2009 09:19:09 -0400 From: "Mallette, Edwin" To: "Thomas D. Nadeau" , Stewart Bryant , pwe3 Date: Fri, 3 Apr 2009 09:19:07 -0400 Thread-Topic: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? Thread-Index: Acmzthrw3LRxxTp2RcW+PAjuVJIAHAAAEP9gAABQPywAKapsgA== Message-ID: References: <87AC5F88F03E6249AEA68D40BD3E00BE193A8325@zcarhxm2.corp.nortel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0904030071 Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 03 Apr 2009 13:18:15 -0000 I concur with Tom here. As a multiservice operator we also have a high deg= ree of interest in multivendor interop for mc-LAG, mc-APS functions which t= his draft enables. -Ed -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Tho= mas D. Nadeau Sent: Thursday, April 02, 2009 1:23 PM To: David Allan; Stewart Bryant; pwe3 Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? On 4/2/09 1:17 PM, "David Allan" wrote: > Hi Stewart > > Comment that most resonated with me in Dublin was "how frequently would > mirrored nodes be multi-vendor", implying minimal interest from anyone > in standardizing this... Speaking as a service provider interested in providing multi-vendor interoperability on this function, I'd disagree that there is minimal interest in standardizing this. I build and deploy multi-vendor networks an= d need this feature to work on different platforms. There might not be interest from vendors like youself (although the three I use are), having spoken to other colleagues on the SP side, they are interested. I hope they chime in on this thread to this effect. --Tom > That seemed to be group consensus at the time, what has changed? > > Cheers > Dave > > > > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Stewart Bryant > Sent: Thursday, April 02, 2009 1:09 PM > To: pwe3 > Subject: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? > > The authors of draft-martini-pwe3-iccp-01.txt > > http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt > > have requested that this become a PWE3 WG document. > > Please can you send comments to the list by 20th April so that the > chairs can judge consensus. > > Thanks > > Stewart > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 -- Principal Architect - 21CN Networks _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile= ged, confidential or otherwise protected from disclosure. If you are not th= e intended recipient of this e-mail, please notify the sender immediately b= y return e-mail, purge it and do not disseminate or copy it. From hhelvoort@chello.nl Fri Apr 3 06:36:08 2009 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 4C08A3A690C for ; Fri, 3 Apr 2009 06:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 Otd50Z7bpjNt for ; Fri, 3 Apr 2009 06:36:07 -0700 (PDT) Received: from viefep24-int.chello.at (viefep24-int.chello.at [62.179.121.44]) by core3.amsl.com (Postfix) with ESMTP id 18A653A6D96 for ; Fri, 3 Apr 2009 06:36:06 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep12-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090403133609.SMQN12380.viefep12-int.chello.at@edge01.upc.biz> for ; Fri, 3 Apr 2009 15:36:09 +0200 Received: from McAsterix.local ([24.132.228.153]) by edge01.upc.biz with edge id b1c81b00N3KDBhC011c9fC; Fri, 03 Apr 2009 15:36:09 +0200 X-SourceIP: 24.132.228.153 Message-ID: <49D610C7.1070307@chello.nl> Date: Fri, 03 Apr 2009 15:36:07 +0200 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: pwe3 References: <49D4F11A.1020905@cisco.com> In-Reply-To: <49D4F11A.1020905@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 13:36:08 -0000 To the authors: What do you mean by "SONET APS" and where is it located in figure 1? I could not find any reference in the refence sections either. Regards, Huub. ===================== > The authors of draft-martini-pwe3-iccp-01.txt > > http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt > > have requested that this become a PWE3 WG document. > > Please can you send comments to the list by 20th April > so that the chairs can judge consensus. > > Thanks > > Stewart -- ================================================================ Always remember that you are unique...just like everyone else... From philippe.niger@orange-ftgroup.com Fri Apr 3 09:17:33 2009 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 9C6093A6D60 for ; Fri, 3 Apr 2009 09:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 4UVSz5ZdWz3r for ; Fri, 3 Apr 2009 09:17:33 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 7DAB73A68EA for ; Fri, 3 Apr 2009 09:17:31 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 18:18:32 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 18:18:23 +0200 Message-ID: In-Reply-To: <49D4F11A.1020905@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? Thread-Index: AcmztgI+ZO60I3TXQBC+6hGewxeX7AAwbLcw References: <49D4F11A.1020905@cisco.com> From: To: X-OriginalArrivalTime: 03 Apr 2009 16:18:33.0180 (UTC) FILETIME=[D57089C0:01C9B477] Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 03 Apr 2009 16:17:33 -0000 Support. Regards Philippe. -----Message d'origine----- De : pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] De la part de = Stewart Bryant Envoy=E9 : jeudi 2 avril 2009 19:09 =C0 : pwe3 Objet : [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? The authors of draft-martini-pwe3-iccp-01.txt http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt have requested that this become a PWE3 WG document. Please can you send comments to the list by 20th April so that the = chairs can judge consensus. Thanks Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From hshah@ciena.com Fri Apr 3 10:04:17 2009 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 66A673A6A78 for ; Fri, 3 Apr 2009 10:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46] 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 fzFU49edDDbN for ; Fri, 3 Apr 2009 10:04:16 -0700 (PDT) Received: from ripley.ciena.com (ripley.ciena.com [63.118.34.24]) by core3.amsl.com (Postfix) with ESMTP id 711A63A69FE for ; Fri, 3 Apr 2009 10:03:09 -0700 (PDT) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_A462B5_01C9B45C.AF4B0510" Date: Fri, 3 Apr 2009 13:04:11 -0400 Message-ID: <6535C9CED6F87446B41D20EF170F2362327F4A@mamxm01.ciena.com> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Importance: normal Priority: normal Thread-Topic: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? thread-index: Acmx9uZY0mmoKvLIT1OqXckF2OpOJgChWP5w References: <0458D2EE0C36744BABB36BE37805C29A0392FF6A@FRVELSMBS11.ad2.ad.alcatel.com> From: "Shah, Himanshu" To: "BOCCI Matthew" , X-OriginalArrivalTime: 03 Apr 2009 17:04:12.0644 (UTC) FILETIME=[36499240:01C9B47E] Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? 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, 03 Apr 2009 17:04:17 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_A462B5_01C9B45C.AF4B0510 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B47E.35B890E6" ------_=_NextPart_001_01C9B47E.35B890E6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I am skeptical about using this technique per say and wonder if a generic mechanism could solve this as well as any other problems,=20 now or future, proprietary extensions, etc etc. =20 The one I am thinking about is that of 'generic preamble'. The inclusion and size of preamble is signalled between two PEs during PW establishment where offset to where PW header (i.e. control word, if present) begins is exchanged. At dataplane level, egress PE peels off the preamble and either discards it or feeds it to the secret sauce processor. =20 The PEs can then use preamble for various cases including as flow handle for ECMP,=20 encryption keys, stats, timestamps, etc etc. =20 /himanshu ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: Tuesday, March 31, 2009 7:51 AM To: pwe3@ietf.org Subject: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? This is the start of a two week poll to judge the consensus to move draft-bryant-filsfils-fat-pw-03=20 to a PWE3 Working Group draft.=20 Please can you respond to the PWE3 list with your approval (or otherwise).=20 This poll will close on 14th April 2009.=20 Regards=20 Matthew=20 ------_=_NextPart_001_01C9B47E.35B890E6 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable draft-bryant-filsfils-fat-pw-03 to WG = draft?
I am skeptical about = using this=20 technique per say and wonder
if a generic = mechanism=20 could solve this as well as any other problems,=20
now or future, = proprietary=20 extensions, etc etc.
 
The one I am = thinking about is=20 that of 'generic preamble'.
The inclusion and = size of=20 preamble is signalled between two PEs
during PW = establishment where=20 offset to where PW header (i.e. control word, if = present)
begins is exchanged. = At dataplane=20 level, egress PE peels off the preamble
and either discards = it or feeds it=20 to the secret sauce processor.
 
The PEs can then use = preamble for=20 various cases including as flow handle for ECMP, =
encryption keys, = stats,=20 timestamps, etc etc.
 
/himanshu




From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI = Matthew
Sent:=20 Tuesday, March 31, 2009 7:51 AM
To: = pwe3@ietf.org
Subject:=20 [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?

This is the start of a two week poll to = judge the=20 consensus to move draft-bryant-filsfils-fat-pw-03
 to a PWE3 Working Group draft.

Please can you respond to the PWE3 list = with your=20 approval (or otherwise).

This poll will close on 14th April = 2009.

Regards

Matthew



------_=_NextPart_001_01C9B47E.35B890E6-- ------=_NextPart_000_A462B5_01C9B45C.AF4B0510 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= ------=_NextPart_000_A462B5_01C9B45C.AF4B0510-- From amalis@gmail.com Sat Apr 4 08:38:18 2009 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 0836F3A698A for ; Sat, 4 Apr 2009 08:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.678 X-Spam-Level: X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[AWL=-0.079, 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 P5gliI2J3VcG for ; Sat, 4 Apr 2009 08:38:17 -0700 (PDT) Received: from mail-qy0-f109.google.com (mail-qy0-f109.google.com [209.85.221.109]) by core3.amsl.com (Postfix) with ESMTP id 2BE173A690F for ; Sat, 4 Apr 2009 08:38:16 -0700 (PDT) Received: by qyk7 with SMTP id 7so66269qyk.29 for ; Sat, 04 Apr 2009 08:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ItMS2ML4F5BADnm2hdooL5PI0a1FuLPydZ/LKYSfhb4=; b=ZwLJPmxiPig71jzi77rYDSCWjF3f8cusH7dWWao1PfQlMjiGzkTTHfQrGJH8k2VLI3 1G8PB1BTkaBR1ZMnbQHBlsJpj/4hgHdIGeVJFaDrT+Eog1Su3C9IfiOfWNYX3t6TZUsg PxryD1JJjHG8loKC5IJLNBcfHp/NcAVRUC84I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uX1waITlY+kH2sQDqtiKJqywabFTIhqW/tntofu7fRN2lRyEMAuqD/v116Hi3d6a7E pmywE5C5CFlfU4C2JfOMcA6bMn+ueBjUbPX47quWOgkJTAZ5mB0FZ+wnWGklMT1sO791 ZY/3L9GkiUidum6mkNs3JthszOdBblh+Stm6s= MIME-Version: 1.0 In-Reply-To: References: <424CDC689E5CEF4D9FEADE56A378D922021B07BAAB@exrad4.ad.rad.co.il> Date: Sat, 4 Apr 2009 11:39:05 -0400 Received: by 10.224.6.82 with SMTP id 18mr2500287qay.1.1238859560365; Sat, 04 Apr 2009 08:39:20 -0700 (PDT) Message-ID: From: "Andrew G. Malis" To: jiang.xiaowei@zte.com.cn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, stbryant@cisco.com Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? 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, 04 Apr 2009 15:38:18 -0000 Jiang, Yes it could, but in addition to higher overhead it would also require running the PPP state machine and using PPP options. We wanted to keep this as simple as possible. Thanks, Andy 2009/4/3 : > > Sir, > > Could rfc4618 Encapsulation Methods for Transport of PPP/High-Level Data > Link Control (HDLC) over MPLS Networks > be used as a solution for the scenario in this draft? (although have more > encapsulation overhead) > > Thank you! From davarish@yahoo.com Thu Apr 2 10:55:54 2009 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 020F73A6C49 for ; Thu, 2 Apr 2009 10:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 vyYQqjn2Dsqi for ; Thu, 2 Apr 2009 10:55:53 -0700 (PDT) Received: from smtp131.rog.mail.re2.yahoo.com (smtp131.rog.mail.re2.yahoo.com [206.190.53.36]) by core3.amsl.com (Postfix) with SMTP id 0C5B53A68C8 for ; Thu, 2 Apr 2009 10:55:52 -0700 (PDT) Received: (qmail 33263 invoked from network); 2 Apr 2009 17:56:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=g+CRHGI9524v4sJqMr6y8JOcQx79TUBuF7t4c2Xdjgqha7ekhew9XFxpSuJ5noG4JWmuSIUcc4UdA00CXZZNirFqZT5Yk5bns5u2WeD+9oeE8gaGKpDyILHCgee4xRhy3gssSpyXg/wQCwADRkzOUoJOZg8HUaLbaXtTLt2RDsg= ; Received: from unknown (HELO ShahramPC) (davarish@99.238.119.231 with login) by smtp131.rog.mail.re2.yahoo.com with SMTP; 2 Apr 2009 17:56:54 -0000 X-YMail-OSG: 2_mzQDUVM1lV3Fl_UPD4zvziTJf6fII54JUCkRa9bgXrKhKklniFLj9d6mgSTB.OzQ-- X-Yahoo-Newman-Property: ymail-3 From: "Shahram Davari" To: , "'pwe3'" References: <49D4F11A.1020905@cisco.com> <87AC5F88F03E6249AEA68D40BD3E00BE193A8325@zcarhxm2.corp.nortel.com> In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE193A8325@zcarhxm2.corp.nortel.com> Date: Thu, 2 Apr 2009 13:56:54 -0400 Message-ID: <005201c9b3bc$691028a0$3b3079e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmzthrw3LRxxTp2RcW+PAjuVJIAHAAAEP9gAAF2OBA= Content-Language: en-ca X-Mailman-Approved-At: Sun, 05 Apr 2009 12:01:25 -0700 Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: davarish@yahoo.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 17:55:54 -0000 Hi Stewart Could you please clarify whether there is any patent claim related to this draft or not? Thanks, Shahram -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Thursday, April 02, 2009 1:09 PM To: pwe3 Subject: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? The authors of draft-martini-pwe3-iccp-01.txt http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt have requested that this become a PWE3 WG document. Please can you send comments to the list by 20th April so that the chairs can judge consensus. Thanks Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From lmartini@cisco.com Mon Apr 6 15:27:34 2009 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 5FEFA28C0F7 for ; Mon, 6 Apr 2009 15:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_23=0.6, SARE_WEOFFER=0.3] 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 hPCOr02RCd-E for ; Mon, 6 Apr 2009 15:27:31 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [67.41.208.110]) by core3.amsl.com (Postfix) with ESMTP id 9E3E33A67E3 for ; Mon, 6 Apr 2009 15:27:30 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id n36MS1Dr012487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Apr 2009 16:28:01 -0600 (MDT) Message-ID: <49DA81F1.1000908@cisco.com> Date: Mon, 06 Apr 2009 16:28:01 -0600 From: Luca Martini User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: stbryant@cisco.com References: <49B919B4.7090702@cisco.com> In-Reply-To: <49B919B4.7090702@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 209.245.27.1 Cc: pwe3 , draft-ietf-pwe3-segmented-pw@tools.ietf.org Subject: Re: [PWE3] Comments on draft-ietf-pwe3-segmented-pw-11.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, 06 Apr 2009 22:27:34 -0000 Thanks Stewart. Comments Below. Luca Stewart Bryant wrote: > > I have done a line by line review of > draft-ietf-pwe3-segmented-pw-11.txt and have a > number of comments. The overwhelming majority > of these are editorial but there are a few > technical questions most of which are > clarification issues. > > > I think that we need to proceed a follows: > > Please will the authors need to take a look > at my comments and address the text as necessary. > > Then I think that we need to do three things > > 1) Ask MPLS WG if they are happy with the > LDP material. > > 2) Ask L2TPext WG if they are happy with the > L2TP text. > > 3) A couple of other members if PWE3 WG need > to volunteer to read the next version in case > there is anything else that has been missed. > > - Stewart > > ======================================================= > > > Segmented Pseudowire > > > draft-ietf-pwe3-segmented-pw-11.txt > > > Abstract > > This document describes how to connect pseudowires (PW) between two > distinct PW control planes or PSN domains. The PW control planes may > belong to independent autonomous systems, or the PSN technology is > SB> technolgy may be hetrogeneous > 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. > SB> That is true for MPLS but MPLS <> L2TPv3 involves a little > SB> more - for example the frame relay formats are different. > > > > > 2. Terminology > > SB> This needs a reference to draft-ietf-pwe3-ms-pw-arch-06.txt > SB> I wonder if we need it here at all since we are going to > SB> have to make sure it survives the various editing rounds > SB> to pub remaining word for word identical to the above > SB> draft. > I would like to keep this here, since it makes the document readable. > - PW Terminating Provider Edge (T-PE). A PE where the customer- > facing attachment circuits (ACs) are bound to a PW forwarder. A > Terminating PE is present in the first and last segments of a > MS-PW. This incorporates the functionality of a PE as defined in > [RFC3985]. > > - Single-Segment Pseudowire (SS-PW). A PW setup directly between > two T-PE devices. Each PW in one direction of a SS-PW traverses > one PSN tunnel that connects the two T-PEs. > > - Multi-Segment Pseudowire (MS-PW). A static or dynamically > configured set of two or more contiguous PW segments that behave > and function as a single point-to-point PW. Each end of a MS-PW > by definition MUST terminate on a T-PE. > > SB> ... and to prove my point PW Segment, & S-PE have different > SB> definitions and PW Switching is not defined here but is defined > SB> in ms-pw-arch > I will fix this omission. > - PW Segment. A part of a single-segment or multi-segment PW, which > is set up between two PE devices, T-PEs and/or S-PEs. > > - Pw Switching Provider Edge (S-PE). A PE capable of switching the > control and data planes of the preceding and succeeding PW > segments in a MS-PW. The S-PE terminates the PSN tunnels of the > preceding and succeeding segments of the MS-PW. > > > 3. Introduction > > PWE3 defines the signaling and encapsulation techniques for > SB> Do you mean PWE3 here? > SB> Maybe you need to say PWE3 previously defined..., or > SB> maybe you should callup ms-pw requirements as a way of intro > establishing SS-PWs between a pair of terminating PEs and in the vast > majority of cases this will be sufficient. MS-PWs come into play in > two general cases: > changed to: The PWE3 Architecture [rfc3985], > SB>RFC editor will definately change "come into play" > ok changed to "are most useful" > -i. When it is not possible, desirable or feasible to establish > a PW control channel between the ultimate source and > destination PEs. At a minimum PW control channel > establishment requires knowledge of and reachability to the > remote (ultimate) PE IP address. The local (ultimate) PE may > SB> For consistency we should use the term T-PE (this applies > SB> in multiple places yes , this is a side effect of the terminology changes, i will do a search for all " ultimate" occurrences fixed. > not have access to this information related to topology, > operational or security constraints. > > An example is the inter-AS L2VPN scenario where the ultimate > PEs reside in different provider networks (ASes) and it is > the practice to MD5-key all control traffic exchanged > SB> Is MD5 ok with SEC AD? Is the correct verb "MD5-key"? > SB> Maybe you should just use the term "cryptogtaphiclly sign" > SB> effects rest of para. yes. Fixed. > between two networks. Technically a SS-PW could be used but > this would require MD5-keying on ALL ultimate source and > destination PE nodes. An MS-PW allows the providers to > confine MD5 key administration to just the PW switching > points connecting the two domains. > > > > -ii. PWE3 signaling and encapsulation protocols are different. > The ultimate PEs are connected to networks employing > SB> Again use of undefined term ultimate fixed everywhere. > different PW signaling and encapsulation protocols. In this > case it is not possible to use a SS-PW. A MS-PW with the > appropriate interworking performed at the PW switching > points can enable PW connectivity between the ultimate PEs > in this scenario. > > > > 4. General Description > > A pseudowire (PW) is a tunnel established between two provider edge > (PE) nodes to transport L2 PDUs across a packet switched network > SB> Isn't it to interconnect attachement circuits. > SB> We also support TDM which is not L2 PDU > (PSN) as described in Figure 1 and in [RFC3985]. Many providers have > deployed PWs as a means of migrating existing (or building new) L2VPN > services (e.g.. Frame Relay, ATM, or Ethernet) on to a PSN. > > > SB> There is a lot of overlap in this descriptive material with ms-pw > arch > SB> I wonder how much of this overlap is useful? > yes. This is really an introduction, as we have on all pwe3 documents. I'm open to remove it, but it is nice to read one document , and understand the technology without constantly going back to the architecture document. > > SB> There is something wrong with this next para. Did you snip > SB> out some preceeding text - it starts very abruptly and > SB> then strangely changes direction in the middle. > SB> I think that you need to take a look at rewording it. > SB> You might want to break it up into small bits. > I made some minor changes to this paragraph. However it seems to be mostly fine. here is the current text: "The general approach taken for MS-PWs is to connect the individual control planes by passing along any signaling information immediately upon reception. First the S-PE is configured to switch a SS-PW from a specific peer to another SS-PW destined for a different peer. No control messages are exchanged yet as the S-PE PE does not have enough information to actually initiate the PW setup messages. However, if a session does not already exist, a control protocol (LDP/L2TP) session MAY be setup. In this model the MS-PW setup is starting from the T-PE devices. Next once the T-PE is configured it sends the PW control setup messages. These messages are received by the S-PE, and immediately used to form the PW setup messages for the next SS-PW of the MS-PW. If one of the S-PEs doesn't accept an LDP Label Mapping message then a Label Release message may be sent back to the originator T-PE depending on the cause of the error. LDP liberal label retention mode still applies, hence if a PE is simply not configured yet , the label mapping is stored for future use. A MS-PW is declared UP only when all the constituent SS-PWs are UP." does this work ? > In general the approach taken is to connect the individual control > planes by passing along any signaling information immediately upon > reception. First the S-PE is configured to switch a SS-PW from a > specific peer to another SS-PW destined for a different peer. No > control messages are exchanged yet as the S-PE PE does not have > enough information to actually initiate the PW setup messages. > However, if a session does not already exist, a control protocol > (LDP/L2TP) session MAY be setup. In this model the MS-PW setup is > starting from the T-PE devices. Next once the T-PE is configured it > sends the PW control setup messages. These messages are received, and > immediately used to form the PW setup messages for the next SS-PW of > the MS-PW. If one of the Switching PEs doesn't accept an LDP Label > Mapping message then a Label Release message may be sent back to the > originator T-PE depending on the cause of the error. LDP liberal > label retention mode still applies, hence if a PE is simply not > configured yet , the label mapping is stored for future use. A MS-PW > is declared UP when all the constituent SS-PWs are UP. > > > > 5. PW Switching and Attachment Circuit Type > > The PWs in each PSN are established independently, with each PSN > being treated as a separate PWE3 domain. For example, in Figure 2 for > SB> Again do you mean PWE3 domain or PW domain or some other sort of > domain? > SB> missed out the word "the" PW domain . Fixed. > case of MPLS PSNs, PW1 is setup between PE1 and PE2 using the LDP > targeted session as described in [RFC4447], and at the same time a > separate pseudowire, PW2, is setup between PE3 and PE4. The ACs for > PW1 and PW2 at PE2 and PE3 MUST be configured such that they are the > same PW type e.g. ATM VCC, Ethernet VLAN, etc. > > > 6. Applicability > > The general applicability of MS-PWs and their relationship to L2VPNs > is described in [MS-PW-ARCH]. The applicability of a PW type, as > specified in the relevant RFC for that encapsulation (e.g. [RFC4717] > for ATM), applies to each segment. This section describes further > applicability considerations. > > In comon with SS-PWs, the performance of any segment of a MS-PW is > equal to the performance of the PSN plus any impairments Introduced > SB> performance of the PSN less any impairments? I take impairments as a negative , so we add impairments to a network , it makes it worse ... which is the point here. > by the PW layer itself. Therefore it is not possible for the MS-PW to > provide better performance than the PSN over which it is transported. > Furthermore, the overall performance of an MS-PW is no better than > the worst performing segment of that MS-PW. > > > > 7. MPLS-PW to MPLS-PW Control Plane Switching > > Referencing Figure 3, PE2 sets up a PW1 using the LDP targeted > SB> set up PW1 (delete "a") > SB> In Fig 3 you use the term "PW Segment 1" > SB> There is no PE2 in Fig 3 Fixed. > session as described in [RFC4447], at the same time a separate > pseudowire PW3 is setup to PE3. Each PW is configured independently > on the PEs, but on PE2 pseudowire PW1 is connected to pseudowire PW3. > PDUs are then switched between the pseudowires at the PW label level. > Hence the data plane does not need any special knowledge of the > specific pseudowire type. A simple standard MPLS label swap operation > is sufficient to connect the two PWs, and in this case the PW > adaptation function is not used. However when pushing a new PSN label > the TTL SHOULD be set to 255, or some other locally configured fixed > value. > SB> The label text above is a bit clumsy you pull a number out of the > SB> hat. Do you need to call up the pipe model? Comment of QoS? > no, ttl=255 is the maximum allowed amount, which is the usual default policy. I do not understand your comment on QoS ... there is no mention of QoS in the above text. > This process > can be repeated as many times as necessary, the only > limitation to the number of S-PEs traversed is imposed by the TTL > field of the PW MPLS Label. The setting of the TTL is a matter of > SB> PW TTL? there is no such thing as a PW TTL. the text above is correct. > local policy on the originating PE, but SHOULD be set to 255. > SB> Again do you need to say why 255? > > SB> You are in control plane but then swap to TTL for > SB> a bit surely that should be in data plane? > SB> You make the raeder jump around in this section. > fixed text as follows: " This process can be repeated as many times as necessary, the only limitation to the number of S-PEs traversed is imposed by the TTL field of the PW MPLS Label. The setting of the TTL is a matter of local policy on the originating PE, but SHOULD be set to 255. However if the PW PDU contains an OAM packet then the TTL can be set to the required value as explained later in this document. " The control plane set what the TTL should be , so this is a good place as any to discuss this. I'm open to suggestions. The data plane discussion could be split, but there is so little to say that we do not have a section on it. So we put this text in the general MPLS-MPLS section. > > > 7.1. Static Control plane switching > SB> It might be helpful to the reader to call out > SB> the case numbers from the list above. > > In the case of two static control planes the S-PE MUST be configured > to direct the MPLS packets from one PW into the other. There is no > control protocol involved in this case. When one of the control > planes is a simple static PW configuration and the other control > plane is a dynamic LDP FEC 128 or generalized PW FEC, then the static > control plane should be considered identical to an attachment circuit > (AC) in the reference model of Figure 1. The switching point PE > SHOULD signal the proper PW status if it detects a failure in sending > SB> What do you mean by proper? i meant "appropriate" .. fixed. > or receiving packets over the static PW segment. Because the PW is > statically configured, the status communicated to the dynamic LDP PW > will be limited to local interface failures. In this case, the S-PE > PE behaves in a very similar manner to a T-PE, assuming an active > role. > SB> What do you mean by "assuming an active role" active/passive is defined elsewhere in this document. It means that the S-PE will send a PW label mapping immediately. see previous section "FEC 129 Active/Passive T-PE Election Procedure" > This means that the S-PE will immediately send the LDP Label > Mapping message if the static PW is deemed to be UP. > > > 7.2. Two LDP control planes using the same FEC type > > As stated in a section above, the S-PE PE should assume an initial > SB> Which section above? > SB> Not sure "once" is the right word in the para below changed to "when" > passive role. This means that once independent PWs are configured on > the switching point, the LSR does not advertise the LDP PW FEC > mapping until it has received at least one of the two PW LDP FECs > from a remote PE. This is necessary because the switching point LSR > does not know a priori what the interface parameter field in the > initial FEC advertisement will contain. > > SB> PWID comes out of another hat - you need to point to a definition > SB> The next para is perhaps a little too cryptic fixed. > The PWID is a unique number between each pair of PEs. Hence Each SS- > PW that forms an MS-PW may have a different PWID. In the case of The > Generalized PW FEC, the AGI/SAI/TAI may have to also be different for > some, or sometimes all, SS-PWs. > > > 7.2.1. FEC 129 Active/Passive T-PE Election Procedure > > When a MS-PW is signaled using FEC 129, each T-PE might independently > start signaling the MS-PW. If the MS-PW path is not statically > configured, in certain cases the signaling procedure could result in > an attempt to setup each direction of the MS-PW through different > paths. > SB> Maybe you need to clarify that you mean different S-PEs. You > SB> do not care about the PSN paths. > fixed. > To avoid this situation one of the T-PE MUST start the PW > signaling (active role), while the other waits to receive the LDP > label mapping before sending the respective PW LDP label mapping > message. (passive role). When the MS-PW path not statically > configured, the Active T-PE (the ST-PE) and the passive T-PE (the > TT-PE) MUST be identified before signaling is initiated for a given > MS-PW. > > The determination of which T-PE assume the active role SHOULD be done > as follows: > > The SAII and TAII are compared as unsigned integers, if the SAII is > bigger then the T-PE assumes the active role. > SB> Do you mean that the T-PE with the larger xAII assumes the > SB> active roll? It took a couple of parses to get that. > This seems pretty clear to me , and is very similar to the text in rfc5036. Can you suggest something better ? > The selection process to determine which T-PE assumes the active role > MAY be superseded by manual provisioning. > > SB> If the T-PE with the smaller xAII is configured to be active > SB> how does the other T-PE know? > It does not. The operator is supposed to manually configure the other S-PE to be passive. I would really like to to remove this option, but some operators asked for it. I cannot quantify the advantage of defeating the automatic algorithm. > > 7.3. LDP FEC 128 to LDP using the generalized FEC 129 > > When a PE is using the generalized FEC 129, there are two distinct > roles that a PE can assume: active and passive. A PE that assumes the > active role will send the LDP PW setup message, while a passive role > PE will simply reply to an incoming LDP PW setup message. The S-PE > PE, will always remain passive until a PWID FEC 128 LDP message is > received, which will cause the corresponding generalized PW FEC LDP > message to be formed and sent. If a generalized FEC PW LDP message is > received while the switching point PE is in a passive role, the > corresponding PW FEC 128 LDP message will be formed and sent. > > SB> It seems like the text about active passive should preceed > SB> the previous section as it seems less abrupt in nature. > SB> > ??? it proceeds the previous section already ..... where do you ant to put this ? > PW IDs need to be mapped to the corresponding AGI/TAI/SAI and vice > versa. This can be accomplished by local S-PE configuration, or by > some other means, such as some form of auto discovery. Such other > means are outside the scope of this document. > > > 7.4. LDP S-PE TLV > > The edge to edge PW might traverse several switching points, in > separate administrative domains. For management and troubleshooting > reasons it is useful to record information about the switching points > that the PW traverses. This is accomplished by using a S-PE TLV. > > Note that sending the S-PE TLV is OPTIONAL, however the PE or S-PE > MUST process the TLV upon reception. The S-PE TLV is appended to the > PW FEC at each switching point. Each S-PE can append a PW switching > point TLV, and the order of the S-PE TLVs MUST be preserved. The S-PE > TLV MUST be sent if VCCV operation is required beyond the first MS-PW > segment from a T-PE. > > The S-PE TLV is encoded as follows: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| PW sw TLV (0x096D) | PW sw TLV Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Variable Length Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Length Value | > | " | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > SB> To be kind to people reading this in Emacs - it would be good > SB> to put in another " in the line above > I Put 3 in , but i think the RFC editor will make it pretty anyhow. :-) > [note] LDP TLV type is pending IANA approval. > SB> Has this TLV request been approved by MPLS WG yet? > No it must have been missed... the allocation is available , and we have other already allocated but not this one. Can you please send a request ? > > The PW switching Point TLV is an OPTIONAL TLV that should appear only > SB> First you should have given the TLV name when you introduced > SB> the term above. > SB> Second this repeats what you just said in para 2 of this > SB> section Good catch , i cleaned up the mess resulting in : Sending the PW switching Point TLV ( S-PE TLV ) is OPTIONAL, however the PE or S-PE MUST process the TLV upon reception. The "U" bit MUST be set for backward compatibility with T-PEs that do not support the MS-PW extensions described in the document. The S-PE TLV MAY appear only once for each switching point traversed. The S-PE TLV is appended to the PW FEC at each switching point, and the order of the S-PE TLVs in the LDP message MUST be preserved. The S-PE TLV MUST be sent if VCCV operation is required beyond the first MS-PW segment from a T-PE. > once for each switching point traversed. If the S-PE TLV is not > present with the required sub-TLVs, VCCV operation will not function. > > For local policy reasons, a particular S-PE can filter out all S-PE > TLVs in a label mapping message that traverses it and not include > it's own S-PE TLV. In this case, from any upstream PE, it will > appear as if this particular S-PE is the T-PE. This might be > necessary , depending on local policy if the S-PE is at the Service > provider administrative boundary. > > SB> Do you need to comment on the VCCV implications? > > I have a comment above, which is more accurate then what we had before. I added : It should also be noted that because there are no S-PE TLVs describing the path beyond the S-PE that removed them, VCCV will only work as far as that S-PE . > 7.4.1. PW Switching Point Sub-TLVs > SB> The next sentence does not read right > SB> Then it all gets very abrupt in the description that follows > SB> I am not sure how many readers will figure it out > added: The S-PE TLV contains sub-TLVs that describe various characteristics of the S-PE traversed. Below are the definitions of PW Switching Point Sub-TLVs defined in this document: > Below are details specific to PW Switching Point Sub-TLVs described > in this document: > > - PW ID of last PW segment traversed. This is only applicable if > the last PW segment traversed used LDP FEC 128 to signal the PW. > i also fixed this formatting error. > This sub-TLV type contains a PW ID in the format of the PWID > described in [RFC4447]. This is just a 32 bit unsigned integer > number. > > - PW Switching Point description string. > > An optional description string of text up to 80 characters long. > > - Local IP address of PW Switching Point. > > The Local IP V4 or V6 address of the PW Switching Point. This is > an OPTIONAL Sub-TLV. In most cases this will be the local LDP > session IP address of the S-PE. > > - Remote IP address of the last PW Switching Point traversed or of > the T-PE > > The IP V4 or V6 address of the last PW Switching Point traversed > or of the T-PE. This is an OPTIONAL Sub-TLV. In most cases this > will be the remote IP address of the LDP session. This Sub-TLV > SHOULD only be included if there are no other S-PE TLV present > from other S-PEs, or if the remote ip address of the LDP session > does not correspond to the "Local IP address of PW Switching > Point" TLV value contained in the last S-PE TLV. > > - The FEC of last PW segment traversed. > > This is only applicable if the last PW segment traversed used LDP > FEC 129 to signal the PW. > > The Attachment Identifier of the last PW segment traversed. This > is encoded in the following format: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AGI Type | Length | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ AGI Value (contd.) ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AII Type | Length | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ SAII Value (contd.) ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AII Type | Length | Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ TAII Value (contd.) ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > - L2 PW address of PW Switching Point (recommended format). > > This sub-TLV type contains a L2 PW address of PW Switching Point in > the format described in [RFC5003]. This includes the AII type field , > and length, as well as the L2 PW address. > > > > > > 7.6. PW Loop Detection > > A switching point PE SHOULD check the OPTIONAL PW switching Point > TLV, to verify if it's own IP address appears in it. If it's IP > SB> Hopefully to determine or to check and not to verify? > SB> Or maybe to verify that it is not in it? > fixed as follows: A switching point PE SHOULD inspect the PW switching Point TLV, to verify that it's own IP address does not appears in it. If the PE's IP address appears in a received PW switching Point TLV, the PE SHOULD break the loop, and send a label release message with the following error code: > address appears in a received PW switching Point TLV, the PE SHOULD > break the loop, and send a label release message with the following > > > > 8.2. Static MPLS PW and Dynamic L2TPv3 PW > > When a statically configured MPLS PW is switched to a dynamic L2TPv3 > PW, the static control plane should be considered identical to an > attachment circuit (AC) in the reference model of Figure 1. The > switching point PE SHOULD signal the proper PW status if it detects a > SB> Again proper? > SB> Same again in section 8.3 changed to appropriate > failure in sending or receiving packets over the static PW. Because > the PW is statically configured, the status communicated to the > dynamic L2TPv3 PW will be limited to local interface failures. In > this case, the S-PE PE behaves in a very similar manner to a T-PE, > assuming an active role. > > > > SB> In case I miss it - what happens about active/passive > SB> negotiation in mixed L2TPv3/MPLS dynamic? > > that mode does not exist, and is undefined. We do not support dynamic interworking of the two protocols. > > > > 8.4.3. Session Tear Down > > L2TPv3 uses a single message, CDN, to tear down a pseudowire. The CDN > message translates to a Label Withdraw message in LDP. Following are > two example exchanges of messages between LDP and L2TPv3. The first > is a case where an L2TPv3 T-PE initiates the termination of an MS-PW, > the second is a case where an MPLS T-PE initiates the termination of > an MS-PW. > > PE 1 (L2TPv3) PW Switching Node PE3 (MPLS/LDP) > > AC "Down" > L2TPv3 CDN ---> > LDP Label Withdraw ---> > AC "Down" > <-- LDP Label Release > > <--------------- MH PW Data Path Down ------------------> > > SB> Is there no ack back in L2TP to say that the CDN has > SB> been actioned? > Carlos is the expert on this topic, but I believe that there is no support for the "ack" you mention in L2TPV3. > > > > Other interface parameter mappings will either be defined in a future > version of this document, > > SB> Is "future version...." correct IETF speak when we are about > SB> to go to RFC? > Yes I missed this. I removed the text. it is now : "Other interface parameter mappings are unsupported when switching between LDP/MPLS and L2TPv3 PWs." > > 8.7. L2TPv3 and MPLS PW Data Plane > > When switching between an MPLS and L2TP PW, packets are sent in their > entirety from one PW to the other, replacing the MPLS label stack > with the L2TPv3 and IP header or vice versa. There are some > situations where an additional amount of interworking must be > provided between the two data planes at the PW switching node. > > SB> You might want to note that these are described in the > SB> following sections. Note that 8.7.1 really should be part > SB> of the intro (8.7) which would fix that problem. > Sorry , I do not understand this comment. > 8.7.1. PWE3 Payload Convergence and Sequencing > > Section 5.4 of [RFC3985] discusses the purpose of the various shim > headers necessary for enabling a pseudowire over an IP or MPLS PSN. > For L2TPv3, the Payload Convergence and Sequencing function is > carried out via the Default L2-Specific Sublayer defined in [L2TPv3]. > For MPLS, these two functions (together with PSN Convergence) are > carried out via the MPLS Control Word. Since these functions are > different between MPLS and L2TPv3, interworking between the two may > be necessary. > > The L2TP L2-Specific Sublayer and MPLS Control Word are shim headers > which in some cases are not necessary to be present at all. For > example, an Ethernet PW with sequencing disabled will generally not > require an MPLS Control Word or L2TP Default L2-Specific Sublayer to > be present at all. In this case, Ethernet frames are simply sent from > one PW to the other without any modification beyond the MPLS and > L2TP/IP encapsulation and decapsulation. > > The following section offers guidelines for how to interwork between > L2TP and MPLS for those cases where the Payload Convergence, > Sequencing, or PSN Convergence functions are necessary on one or both > sides of the switching node. > > > 8.7.2. Mapping > the formatting had a bug in this title - i fixed it. > The MPLS Control Word consists of (from left to right): > SB> Without a picture you can't say left to right, and even > SB> with one you mean from low order bits to high order bits. > SB> However it might be better to quote bit numbers in > SB> the text below. > SB> Maybe you need both headers in the draft to make it clear? > I'm going to add the picture from rfc3985. > -i. These bits are always zero in MPLS are not necessary to be > mapped to L2TP. > > > > > 9.3. Signaling OAM Capabilities for Switched Pseudowires > > Like in SS-PW, MS-PW VCCV capabilities are signaled using the VCCV > SB> As in? > Similarly to SS-PW > > > > 9.5.1. VCCV Echo Message Processing > > For example, in Figure 3, T-PE1 has the FEC128 of the segment, PW1, > but it does not readily have the information required to compose the > FEC128 of the following segment, PW3, if a VCCV echo request to be > sent to T-PE2. This can be achieved by the methods described in the > following subsections. > > SB> the naming here sort of matches fig 3, but not quite. > fixed. > > > > 9.5.2.5. MS-PW Path Trace > > SB> This looks the same as MS-PW Path Verification > SB> What is the difference? > This is to accommodate existing deployments , and is optional. Otherwise the result is the same, there is no functional difference. MS-PW Path Verification takes control plane information received at PW signaling time and verifies that the dataplane agrees. Path trace ask the control plane in turn , at each ms-pw hop for the information of the next hop and does the same. > > > 10. Mapping Switched Pseudowire Status > > In the PW switching with attachment circuits case (Figure 2), PW > status messages indicating PW or attachment circuit faults MUST be > mapped to fault indications or OAM messages on the connecting AC as > defined in [PW-MSG-MAP]. > > In the PW control plane switching case (Figure 3), there is no > attachment circuit at the S-PE, but the two PWs are connected > together. Similarly, the status of the PWs are forwarded unchanged > from one PW to the other by the control plane switching function. > However, it may sometimes be necessary to communicate fault status of > one of the locally attached SS-PW at a S-PE. For LDP this can be > accomplished by sending an LDP notification message containing the PW > status TLV, as well as an OPTIONAL PW switching point TLV as follows: > > 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| Notification (0x0001) | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|1| Status (0x0300) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|1| Status Code=0x00000028 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Type=0 | PW Status TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Status TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Status TLV | PWId FEC | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | | > | PWId FEC or Generalized ID FEC | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| PW sw TLV (0x096D) | PW sw TLV Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Variable Length Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Only one S-PE TLV can be present in this message. This message is > > SB> This is a general comment, but I think that it would > SB> be a good idea to allocate figure numbers to the TLV and > SB> protocol exchanges. > SB> This not only allows the reader to point to these > SB> components more easily, but we might want to point to > SB> in another of our documents. > This is not a standard stile , if you take, for example , the IDR WG , they almost never use numbers , and the diagrams are very difficult to read. I did not assign a figure number to this picture because I do not want it quoted elsewhere , as it is a very specific example, and future extensions can change it. the more generic figures have numbers assigned to them. > > > > The merging of the received LDP status and the local status for the > PW segments at an S-PE can be summarized as follows: > > -i. When the local status for both PW segments is UP, the S-PE > SB> We kind of need a better name than "both PW segments" Can you suggest one ? > > > SB> You really ought to five the figure a number and point to it > SB> for the table below. > > -i. PW2 Transmit direction fault > -ii. PW1 Transmit direction fault > -iii. PW2 Receive direction fault > -iv. PW1 Receive direction fault > > > > this list has no corresponding figure. What figure do you wan here ? > > 12. Security Considerations > > This document specifies the LDP and L2TPv3 extensions that are needed > SB> and VCCV extensions fixed. > for setting up and maintaining pseudowires. The purpose of setting up > pseudowires is to enable layer 2 frames to be encapsulated and > transmitted from one end of a pseudowire to the other. Therefore we > treat the security considerations for both the data plane and the > SB> address the security? > control plane. > we do not really address the security , as we offer no solution in some cases. I could say "discuss" ? > > > 12.2. Control Protocol Security > > > > A Pseudowire connects two attachment circuits. It is important to > make sure that LDP connections are not arbitrarily accepted from > anywhere, or else a local attachment circuit might get connected to > an arbitrary remote attachment circuit. Therefore an incoming session > request MUST NOT be accepted unless its IP source address is known to > be the source of an "eligible" peer. The set of eligible peers could > be pre-configured (either as a list of IP addresses, or as a list of > address/mask combinations), or it could be discovered dynamically via > an auto-discovery protocol which is itself trusted. (Obviously if the > auto-discovery protocol were not trusted, the set of "eligible peers" > it produces could not be trusted.) > SB> You might want to rephase the last sentence, because it > SB> treats the reader like an idiot :) > ??? that was certainly not the intention. i'll reword it as follows: Obviously -> Note that > > > For a greater degree of security, the LDP MD5 authentication key > option, as described in section 2.9 of RFC 3036, or the Control > Message Authentication option of [L2TPv3] MAY be used. > > SB> I am worried that sec review will complain about MD5 > SB> do we have to say MD5 rather than something just saying > SB> use the flavor of the month crypto authentication. > Ok, first the quote is obsolete , i'll update it to rfc5036. then i removed the MD5 part. We really can only do what LDP supports in this case. > > > This provides > integrity and authentication for the control messages, and eliminates > the possibility of source address spoofing. Use of the message > authentication option does not provide privacy, but privacy of > control messages are not usually considered to be highly urgent. > SB> urgent means "do now" I think you mean important > yes. Fixed. > > > > 13. IANA Considerations > > 13.1. L2TPv3 AVP > > This document uses a ne L2TP parameter, IANA already maintains a > registry of name "Control Message Attribute Value Pair" defined by > [RFC3438]. The following new values are required: > SB> only one value > fixed. > TBA-L2TP-AVP-1 - PW Switching Point AVP > > 13.2. LDP TLV TYPE > > This document uses several new LDP TLV types, IANA already maintains > SB> But you only ask for one new TLV below > A registry of name "TLV TYPE NAME SPACE" defined by RFC3036. The > following value is suggested for assignment: > > TLV type Description > 0x096D Pseudowire Switching TLV > fixed. let's get this assigned ASAP ! > > > 13.3. LDP Status Codes > > This document uses several new LDP status codes, IANA already > SB> But you only ask for one new status code below > maintains a registry of name "STATUS CODE NAME SPACE" defined by > RFC3036. The following value is suggested for assignment: > > Assignment E Description > 0x0000003A 0 "PW Loop Detected" > > > 13.4. L2TPv3 Result Codes > > This document uses several new L2TPv3 status codes, IANA already > SB> ... and I only see one request below clearly I cut and pasted this text ;-) > maintains a registry of name "L2TPv3 Result Codes" defined by > RFCxxxx. The following value is suggested for assignment: > SB> ... you need the RFC number > it is unclear what rfc defines these , so i'll remove the mention of an RFC. > Assignment Description > 17 "sequencing not supported" > > > 13.5. New IANA Registries > > IANA needs to set up a registry of "PW Switching Point TLV Type". > These are 8-bit values. Types value 1 through 3 are defined in this > document. Type values 4 through 64 are to be assigned by IANA using > SB> you define 1 through 6 below > indeed, fixed. > > Type Length Description > > 0x01 4 PW ID of last PW segment traversed > 0x02 variable PW Switching Point description string > 0x03 4/16 Local IP address of PW Switching Point > 0x04 4/16 Remote IP address of last PW Switching Point traversed > or of the T-PE > 0x05 variable AI of last PW segment traversed > 0x06 10 L2 PW address of PW Switching Point > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From simon.delord@gmail.com Mon Apr 6 15:28:29 2009 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 A119F3A67E3 for ; Mon, 6 Apr 2009 15:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 utInup80YjhD for ; Mon, 6 Apr 2009 15:28:28 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id B04913A6B39 for ; Mon, 6 Apr 2009 15:28:28 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2455244wfg.31 for ; Mon, 06 Apr 2009 15:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=CRFvB/3TFK2WG+nhCMXEK+3H9aix2m9XFzqSqPTiwjY=; b=R7b1EK26zrbl56qfqQ1pdX6Sj7G8u/L62eBU726vCphns8fKVq+NwgWoNAByfW91Gl LPdHqlF2oeJw8FTpeGfM4UTFcyY6L6IsEhKN+G9FYKLvldWv0Uj2EgD13LkB4tSXz/SL Mlk5zyATcvlWzeYP3JgFVT227lbM4L9vGxmL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Rhh1NFKY7vyoSTxQIH/zwSqJM4yfzt5W2Z1niqaAbpyfejABF0g8y0gxe2uQZEHMJF R0mg2IDj8WuLnctXCRCg6H/tMt+wKMT+ganYJB0P2qMxTutc1ISXzGUDa/chg4TlHrYa i8PsYVPJibPcVQdiQf7lBGGycdOnV40rPJqeo= MIME-Version: 1.0 Received: by 10.142.49.20 with SMTP id w20mr1401396wfw.330.1239056974893; Mon, 06 Apr 2009 15:29:34 -0700 (PDT) In-Reply-To: <49D4F11A.1020905@cisco.com> References: <49D4F11A.1020905@cisco.com> Date: Tue, 7 Apr 2009 08:29:34 +1000 Message-ID: From: Simon Delord To: stbryant@cisco.com, pwe3 Content-Type: multipart/alternative; boundary=000e0cd2a0a8d852160466ea6ef6 Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 06 Apr 2009 22:28:29 -0000 --000e0cd2a0a8d852160466ea6ef6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Support, Simon 2009/4/3 Stewart Bryant > The authors of draft-martini-pwe3-iccp-01.txt > > http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt > > have requested that this become a PWE3 WG document. > > Please can you send comments to the list by 20th April > so that the chairs can judge consensus. > > Thanks > > Stewart > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --000e0cd2a0a8d852160466ea6ef6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support,
=A0
Simon

2009/4/3 Stewart Bryant <stbryant@cisco.com>
The authors of draft-martini-pwe= 3-iccp-01.txt

http://tools.ietf.org/id/draft-martini-pwe3= -iccp-01.txt

have requested that this become a PWE3 WG document.

Please can y= ou send comments to the list by 20th April
so that the chairs can judge = consensus.

Thanks

Stewart
________________________________= _______________
pwe3 mailing list
pwe= 3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3

--000e0cd2a0a8d852160466ea6ef6-- From frederic.jounay@orange-ftgroup.com Tue Apr 7 07:14:58 2009 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 C240B28C0FB for ; Tue, 7 Apr 2009 07:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, SUBJ_ALL_CAPS=2.077] 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 TNEJRYIPo-Ye for ; Tue, 7 Apr 2009 07:14:57 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 5E1513A6886 for ; Tue, 7 Apr 2009 07:14:57 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 16:15:51 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Apr 2009 16:15:52 +0200 Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A15656ED4@ftrdmel2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPLS2009 - CALL FOR PRESENTATIONS Thread-Index: Acm3i1wHcQWxQHD4TFaxtrh7JMSuwA== From: To: X-OriginalArrivalTime: 07 Apr 2009 14:15:51.0060 (UTC) FILETIME=[5AED2D40:01C9B78B] Subject: [PWE3] MPLS2009 - CALL FOR PRESENTATIONS 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, 07 Apr 2009 14:14:58 -0000 MPLS 2009 INTERNATIONAL CONFERENCE http://www.mpls2009.com=20 OCTOBER 25 - 28, 2009, WASHINGTON, DC=20 On line Submissions: http://www.isocore.com/mpls2009/call_for_papers/cfp.htm=20 Deadline for submission of presentation proposals: May 8, 2009=20 CALL FOR PRESENTATION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=20 The MPLS 2009 International Conference, the 12th Annual International Conference on MPLS and Related Technologies, will be held October 25 - 28, 2009, in Washington, DC. The Technical Program Committee is soliciting an abstract summarizing a proposed presentation representing original/unpublished work covering cutting-edge topics.=20 Presentations addressing new technologies and operational experience are being solicited from network equipment vendors, service/transport providers, the research community, government agencies, and enterprise users.=20 Some or all of these topics have been of interest to the PWE3 WG in the past, and I wanted to indicate that the call for presentation abstracts is now open. If you are interested in further information or want to submit a presentation abstract, please see the following URL: http://www.isocore.com/mpls2009/call_for_papers/cfp.htm=20 In particular and relevant to PWE3, this year's conference will include, but will not be limited to the following topics A. Architectures and Enablers=20 MPLS Transport Profile (MPLS-TP)=20 Multicast in MPLS Pseudowires and VPLS=20 Single and Multi-hop Pseudowire placement, setup, and management=20 B. Services and Applications=20 MPLS Support for Ethernet Services and VPLS=20 Next Generation Mulicast VPN in Enterprise Networks=20 Testing: MPLS test tools and certification experience=20 C. Implementation (ISP/User) Experience and Case Studies=20 Deploying, interworking, and operating L2 and L3=20 MPLS VPN deployment experience: scaling, performance, and Security=20 D. OAM, Resiliency and Performance=20 OAM and network management for packet transport networks=20 High Availability (Graceful Restart, Non-Stop Routing, In-Service Software Upgrades, etc)=20 Protection, restoration, and reliability for MPLS and Pseudowires=20 Improved Load Balancing for MPLS and Pseudowires=20 Security features for MPLS and Pseudowires=20 Congestion Notification and processing for MPLS and Pseudowires=20 E. Wireless and Mobility=20 MPLS applications for LTE/WiMAX=20 Wireless and Mobility Backhauling=20 MPLS applications in the access network=20 Best Regards, Frederic _______________________________________________ tpc-mpls2009-L mailing list tpc-mpls2009-L@isocore.com http://isocore.com/mailman/listinfo/tpc-mpls2009-l_isocore.com From jiang.xiaowei@zte.com.cn Wed Apr 8 04:53:28 2009 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 D4C1B3A696A for ; Wed, 8 Apr 2009 04:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[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 aoV5-z-0iiI0 for ; Wed, 8 Apr 2009 04:53:27 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 3AECB3A69FF for ; Wed, 8 Apr 2009 04:53:27 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111641397396305; Wed, 8 Apr 2009 19:45:24 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 47274.4466833428; Wed, 8 Apr 2009 19:43:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n38BkcJq044544; Wed, 8 Apr 2009 19:46:38 +0800 (CST) (envelope-from jiang.xiaowei@zte.com.cn) In-Reply-To: To: amalis@gmail.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: jiang.xiaowei@zte.com.cn Date: Wed, 8 Apr 2009 19:46:04 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-08 19:46:42, Serialize by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-08 19:46:42, Serialize complete at 2009-04-08 19:46:42, S/MIME Sign failed at 2009-04-08 19:46:43: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-08 19:46:19, Serialize complete at 2009-04-08 19:46:19 Content-Type: multipart/alternative; boundary="=_alternative 0040B39F48257592_=" X-MAIL: mse1.zte.com.cn n38BkcJq044544 Cc: pwe3@ietf.org, stbryant@cisco.com Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? 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, 08 Apr 2009 11:53:28 -0000 This is a multipart message in MIME format. --=_alternative 0040B39F48257592_= Content-Type: text/plain; charset="US-ASCII" Andy, Is there any need for Packet-PW to maintain any kind of state machine for virtual interface status like Lucy Yong mentioned? Thanks, Albert Lucy Yong sender: pwe3-bounces@ietf.org 2009-04-01 01:13 to 'Stewart Bryant' , pwe3@ietf.org, "'Malis, Andrew G. (Andy)'" cc topic [PWE3] comments on packet pw Hi Stewart and Andy, I support this draft to become WG draft. Congratulation!! I also have some comments on the draft: 1) Since Packet PW requires using CW, it is necessary to state how to use flow label and S/N for packet PW. 2) It is good to have the PW status mapped to virtual interfaces. However, each protocol interface may have its own link status protocol running, the draft should state the procedures to determine interface status, or require each protocol interface to turn off its link protocol when using Packet PW 3) Since Packet PW acts as a data link between two clients LSRs, the draft should state link operational procedures (for client networks) over a packet PW such as how to determine admin cost, TE metrics, etc. 4) I assume that a Packet PW can obtain transport resiliency from server MPLS network, it would be nice for the draft to state them and considers that the consequence may change admin cost in client networks. Cheers, Lucy_______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 "Andrew G. Malis" 2009-04-04 23:39 jiang.xiaowei@zte.com.cn stbryant@cisco.com, pwe3@ietf.org Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? Jiang, Yes it could, but in addition to higher overhead it would also require running the PPP state machine and using PPP options. We wanted to keep this as simple as possible. Thanks, Andy 2009/4/3 : > > Sir, > > Could rfc4618 Encapsulation Methods for Transport of PPP/High-Level Data > Link Control (HDLC) over MPLS Networks > be used as a solution for the scenario in this draft? (although have more > encapsulation overhead) > > Thank you! --=_alternative 0040B39F48257592_= Content-Type: text/html; charset="US-ASCII"
Andy,

Is there any need for Packet-PW to maintain any kind of state machine for virtual interface status like Lucy Yong mentioned?

Thanks,
Albert




Lucy Yong <lucyyong@huawei.com>
sender:  pwe3-bounces@ietf.org

2009-04-01 01:13

to
'Stewart Bryant' <stbryant@cisco.com>, pwe3@ietf.org, "'Malis, Andrew G. (Andy)'" <andrew.g.malis@verizon.com>
cc
topic
[PWE3] comments on packet pw





Hi Stewart and Andy,
 
I support this draft to become WG draft. Congratulation!!
I also have some comments on the draft:
 
1)     Since Packet PW requires using CW, it is necessary to state how to use flow label and S/N for packet PW.
2)     It is good to have the PW status mapped to virtual interfaces. However, each protocol interface may have its own link status protocol running, the draft should state the procedures to determine interface status, or require each protocol interface to turn off its link protocol when using Packet PW
3)     Since Packet PW acts as a data link between two clients LSRs, the draft should state link operational procedures (for client networks) over a packet PW such as how to determine admin cost, TE metrics, etc.
4)     I assume that a Packet PW can obtain transport resiliency from server MPLS network, it would be nice for the draft to state them and considers that the consequence may change admin cost in client networks.
 
Cheers,
Lucy_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3





"Andrew G. Malis" <amalis@gmail.com>

2009-04-04 23:39

jiang.xiaowei@zte.com.cn
stbryant@cisco.com, pwe3@ietf.org
Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?





Jiang,

Yes it could, but in addition to higher overhead it would also require
running the PPP state machine and using PPP options. We wanted to keep
this as simple as possible.

Thanks,
Andy

2009/4/3  <jiang.xiaowei@zte.com.cn>:
>
> Sir,
>
> Could rfc4618 Encapsulation Methods for Transport of PPP/High-Level Data
> Link Control (HDLC) over MPLS Networks
> be used as a solution for the scenario in this draft? (although have more
> encapsulation overhead)
>
> Thank you!

--=_alternative 0040B39F48257592_=-- From satoru@ft.solteria.net Wed Apr 8 06:37:17 2009 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 548DE3A6A10 for ; Wed, 8 Apr 2009 06:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 GxdlkWX8zuGG for ; Wed, 8 Apr 2009 06:37:16 -0700 (PDT) Received: from ns.ft.solteria.net (ns.ft.solteria.net [210.142.173.164]) by core3.amsl.com (Postfix) with ESMTP id 756763A68DA for ; Wed, 8 Apr 2009 06:37:16 -0700 (PDT) Received: from [IPv6:::1] (localhost [127.0.0.1]) by ns.ft.solteria.net (Postfix) with ESMTP id 0DCFB38745; Wed, 8 Apr 2009 22:40:28 +0900 (JST) Message-Id: <6DC5615C-14D1-4D28-B204-316C6FFDF23B@ft.solteria.net> From: Satoru Matsushima To: pwe3 In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 22:38:22 +0900 References: X-Mailer: Apple Mail (2.930.3) Cc: davarish@yahoo.com, Stewart Bryant Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 08 Apr 2009 13:37:17 -0000 On 2009/04/03, at 3:57, Thomas D. Nadeau wrote: > > There are no claims from BT. > > --Tom > Softbank has no patent claim. -- Satoru Matsushima > > > On 4/2/09 2:52 PM, "Stewart Bryant" wrote: > >> Please will the authors clarify the IPR position. >> >> Stewart >> >> Shahram Davari wrote: >>> Hi Stewart >>> >>> Could you please clarify whether there is any patent claim related >>> to this >>> draft or not? >>> >>> Thanks, >>> Shahram >>> >>> >>> >>> -----Original Message----- >>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On >>> Behalf Of >>> Stewart Bryant >>> Sent: Thursday, April 02, 2009 1:09 PM >>> To: pwe3 >>> Subject: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? >>> >>> The authors of draft-martini-pwe3-iccp-01.txt >>> >>> http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt >>> >>> have requested that this become a PWE3 WG document. >>> >>> Please can you send comments to the list by 20th April so that the >>> chairs can judge consensus. >>> >>> Thanks >>> >>> Stewart >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> >>> >>> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 > > -- > Principal Architect - 21CN Networks > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From amalis@gmail.com Wed Apr 8 06:41:08 2009 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 B5D3F3A6931 for ; Wed, 8 Apr 2009 06:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[AWL=-0.073, 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 cUpPMorVIkUm for ; Wed, 8 Apr 2009 06:41:07 -0700 (PDT) Received: from mail-qy0-f110.google.com (mail-qy0-f110.google.com [209.85.221.110]) by core3.amsl.com (Postfix) with ESMTP id 6E4C73A68DA for ; Wed, 8 Apr 2009 06:41:07 -0700 (PDT) Received: by qyk8 with SMTP id 8so140874qyk.29 for ; Wed, 08 Apr 2009 06:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=xVXaBvyQX4aUuiu+pqgddmFfKwl3ovE5yl/LHyqSAF8=; b=IIyhAfSgntSXYYpj2yZQbpdnU2uEl8noSVtYu3to7kZMv9qSH/lVMrU+qyuvB9n/oz Npburd4Oq7lDnJusTJNv6BtkCQHvVj28kK5ZZjBfb+llDnCyycaKdubYUYmL4HV3dyma UfwBsYwA4KX97jFehZS1VdrT8jQFlWtMhEMII= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=GrjVBVgT6ujs/8BZes8mjaz8vfS8d7y7miQ/SEDQe6eEbO21GSut/yTkWWp6ArT+Lv OEbuDDgB/EfAL4ZO1xU+rS/j2bgUD5HxGPrEnTHmhIsTJ5TdGT9hrt+F1Go/xLH8ZZXT klAHkNcMDfKcrpTTIWT2D408Xto7aiP5N/9lA= MIME-Version: 1.0 Received: by 10.224.54.75 with SMTP id p11mr1488041qag.93.1239198134495; Wed, 08 Apr 2009 06:42:14 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Wed, 8 Apr 2009 09:41:59 -0400 Message-ID: To: jiang.xiaowei@zte.com.cn Content-Type: multipart/alternative; boundary=0015175cdef29ce90804670b4c9c Cc: pwe3@ietf.org, stbryant@cisco.com Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? 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, 08 Apr 2009 13:41:08 -0000 --0015175cdef29ce90804670b4c9c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jiang, I don't think so, but we should look more closely at the details on mapping between the virtual interface state and PW status reporting (without being implementation-dependent) to make sure we've got the all of the details covered. Lucy's point 3 is a good one as well. Thanks, Andy On Wed, Apr 8, 2009 at 7:46 AM, wrote: > > Andy, > > Is there any need for Packet-PW to maintain any kind of state machine for > virtual interface status like Lucy Yong mentioned? > > Thanks, > Albert > > > > > *Lucy Yong * > sender: pwe3-bounces@ietf.org > > 2009-04-01 01:13 > to > 'Stewart Bryant' , pwe3@ietf.org, "'Malis, Andrew G. > (Andy)'" cc > topic > [PWE3] comments on packet pw > > > > > Hi Stewart and Andy, > > I support this draft to become WG draft. Congratulation!! > I also have some comments on the draft: > > 1) Since Packet PW requires using CW, it is necessary to state how to > use flow label and S/N for packet PW. > 2) It is good to have the PW status mapped to virtual interfaces. > However, *each protocol interface may have its own link status protocol*running, the draft should state the procedures to determine interface > status, or require each protocol interface to turn off its link protocol > when using Packet PW > 3) Since Packet PW acts as a data link between two clients LSRs, the > draft should state link operational procedures (for client networks) over a > packet PW such as how to determine admin cost, TE metrics, etc. > 4) I assume that a Packet PW can obtain transport resiliency from > server MPLS network, it would be nice for the draft to state them and > considers that the consequence may change admin cost in client networks. > > Cheers, > Lucy_______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > *"Andrew G. Malis" * > > 2009-04-04 23:39 > jiang.xiaowei@zte.com.cn > stbryant@cisco.com, pwe3@ietf.org > Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? > > > > > Jiang, > > Yes it could, but in addition to higher overhead it would also require > running the PPP state machine and using PPP options. We wanted to keep > this as simple as possible. > > Thanks, > Andy > > 2009/4/3 : > > > > Sir, > > > > Could rfc4618 Encapsulation Methods for Transport of PPP/High-Level Data > > Link Control (HDLC) over MPLS Networks > > be used as a solution for the scenario in this draft? (although have more > > encapsulation overhead) > > > > Thank you! > > --0015175cdef29ce90804670b4c9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jiang,

I don't think so, but we should look more clo= sely at the details on mapping between the virtual interface state and PW s= tatus reporting (without being implementation-dependent) to make sure we= 9;ve got the all of the details covered. Lucy's point 3 is a good one a= s well.

Thanks,
Andy

On Wed, Apr 8, 2009 at 7:46 AM, <jiang.xiaowei@zte.com.cn> wr= ote:

Andy,

Is there any need for Packet-PW to= maintain any kind of state machine for virtual interface status like Lucy Yong menti= oned?

Thanks,
Albert




Lucy Yong <lucyyong@huawei.com>
sender: =A0
pwe3-bounces@ietf.org

2009-04-01 01:13

to
'Stewart Bryant' <= stbryant@cisco.com<= /a>>, pwe3@ietf.org, "= ;'Malis, Andrew G. (Andy)'" <andrew.g.malis@verizon.com>
cc
topic
[PWE3] comments on packet pw<= /font>





Hi Stewart and Andy,
=A0
I support this draft to become WG draf= t. Congratulation!!
I also have some comments on the draft= :
=A0
1) =A0 =A0 Since Packet PW requires using CW, it is necessary to state how to use flow label and S/N for packet PW.
2) =A0 =A0 It is good to have the PW status mapped to virtual interfaces. However, each protocol interface may have its own link status protocol running, the draft should state the procedures to determine interface status, or require each protocol interface to turn off its link protocol when using Packet PW
3) =A0 =A0 Since Packet PW acts as a data link between two clients LSRs, the draft should state link operation= al procedures (for client networks) over a packet PW such as how to determine admin cost, TE metrics, etc.
4) =A0 =A0 I assume that a Packet PW can obtain transport resiliency from server MPLS network, it would be nice for the draft to state them and considers that the consequence may change admin cost in client networks.
=A0
Cheers,
Lucy______= _________________________________________




"Andrew G. M= alis" <amalis@gmail.com<= /a>>

2009-04-04 23:39

stbryant@cisco.com, pwe3@ietf.org
Re: [PWE3] draft-bryant-pwe3-= packet-pw-00.txt to WG draft?





Jiang,

Yes it could, but in addition to higher overhead it would also require
running the PPP state machine and using PPP options. We wanted to keep
this as simple as possible.

Thanks,
Andy

2009/4/3 =A0<jiang.xiaowei@zte.com.cn>:
>
> Sir,
>
> Could rfc4618 Encapsulation Methods for Transport of PPP/High-Level Data
> Link Control (HDLC) over MPLS Networks
> be used as a solution for the scenario in this draft? (although have more
> encapsulation overhead)
>
> Thank you!


--0015175cdef29ce90804670b4c9c-- From Mustapha.Aissaoui@alcatel-lucent.com Wed Apr 8 07:20:14 2009 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 A73EC3A6844 for ; Wed, 8 Apr 2009 07:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 c75x9ek9+C9r for ; Wed, 8 Apr 2009 07:20:05 -0700 (PDT) Received: from audl751.usa.alcatel.com (audl751.usa.alcatel.com [143.209.238.164]) by core3.amsl.com (Postfix) with ESMTP id 610433A68DA for ; Wed, 8 Apr 2009 07:20:03 -0700 (PDT) Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id n38EL9I8025100 for ; Wed, 8 Apr 2009 09:21:09 -0500 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Apr 2009 09:21:09 -0500 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_01C9B855.43037BB7" Date: Wed, 8 Apr 2009 09:21:08 -0500 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B0549B35C@USDALSMBS03.ad3.ad.alcatel.com> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A03718324@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call thread-index: AcmgyPWOuN2jJRCTSJyF9zjH3IElPQXi7eEw References: <0458D2EE0C36744BABB36BE37805C29A03718324@FRVELSMBS11.ad2.ad.alcatel.com> From: "AISSAOUI Mustapha" To: "BOCCI Matthew" , X-OriginalArrivalTime: 08 Apr 2009 14:21:09.0244 (UTC) FILETIME=[42FDF3C0:01C9B855] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call 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, 08 Apr 2009 14:20:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B855.43037BB7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, as requested by Matthew, I reviewed this draft and I have compiled my comments below. =20 Regards, Mustapha. --------------------------------------------------- Comments on draft-ietf-pwe3-vccv-bfd-03 1. Section 3.1, last paragraph states: " When the downstream PE (D-PE) does not receive BFD control messages from its upstream peer PE (U-PE) during a certain number of transmission intervals (a number provisioned by the operator as Detect Mult), D-PE declares that the PW in its receive direction is down. In other words, D-PE enters the "forward defect" state for this PW. After this calculated Detection Time, D-PE declares the session Down, and signals this to the remote end via the State (Sta) with Diagnostic code 1 (Control Detection Time Expired). In turn, U-PE declares the PW is down in its transmit direction setting the State to Down, and it using Diagnostic code 3 (Neighbor signaled session down) in its control messages to D-PE. U-PE enters the "reverse defect" state for this PW. If needed, how it further processes this error condition, and conveys this status to the attachment circuits is out of the scope of this specification, and is instead defined in [I-D.ietf-pwe3-oam-msg-map].=20 " MA> I do not believe that BFD as defined today supports this mode of operation. This mode requires that each PE be able to declare the PW to be down in the receive direction independently based on not receiving a number of BFD control messages during a number of time intervals. This mode would be similar to the way ATM and Ethernet CC work.=20 However, BFD requires that the sender of the messages declares the state of the PW to be down if replies to its own BFD messages were not received for a number of time intervals.=20 Given that, the sender cannot tell which direction of the PW is down, it must enter the PW receive defect state as explained in draft-ietf-pwe3-oam-msg-map-09.txt. However, the receiver of the messages can send a BFD status change asynchronously and in this case the sender can be sure the defect is in the forward direction, which means it must enter the PW trasmit defect state. I believe Appendix B of draft-ietf-pwe3-oam-msg-map-09.txt must also be corrected as it states: " Furthermore, the detection of a fault could occur at different points in the network and there are several ways the observing PE determines a fault exists:=20 a. egress or ingress PE detection of failure (e.g. BFD)=20 .... " 2. Section 3.2 - BFD Encapsulation MA> We need to document how the reply to the BFD packet is encapsulated. The following reply modes of "2- Reply via an IPv4/IPv6 UDP packet", "3 - Reply via an IPv4/IPv6 UDP packet with Router Alert", and "4 - Reply via application level control channel" must be documented for the UDP/IP encapsulation. The PW-ACH necapsulation can only support reply mode 4 since it cannot be routed. I believe the relevant text for this is covered in draft-ietf-bfd-mpls-07.txt.=20 3. Section 3.3, item (3) reads: " 4. Pseudowires that do not use a CW or L2SS using the PW Associated Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., PW-ACH encapsulation of BFD, without IP/UDP headers).=20 A. PWs that use a PW-ACH include CC Type 1 (for both MPLS and L2TPv3 as defined in Sections 5.1.1 and 6.1 of [RFC5085]), and MPLS CC Types 2 and 3 when using a Control Word (as specified in Sections 5.1.2 and 5.1.3 of [RFC5085]). This restriction stems from the fact that the PW-ACH contains a Protocol Identification (PID) field, the Channel Type.=20 B. PWs that do not use a PW-ACH can use the VCCV BFD encapsulation with IP/UDP headers, including its concurrent use along with another CV Type that uses an encapsulation with IP headers (e.g., ICMP Ping or LSP Ping). For example, as specified in Section 7 of [RFC4385], a Pseudowire operating without CW MUST NOT use the PW-ACH.=20 " MA> This paragraph is trying to convey too many things and is confusing. I propose we split it into the case of PW with ACH and PW with no ACH. Here is a proposal which I believe covers all the intended points: " 4. A PW that uses the PW-ACH must signal CC Type 1 only in the VCCV parameter included in the interface parameter field of the PW ID FEC TLV or the sub-TLV interface parameter of the Generalized PW ID FEC TLV as described in [RFC 5085].=20 5. A PW that does not use a PW-ACH must signal CC Types 2 and/or 3 in the VCCV parameter included in the interface parameter field of the PW ID FEC TLV or the sub-TLV interface parameter of the Generalized PW ID FEC TLV as described in [RFC 5085]. For example, this can be a PW which is configured not to use the CW on the user packets. As specified in Section 7 of [RFC4385], this PW MUST NOT use the PW-ACH.=20 6. A PW that does not use the PW-ACH MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., PW-ACH encapsulation of BFD, without IP/UDP headers). This restriction stems from the fact that the PW-ACH contains a Protocol Identification (PID) field, the Channel Type, which is the only way to identify BFD messages with these CV types. 7. A PW can use the VCCV BFD encapsulation with IP/UDP headers, including its concurrent use along with another CV type that uses an encapsulation with IP headers (e.g., ICMP Ping or LSP Ping), regardless if it is configured to use PW-ACH or not. " 5. Section 3.3, item (4) " 4. Only a single BFD CV Type can be selected and used. All BFD CV Types are mutually exclusive with the rest, after selecting a BFD CV Type, a node MUST NOT use any of the other three BFD CV Types.=20 " MA> It must be stated that in order to change the negotiation and selection of the BFD CV types, the PW must be torn down and re-signaled. --------------------------------------------------- ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: Monday, March 09, 2009 11:09 AM To: pwe3@ietf.org Subject: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call =09 =09 This is the start of working group last call on draft-ietf-pwe3-vccv-bfd-03.txt=20 This draft can be found at:=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-03.txt =20 The last call will close on Monday 6th April 2009.=20 Please read the document and provide feedback to the PWE3 list.=20 Many thanks to the following, who have also kindly agreed to review the draft and provide comments to the list:=20 Ben Niven-Jenkins=20 Mustapha Aissaoui=20 Luca Martini=20 Yaakov Stein=20 Best regards=20 Matthew=20 ------_=_NextPart_001_01C9B855.43037BB7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-pwe3-vccv-bfd-03.txt WG last call
Dear all,
as requested by Matthew, I reviewed this draft and I have=20 compiled my comments below.
 
Regards,
Mustapha.
---------------------------------------------------

Comments on=20 draft-ietf-pwe3-vccv-bfd-03

1. Section 3.1, last paragraph states:

"

When the downstream PE (D-PE) does not receive BFD control messages = from its=20 upstream peer PE (U-PE) during a certain number of transmission = intervals (a=20 number provisioned by the operator as Detect Mult), D-PE declares that = the PW in=20 its receive direction is down. In other words, D-PE enters the "forward = defect"=20 state for this PW. After this calculated Detection Time, D-PE declares = the=20 session Down, and signals this to the remote end via the State (Sta) = with=20 Diagnostic code 1 (Control Detection Time Expired). In turn, U-PE = declares the=20 PW is down in its transmit direction setting the State to Down, and it = using=20 Diagnostic code 3 (Neighbor signaled session down) in its control = messages to=20 D-PE. U-PE enters the "reverse defect" state for this PW. If needed, how = it=20 further processes this error condition, and conveys this status to the=20 attachment circuits is out of the scope of this specification, and is = instead=20 defined in [I-D.ietf-pwe3-oam-msg-map].

"

MA> I do not believe that BFD as defined today supports this mode = of=20 operation. This mode requires that each PE be able to declare the PW to = be down=20 in the receive direction independently based on not receiving a number = of BFD=20 control messages during a number of time intervals. This mode would be = similar=20 to the way ATM and Ethernet CC work.

However, BFD requires that the sender of the messages declares the = state of=20 the PW to be down if replies to its own BFD messages were not received = for a=20 number of time intervals.

Given that, the sender cannot tell which direction of the PW is down, = it must=20 enter the PW receive defect state as explained in=20 draft-ietf-pwe3-oam-msg-map-09.txt. However, the receiver of the = messages can=20 send a BFD status change asynchronously and in this case the sender can = be sure=20 the defect is in the forward direction, which means it must enter the PW = trasmit=20 defect state.

I believe Appendix B of draft-ietf-pwe3-oam-msg-map-09.txt must also = be=20 corrected as it states:

"

Furthermore, the detection of a fault could occur at different points = in the=20 network and there are several ways the observing PE determines a fault = exists:=20

a. egress or ingress PE detection of failure (e.g. BFD)

….

"

2. Section 3.2 - BFD Encapsulation

MA> We need to document how the reply to the BFD packet is = encapsulated.=20 The following reply modes of "2-=20 Reply via an IPv4/IPv6 UDP packet", "3 - Reply via an IPv4/IPv6 UDP = packet with=20 Router Alert", and "4 - Reply via application level control = channel" must=20 be documented for the UDP/IP=20 encapsulation. The PW-ACH = necapsulation=20 can only support reply mode 4 since it cannot be routed. I = believe=20 the relevant text for this = is covered=20 in draft-ietf-bfd-mpls-07.txt.

3. Section 3.3, item (3) reads:

"

4. Pseudowires that do not use a CW or L2SS using the PW Associated = Channel=20 Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., PW-ACH = encapsulation of=20 BFD, without IP/UDP headers).

A. PWs that use a PW-ACH include CC Type 1 (for both MPLS and L2TPv3 = as=20 defined in Sections 5.1.1 and 6.1 of [RFC5085]), and MPLS CC Types 2 and = 3 when=20 using a Control Word (as specified in Sections 5.1.2 and 5.1.3 of = [RFC5085]).=20 This restriction stems from the fact that the PW-ACH contains a Protocol = Identification (PID) field, the Channel Type.

B. PWs that do not use a PW-ACH can use the VCCV BFD encapsulation = with=20 IP/UDP headers, including its concurrent use along with another CV Type = that=20 uses an encapsulation with IP headers (e.g., ICMP Ping or LSP Ping). For = example, as specified in Section 7 of [RFC4385], a Pseudowire operating = without=20 CW MUST NOT use the PW-ACH.

"

MA> This paragraph is trying to convey too many things and is = confusing. I=20 propose we split it into the case of PW with ACH and PW with no ACH. = Here is a=20 proposal which I believe covers all the intended points:

"

4. A PW that uses the = PW-ACH must=20 signal CC Type 1 only in the VCCV parameter included in the interface = parameter=20 field of the PW ID FEC TLV or the sub-TLV interface parameter of the = Generalized=20 PW ID FEC TLV as described in [RFC 5085].

5. A PW that does not use a PW-ACH must signal CC Types 2 and/or 3 in = the=20 VCCV parameter included in the interface parameter field of the PW ID = FEC TLV or=20 the sub-TLV interface parameter of the Generalized PW ID FEC TLV as = described in=20 [RFC 5085]. For example, this can be a PW which is configured not to use = the CW=20 on the user packets. As specified in Section 7 of [RFC4385], this PW = MUST NOT=20 use the PW-ACH.

6. A PW that = does not use=20 the PW-ACH MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., PW-ACH=20 encapsulation of BFD, without IP/UDP headers). This restriction stems = from the=20 fact that the PW-ACH contains a Protocol Identification (PID) field, the = Channel=20 Type, which is the only way to identify BFD messages with these CV=20 types.

7. A PW can use the VCCV BFD encapsulation with IP/UDP headers, = including its=20 concurrent use along with another CV type that uses an encapsulation = with IP=20 headers (e.g., ICMP Ping or LSP Ping), regardless if it is configured to = use=20 PW-ACH or not.

"

5. Section 3.3, item (4)

"

4. Only a single BFD CV Type can be selected and used. All BFD CV = Types are=20 mutually exclusive with the rest, after selecting a BFD CV Type, a node = MUST NOT=20 use any of the other three BFD CV Types.

"

MA> It must be stated that in order to change the negotiation and=20 selection of the BFD CV types, the PW must be torn down and re-signaled. =

---------------------------------------------------

From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI=20 Matthew
Sent: Monday, March 09, 2009 11:09 AM
To:=20 pwe3@ietf.org
Subject: [PWE3] = draft-ietf-pwe3-vccv-bfd-03.txt WG=20 last call

This is the start of working = group last=20 call on draft-ietf-pwe3-vccv-bfd-03.txt

This draft can be found = at:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-03.= txt=20

The last call will close on = Monday 6th=20 April 2009.

Please read the document and = provide=20 feedback to the PWE3 list.

Many thanks to the following, = who have also=20 kindly agreed to review the draft and provide comments to the = list:=20
Ben Niven-Jenkins =
Mustapha Aissaoui

Luca Martini

Yaakov Stein

Best regards

Matthew=20



------_=_NextPart_001_01C9B855.43037BB7-- From lucyyong@huawei.com Wed Apr 8 12:17:52 2009 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 627553A6B76 for ; Wed, 8 Apr 2009 12:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.608, 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 KIZ44XNw9HdE for ; Wed, 8 Apr 2009 12:17:51 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 1A4943A6895 for ; Wed, 8 Apr 2009 12:17:51 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHS007T0QZL8N@usaga04-in.huawei.com> for pwe3@ietf.org; Wed, 08 Apr 2009 14:18:58 -0500 (CDT) Received: from Y73674 ([10.124.12.103]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHS00GSVQZJAK@usaga04-in.huawei.com> for pwe3@ietf.org; Wed, 08 Apr 2009 14:18:57 -0500 (CDT) Date: Wed, 08 Apr 2009 14:18:55 -0500 From: Lucy Yong In-reply-to: To: "'Andrew G. Malis'" , jiang.xiaowei@zte.com.cn Message-id: <008701c9b87e$dd04f710$670c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_bESbKkhVqMcWmxP6H4PPEg)" Thread-index: Acm4UAD5+BpXMR5JRNi4jt5wB2yJ+QALTT6g References: Cc: pwe3@ietf.org, stbryant@cisco.com Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? 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, 08 Apr 2009 19:17:52 -0000 This is a multi-part message in MIME format. --Boundary_(ID_bESbKkhVqMcWmxP6H4PPEg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Andy and XiaoWei, Since the purpose of packet-PW is to create a virtual physical interface for two connected client LSRs and allow multiple client protocols run over it. Assume the client LSP is IP router, it runs OSPF or IS-IS. To support the routing protocol properly running, IP interface is configured over a packet-PW. Hello protocol is normally activated over IP interface. However, if we want to use packet-PW state as IP interface state, we need to turn off hello protocol. Is that right? That is my second point in previous e-mail. Thanks, Lucy _____ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G. Malis Sent: Wednesday, April 08, 2009 8:42 AM To: jiang.xiaowei@zte.com.cn Cc: pwe3@ietf.org; stbryant@cisco.com Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? Jiang, I don't think so, but we should look more closely at the details on mapping between the virtual interface state and PW status reporting (without being implementation-dependent) to make sure we've got the all of the details covered. Lucy's point 3 is a good one as well. Thanks, Andy On Wed, Apr 8, 2009 at 7:46 AM, wrote: Andy, Is there any need for Packet-PW to maintain any kind of state machine for virtual interface status like Lucy Yong mentioned? Thanks, Albert Lucy Yong sender: pwe3-bounces@ietf.org 2009-04-01 01:13 to 'Stewart Bryant' , pwe3@ietf.org, "'Malis, Andrew G. (Andy)'" cc topic [PWE3] comments on packet pw Hi Stewart and Andy, I support this draft to become WG draft. Congratulation!! I also have some comments on the draft: 1) Since Packet PW requires using CW, it is necessary to state how to use flow label and S/N for packet PW. 2) It is good to have the PW status mapped to virtual interfaces. However, each protocol interface may have its own link status protocol running, the draft should state the procedures to determine interface status, or require each protocol interface to turn off its link protocol when using Packet PW 3) Since Packet PW acts as a data link between two clients LSRs, the draft should state link operational procedures (for client networks) over a packet PW such as how to determine admin cost, TE metrics, etc. 4) I assume that a Packet PW can obtain transport resiliency from server MPLS network, it would be nice for the draft to state them and considers that the consequence may change admin cost in client networks. Cheers, Lucy_______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 "Andrew G. Malis" 2009-04-04 23:39 jiang.xiaowei@zte.com.cn stbryant@cisco.com, pwe3@ietf.org Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? Jiang, Yes it could, but in addition to higher overhead it would also require running the PPP state machine and using PPP options. We wanted to keep this as simple as possible. Thanks, Andy 2009/4/3 : > > Sir, > > Could rfc4618 Encapsulation Methods for Transport of PPP/High-Level Data > Link Control (HDLC) over MPLS Networks > be used as a solution for the scenario in this draft? (although have more > encapsulation overhead) > > Thank you! --Boundary_(ID_bESbKkhVqMcWmxP6H4PPEg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Andy and XiaoWei,

 

Since the purpose of packet-PW is to create a virtual physical interface for two connected client LSRs and allow multiple client protocols run over it. Assume the client LSP is IP router, it runs OSPF or IS-IS. To support the routing protocol properly running, IP interface is configured over a packet-PW. Hello protocol is normally activated over IP interface. However, if we want to use packet-PW state as IP interface state, we need to turn off hello protocol. Is that right? That is my second point in previous e-mail.

 

Thanks,

Lucy

 


From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Wednesday, April 08, 2009 8:42 AM
To: jiang.xiaowei@zte.com.cn
Cc: pwe3@ietf.org; stbryant@cisco.com
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?

 

Jiang,

 

I don't think so, but we should look more closely at the details on mapping between the virtual interface state and PW status reporting (without being implementation-dependent) to make sure we've got the all of the details covered. Lucy's point 3 is a good one as well.

 

Thanks,

Andy

 

On Wed, Apr 8, 2009 at 7:46 AM, <jiang.xiaowei@zte.com.cn> wrote:


Andy,

Is there any need for Packet-PW to maintain any kind of state machine for virtual interface status like Lucy Yong mentioned?

Thanks,
Albert



Lucy Yong <lucyyong@huawei.com>
sender:  pwe3-bounces@ietf.org

2009-04-01 01:13

to

'Stewart Bryant' <stbryant@cisco.com>, pwe3@ietf.org, "'Malis, Andrew G. (Andy)'" <andrew.g.malis@verizon.com>

cc

 

topic

[PWE3] comments on packet pw

 

 

 




Hi Stewart and Andy,
 
I support this draft to become WG draft. Congratulation!!
I also have some comments on the draft:
 
1)     Since Packet PW requires using CW, it is necessary to state how to use flow label and S/N for packet PW.
2)     It is good to have the PW status mapped to virtual interfaces. However, each protocol interface may have its own link status protocol running, the draft should state the procedures to determine interface status, or require each protocol interface to turn off its link protocol when using Packet PW
3)     Since Packet PW acts as a data link between two clients LSRs, the draft should state link operational procedures (for client networks) over a packet PW such as how to determine admin cost, TE metrics, etc.
4)     I assume that a Packet PW can obtain transport resiliency from server MPLS network, it would be nice for the draft to state them and considers that the consequence may change admin cost in client networks.
 
Cheers,
Lucy_______________________________________________





"Andrew G. Malis" <amalis@gmail.com>

2009-04-04 23:39

 

 

stbryant@cisco.com, pwe3@ietf.org

 

Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?

 

 

 

 


Jiang,

Yes it could, but in addition to higher overhead it would also require
running the PPP state machine and using PPP options. We wanted to keep
this as simple as possible.

Thanks,
Andy

2009/4/3  <jiang.xiaowei@zte.com.cn>:
>
> Sir,
>
> Could rfc4618 Encapsulation Methods for Transport of PPP/High-Level Data
> Link Control (HDLC) over MPLS Networks
> be used as a solution for the scenario in this draft? (although have more
> encapsulation overhead)
>
> Thank you!

 

--Boundary_(ID_bESbKkhVqMcWmxP6H4PPEg)-- From busschbach@alcatel-lucent.com Wed Apr 8 12:21:45 2009 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 7760E3A6A3A for ; Wed, 8 Apr 2009 12:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 pPLENWAsbFVw for ; Wed, 8 Apr 2009 12:21:34 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 657E43A6A5C for ; Wed, 8 Apr 2009 12:21:34 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n38JMfCc006927 for ; Wed, 8 Apr 2009 14:22:41 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.11]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Apr 2009 14:22:41 -0500 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_01C9B87F.62545DD8" Date: Wed, 8 Apr 2009 14:22:39 -0500 Message-ID: In-Reply-To: <4A5028372622294A99B8FFF6BD06EB7B0549B35C@USDALSMBS03.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call thread-index: AcmgyPWOuN2jJRCTSJyF9zjH3IElPQXi7eEwAApEkvA= References: <0458D2EE0C36744BABB36BE37805C29A03718324@FRVELSMBS11.ad2.ad.alcatel.com> <4A5028372622294A99B8FFF6BD06EB7B0549B35C@USDALSMBS03.ad3.ad.alcatel.com> From: "Busschbach, Peter B (Peter)" To: "Aissaoui, Mustapha (Mustapha)" , "Bocci, Matthew (Matthew)" , X-OriginalArrivalTime: 08 Apr 2009 19:22:41.0117 (UTC) FILETIME=[6296B0D0:01C9B87F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call 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, 08 Apr 2009 19:21:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B87F.62545DD8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable MA> I do not believe that BFD as defined today supports this mode of operation. This mode requires that each MA> PE be able to declare the PW to be down in the receive direction independently based on not receiving a MA> number of BFD control messages during a number of time intervals. This mode would be similar to the way MA> ATM and Ethernet CC work.=20 =20 Mustapha, =20 I had a different interpretation of the way BFD works. In the asynchornous mode, which the vccv-bfd draft prescribes, each end point checks for the arrival of control messages sent by the remote end. If it does not receive control messages, it enters the DOWN state. This is specified in section 6.2. =20 Since the flow of control messages consists of two independent, uni-directional flows, isn't it true that the downstream PE can autonomously declare a receive defect? =20 Peter ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of AISSAOUI Mustapha Sent: Wednesday, April 08, 2009 10:21 AM To: Bocci, Matthew (Matthew); pwe3@ietf.org Subject: Re: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call =09 =09 Dear all, as requested by Matthew, I reviewed this draft and I have compiled my comments below. =20 Regards, Mustapha. --------------------------------------------------- Comments on draft-ietf-pwe3-vccv-bfd-03 1. Section 3.1, last paragraph states: " When the downstream PE (D-PE) does not receive BFD control messages from its upstream peer PE (U-PE) during a certain number of transmission intervals (a number provisioned by the operator as Detect Mult), D-PE declares that the PW in its receive direction is down. In other words, D-PE enters the "forward defect" state for this PW. After this calculated Detection Time, D-PE declares the session Down, and signals this to the remote end via the State (Sta) with Diagnostic code 1 (Control Detection Time Expired). In turn, U-PE declares the PW is down in its transmit direction setting the State to Down, and it using Diagnostic code 3 (Neighbor signaled session down) in its control messages to D-PE. U-PE enters the "reverse defect" state for this PW. If needed, how it further processes this error condition, and conveys this status to the attachment circuits is out of the scope of this specification, and is instead defined in [I-D.ietf-pwe3-oam-msg-map].=20 " MA> I do not believe that BFD as defined today supports this mode of operation. This mode requires that each PE be able to declare the PW to be down in the receive direction independently based on not receiving a number of BFD control messages during a number of time intervals. This mode would be similar to the way ATM and Ethernet CC work.=20 However, BFD requires that the sender of the messages declares the state of the PW to be down if replies to its own BFD messages were not received for a number of time intervals.=20 Given that, the sender cannot tell which direction of the PW is down, it must enter the PW receive defect state as explained in draft-ietf-pwe3-oam-msg-map-09.txt. However, the receiver of the messages can send a BFD status change asynchronously and in this case the sender can be sure the defect is in the forward direction, which means it must enter the PW trasmit defect state. I believe Appendix B of draft-ietf-pwe3-oam-msg-map-09.txt must also be corrected as it states: " Furthermore, the detection of a fault could occur at different points in the network and there are several ways the observing PE determines a fault exists:=20 a. egress or ingress PE detection of failure (e.g. BFD)=20 .... " 2. Section 3.2 - BFD Encapsulation MA> We need to document how the reply to the BFD packet is encapsulated. The following reply modes of "2- Reply via an IPv4/IPv6 UDP packet", "3 - Reply via an IPv4/IPv6 UDP packet with Router Alert", and "4 - Reply via application level control channel" must be documented for the UDP/IP encapsulation. The PW-ACH necapsulation can only support reply mode 4 since it cannot be routed. I believe the relevant text for this is covered in draft-ietf-bfd-mpls-07.txt.=20 3. Section 3.3, item (3) reads: " 4. Pseudowires that do not use a CW or L2SS using the PW Associated Channel Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., PW-ACH encapsulation of BFD, without IP/UDP headers).=20 A. PWs that use a PW-ACH include CC Type 1 (for both MPLS and L2TPv3 as defined in Sections 5.1.1 and 6.1 of [RFC5085]), and MPLS CC Types 2 and 3 when using a Control Word (as specified in Sections 5.1.2 and 5.1.3 of [RFC5085]). This restriction stems from the fact that the PW-ACH contains a Protocol Identification (PID) field, the Channel Type. B. PWs that do not use a PW-ACH can use the VCCV BFD encapsulation with IP/UDP headers, including its concurrent use along with another CV Type that uses an encapsulation with IP headers (e.g., ICMP Ping or LSP Ping). For example, as specified in Section 7 of [RFC4385], a Pseudowire operating without CW MUST NOT use the PW-ACH.=20 " MA> This paragraph is trying to convey too many things and is confusing. I propose we split it into the case of PW with ACH and PW with no ACH. Here is a proposal which I believe covers all the intended points: " 4. A PW that uses the PW-ACH must signal CC Type 1 only in the VCCV parameter included in the interface parameter field of the PW ID FEC TLV or the sub-TLV interface parameter of the Generalized PW ID FEC TLV as described in [RFC 5085].=20 5. A PW that does not use a PW-ACH must signal CC Types 2 and/or 3 in the VCCV parameter included in the interface parameter field of the PW ID FEC TLV or the sub-TLV interface parameter of the Generalized PW ID FEC TLV as described in [RFC 5085]. For example, this can be a PW which is configured not to use the CW on the user packets. As specified in Section 7 of [RFC4385], this PW MUST NOT use the PW-ACH.=20 6. A PW that does not use the PW-ACH MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., PW-ACH encapsulation of BFD, without IP/UDP headers). This restriction stems from the fact that the PW-ACH contains a Protocol Identification (PID) field, the Channel Type, which is the only way to identify BFD messages with these CV types. 7. A PW can use the VCCV BFD encapsulation with IP/UDP headers, including its concurrent use along with another CV type that uses an encapsulation with IP headers (e.g., ICMP Ping or LSP Ping), regardless if it is configured to use PW-ACH or not. " 5. Section 3.3, item (4) " 4. Only a single BFD CV Type can be selected and used. All BFD CV Types are mutually exclusive with the rest, after selecting a BFD CV Type, a node MUST NOT use any of the other three BFD CV Types.=20 " MA> It must be stated that in order to change the negotiation and selection of the BFD CV types, the PW must be torn down and re-signaled.=20 --------------------------------------------------- =09 ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: Monday, March 09, 2009 11:09 AM To: pwe3@ietf.org Subject: [PWE3] draft-ietf-pwe3-vccv-bfd-03.txt WG last call =09 =09 This is the start of working group last call on draft-ietf-pwe3-vccv-bfd-03.txt=20 This draft can be found at:=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-03.txt =20 The last call will close on Monday 6th April 2009.=20 Please read the document and provide feedback to the PWE3 list.=20 Many thanks to the following, who have also kindly agreed to review the draft and provide comments to the list:=20 Ben Niven-Jenkins=20 Mustapha Aissaoui=20 Luca Martini=20 Yaakov Stein=20 Best regards=20 Matthew=20 ------_=_NextPart_001_01C9B87F.62545DD8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable draft-ietf-pwe3-vccv-bfd-03.txt WG last call
MA> I do not = believe that BFD=20 as defined today supports this mode of operation. This mode requires = that=20 each
MA> PE be able to declare the PW to = be down=20 in the receive direction independently based on not receiving=20 a
MA> number of BFD control = messages=20 during a number of time intervals. This mode would be similar to the=20 way
MA> ATM and Ethernet CC work.=20
 
Mustapha,
 
I=20 had a different interpretation of the way BFD works. In the asynchornous = mode,=20 which the vccv-bfd draft prescribes, each end point checks for the = arrival of=20 control messages sent by the remote end. If it does not receive control=20 messages, it enters the DOWN state. This is specified in section=20 6.2.
 
Since the flow of control messages consists of two independent, = uni-directional flows, isn't it true that the downstream PE can = autonomously=20 declare a receive defect?
 
Peter


From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of AISSAOUI=20 Mustapha
Sent: Wednesday, April 08, 2009 10:21 = AM
To:=20 Bocci, Matthew (Matthew); pwe3@ietf.org
Subject: Re: [PWE3]=20 draft-ietf-pwe3-vccv-bfd-03.txt WG last call

Dear all,
as requested by Matthew, I reviewed this draft and I = have=20 compiled my comments below.
 
Regards,
Mustapha.
---------------------------------------------------

Comments on=20 draft-ietf-pwe3-vccv-bfd-03

1. Section 3.1, last paragraph states:

"

When the downstream PE (D-PE) does not receive BFD control messages = from=20 its upstream peer PE (U-PE) during a certain number of transmission = intervals=20 (a number provisioned by the operator as Detect Mult), D-PE declares = that the=20 PW in its receive direction is down. In other words, D-PE enters the = "forward=20 defect" state for this PW. After this calculated Detection Time, D-PE = declares=20 the session Down, and signals this to the remote end via the State = (Sta) with=20 Diagnostic code 1 (Control Detection Time Expired). In turn, U-PE = declares the=20 PW is down in its transmit direction setting the State to Down, and it = using=20 Diagnostic code 3 (Neighbor signaled session down) in its control = messages to=20 D-PE. U-PE enters the "reverse defect" state for this PW. If needed, = how it=20 further processes this error condition, and conveys this status to the = attachment circuits is out of the scope of this specification, and is = instead=20 defined in [I-D.ietf-pwe3-oam-msg-map].

"

MA> I do not believe that BFD as defined today supports this = mode of=20 operation. This mode requires that each PE be able to declare the PW = to be=20 down in the receive direction independently based on not receiving a = number of=20 BFD control messages during a number of time intervals. This mode = would be=20 similar to the way ATM and Ethernet CC work.

However, BFD requires that the sender of the messages declares the = state of=20 the PW to be down if replies to its own BFD messages were not received = for a=20 number of time intervals.

Given that, the sender cannot tell which direction of the PW is = down, it=20 must enter the PW receive defect state as explained in=20 draft-ietf-pwe3-oam-msg-map-09.txt. However, the receiver of the = messages can=20 send a BFD status change asynchronously and in this case the sender = can be=20 sure the defect is in the forward direction, which means it must enter = the PW=20 trasmit defect state.

I believe Appendix B of draft-ietf-pwe3-oam-msg-map-09.txt must = also be=20 corrected as it states:

"

Furthermore, the detection of a fault could occur at different = points in=20 the network and there are several ways the observing PE determines a = fault=20 exists:

a. egress or ingress PE detection of failure (e.g. BFD)

….

"

2. Section 3.2 - BFD Encapsulation

MA> We need to document how the reply to the BFD packet is = encapsulated.=20 The following reply modes of "2-=20 Reply via an IPv4/IPv6 UDP packet", "3 - Reply via an IPv4/IPv6 UDP = packet=20 with Router Alert", and "4 - Reply via application level control=20 channel" must be documented = for the=20 UDP/IP encapsulation. The = PW-ACH=20 necapsulation can only support reply mode 4 since it cannot be=20 routed. I believe the relevant=20 text for this is covered in draft-ietf-bfd-mpls-07.txt.

3. Section 3.3, item (3) reads:

"

4. Pseudowires that do not use a CW or L2SS using the PW Associated = Channel=20 Header MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., PW-ACH = encapsulation=20 of BFD, without IP/UDP headers).

A. PWs that use a PW-ACH include CC Type 1 (for both MPLS and = L2TPv3 as=20 defined in Sections 5.1.1 and 6.1 of [RFC5085]), and MPLS CC Types 2 = and 3=20 when using a Control Word (as specified in Sections 5.1.2 and 5.1.3 of = [RFC5085]). This restriction stems from the fact that the PW-ACH = contains a=20 Protocol Identification (PID) field, the Channel Type.

B. PWs that do not use a PW-ACH can use the VCCV BFD encapsulation = with=20 IP/UDP headers, including its concurrent use along with another CV = Type that=20 uses an encapsulation with IP headers (e.g., ICMP Ping or LSP Ping). = For=20 example, as specified in Section 7 of [RFC4385], a Pseudowire = operating=20 without CW MUST NOT use the PW-ACH.

"

MA> This paragraph is trying to convey too many things and is = confusing.=20 I propose we split it into the case of PW with ACH and PW with no ACH. = Here is=20 a proposal which I believe covers all the intended points:

"

4. A PW that uses the = PW-ACH must=20 signal CC Type 1 only in the VCCV parameter included in the interface=20 parameter field of the PW ID FEC TLV or the sub-TLV interface = parameter of the=20 Generalized PW ID FEC TLV as described in [RFC 5085].

5. A PW that does not use a PW-ACH must signal CC Types 2 and/or 3 = in the=20 VCCV parameter included in the interface parameter field of the PW ID = FEC TLV=20 or the sub-TLV interface parameter of the Generalized PW ID FEC TLV as = described in [RFC 5085]. For example, this can be a PW which is = configured not=20 to use the CW on the user packets. As specified in Section 7 of = [RFC4385],=20 this PW MUST NOT use the PW-ACH.

6. A PW that = does not use=20 the PW-ACH MUST NOT use the BFD CV Types 0x10 or 0x20 (i.e., PW-ACH=20 encapsulation of BFD, without IP/UDP headers). This restriction stems = from the=20 fact that the PW-ACH contains a Protocol Identification (PID) field, = the=20 Channel Type, which is the only way to identify BFD messages with = these CV=20 types.

7. A PW can use the VCCV BFD encapsulation with IP/UDP headers, = including=20 its concurrent use along with another CV type that uses an = encapsulation with=20 IP headers (e.g., ICMP Ping or LSP Ping), regardless if it is = configured to=20 use PW-ACH or not.

"

5. Section 3.3, item (4)

"

4. Only a single BFD CV Type can be selected and used. All BFD CV = Types are=20 mutually exclusive with the rest, after selecting a BFD CV Type, a = node MUST=20 NOT use any of the other three BFD CV Types.

"

MA> It must be stated that in order to change the negotiation = and=20 selection of the BFD CV types, the PW must be torn down and = re-signaled.=20

---------------------------------------------------

From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of BOCCI=20 Matthew
Sent: Monday, March 09, 2009 11:09 = AM
To:=20 pwe3@ietf.org
Subject: [PWE3] = draft-ietf-pwe3-vccv-bfd-03.txt WG=20 last call

This is the start of working = group last=20 call on draft-ietf-pwe3-vccv-bfd-03.txt

This draft can be found = at:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-03.= txt=20

The last call will close on = Monday 6th=20 April 2009.

Please read the document and = provide=20 feedback to the PWE3 list.

Many thanks to the following, = who have=20 also kindly agreed to review the draft and provide comments to the=20 list:
Ben = Niven-Jenkins=20
Mustapha Aissaoui =
Luca Martini
Yaakov Stein

Best regards

Matthew=20



------_=_NextPart_001_01C9B87F.62545DD8-- From liu.guoman@zte.com.cn Sun Apr 12 19:30:11 2009 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 EFB883A6CB9 for ; Sun, 12 Apr 2009 19:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.035 X-Spam-Level: X-Spam-Status: No, score=-95.035 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 vhbUts5vKv-T for ; Sun, 12 Apr 2009 19:30:11 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 719F53A6C9F for ; Sun, 12 Apr 2009 19:30:10 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111641397396305; Mon, 13 Apr 2009 10:22:07 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 90033.3171924358; Mon, 13 Apr 2009 10:28:00 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n3D2V4aF043641; Mon, 13 Apr 2009 10:31:04 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <49D4A072.9090308@cisco.com> To: stbryant@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Mon, 13 Apr 2009 10:28:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-13 10:31:03, Serialize complete at 2009-04-13 10:31:03 Content-Type: multipart/alternative; boundary="=_alternative 000DD2D348257597_=" X-MAIL: mse1.zte.com.cn n3D2V4aF043641 Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? 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, 13 Apr 2009 02:30:12 -0000 This is a multipart message in MIME format. --=_alternative 000DD2D348257597_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U3Rld2FydDoNCiAgSSB1bmRlcnN0YW5kIHlvdXIgbWVhbmluZyAsIGJ1dCBJIHRoaW5rIGl0IHVu bmVjZXNzYXJ5IHRvIHVzZSBhbmQgYXBwbHkgDQphbm90aGVyIGZsb3cgbGFiZWwuIHdlIG1heSBh ZGQgMiBieXRlcyBmbG93IElEIGluIHNlcnZpY2VzIGhlYWRlciwgc28gYXQgDQpzaW5rIHBvaW50 LCBpdCBpZGVudGlmeSBhbmQgcmUtZW5jYXBzdWxhdGUgdGhlIHNlcnZpY2VzIGNvbnRleHQgYnkg ZmxvdyBpZCANCmFuZCBTTiBpbiBzZXJ2aWNlcyBoZWFkZXIuIA0KZG8geW91IHRoaW5rIHNvLg0K cmVnYXJkcyANCmxpdSANCg0KDQoNClN0ZXdhcnQgQnJ5YW50IDxzdGJyeWFudEBjaXNjby5jb20+ IA0KMjAwOS0wNC0wMiAxOToyNA0Kx+u08Li0ILj4DQpzdGJyeWFudEBjaXNjby5jb20NCg0KDQrK 1bz+yMsNCmxpdS5ndW9tYW5AenRlLmNvbS5jbg0Ks63LzQ0KcHdlM0BpZXRmLm9yZw0K1vfM4g0K UmU6IFtQV0UzXSBkcmFmdC1icnlhbnQtZmlsc2ZpbHMtZmF0LXB3LTAzIHRvIFdHIGRyYWZ0Pw0K DQoNCg0KDQoNCg0KbGl1Lmd1b21hbkB6dGUuY29tLmNuIHdyb3RlOg0KPg0KPiBTdGV3YXJ0Og0K PiBteSBwcm9ibGVtIGlzIDogaWYgdGhlcmUgaXMgYSBtdWx0aW1lZGlhIGRhdGEgZmxvdywgdGhl IGZsb3cgbXVzdCBiZQ0KPiB0cmFuc3BvcnRlZCBpbiBvcmRlci4gb3IgZWxzZSBpdCB3aWxsIG5v dCBiZWNvbWUgYSBtdWx0aW1lZGlhIGZsb3cuDQo+IGhvdyB0byBwcm9jZXNzIHRoZSBkYXRhIGZs b3cgYnkgRUNNUD8NCj4gSU1PLCB0aGVyZSBhcmUgdHdvIHNvbHV0aW9uczoNCj4gMSBhdCBzaW5r IHBvaW50cywgdGhlcmUgYXJlIGVub3VnaCBidWZmZXJzIHRvIHN0b3JlIHRoZSBkYXRhIGZsb3cu DQo+IDIgZHVyaW5nIHRyYW5zcG9ydGluZyB0aGUgZGF0YSBmbG93LCBpdCBtdXN0IHRyYW5zcG9y dCBpbiBvcmRlci4NCj4NCj4gZG8geW91IHRoaW5rIHNvPw0KPiByZWdhcmRzDQo+IGxpdQ0KPg0K WWVzDQoNClJlbWVtYmVyIHRoaXMgZHJhZnQgaXMgc2ltcGx5IGEgdG9vbCB0aGF0IGlzIHVzZWQg dG8gc3ByZWFkIG91dCBhbHJlYWR5DQppZGVudGlmaWVkIGZsb3dzIG92ZXIgdGhlIEVDTVAgc2V0 Lg0KDQpUaGUgcHJvY2Vzc2luZyBpbnRvIGFuZCBvdXQgb2YgYSBmYXQgcHcgaXMgb3V0c2lkZSBp dCdzIHNjb3BlLg0KDQpDbGVhcmx5IHlvdSBjYW4gZW5hYmxlIHMvbiAtIGFwcGx5IHRoZSBMQiBs YWJlbCAtIGFuZCBwdXQgdGhlIGZsb3cgYmFjaw0KdG9nZXRoZXIgYXQgdGhlIGVncmVzcyBpZiB0 aGF0IHN1aXRzIHlvdSBhcHBsaWNhdGlvbiBvdGhlcndpc2UgYXMgeW91DQpzYXkgeW91IGhhdmUg dG8gaGF2ZSBsYXJnZSBlbm91Z2ggZW5kIHRvIGVuZCBiL3cuDQoNClJlbWVtYmVyIHdoYXQgaXQg c2F5cyBpbiB0aGUgUFdFMyBjaGFydGVyIC0gaWYgdGhlIGJlc3QgZWZmb3J0IGVtdWxhdGlvbg0K cHJvdmlkZWQgYnkgUFdFMyBpcyBub3QgZ29vZCBlbm91Z2gsIHRoZW4gZWl0aGVyIHByb3Bvc2Ug YSBiZXR0ZXINCmVtdWxhdGlvbiwgb3IgdXNlIGEgcmVhbCB3aXJlLg0KDQpTdGV3YXJ0DQoNCg0K DQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIn cyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4g UmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kg YW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNv bW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0 dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg dXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3Nl ZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5 IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRo aXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNz YWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3Bh bSBzeXN0ZW0uDQo= --=_alternative 000DD2D348257597_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlN0ZXdhcnQ6PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgSSB1bmRlcnN0YW5kIHlvdXIg bWVhbmluZyAsIGJ1dA0KSSB0aGluayBpdCB1bm5lY2Vzc2FyeSB0byB1c2UgYW5kIGFwcGx5IGFu b3RoZXIgZmxvdyBsYWJlbC4gd2UgbWF5IGFkZA0KMiBieXRlcyBmbG93IElEIGluIHNlcnZpY2Vz IGhlYWRlciwgc28gYXQgc2luayBwb2ludCwgaXQgaWRlbnRpZnkgYW5kIHJlLWVuY2Fwc3VsYXRl DQp0aGUgc2VydmljZXMgY29udGV4dCBieSBmbG93IGlkIGFuZCBTTiBpbiBzZXJ2aWNlcyBoZWFk ZXIuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ZG8geW91IHRo aW5rIHNvLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+cmVnYXJk cyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPmxpdSA8L2ZvbnQ+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+U3Rld2FydCBC cnlhbnQgJmx0O3N0YnJ5YW50QGNpc2NvLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wNC0wMiAxOToyNDwvZm9udD4NCjx0YWJsZSBi b3JkZXI+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCBiZ2NvbG9yPXdoaXRlPg0KPGRpdiBhbGlnbj1j ZW50ZXI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsfrtPC4tCC4+Dxicj4NCnN0YnJ5 YW50QGNpc2NvLmNvbTwvZm9udD48L2Rpdj48L3RhYmxlPg0KPGJyPg0KPHRkIHdpZHRoPTczJT4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmxpdS5ndW9tYW5AenRlLmNvbS5jbjwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+cHdlM0BpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtQ V0UzXSBkcmFmdC1icnlhbnQtZmlsc2ZpbHMtZmF0LXB3LTAzDQp0byBXRyBkcmFmdD88L2ZvbnQ+ PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFi bGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PmxpdS5n dW9tYW5AenRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBTdGV3YXJ0Ojxicj4N CiZndDsgbXkgcHJvYmxlbSBpcyA6IGlmIHRoZXJlIGlzIGEgbXVsdGltZWRpYSBkYXRhIGZsb3cs IHRoZSBmbG93IG11c3QNCmJlPGJyPg0KJmd0OyB0cmFuc3BvcnRlZCBpbiBvcmRlci4gb3IgZWxz ZSBpdCB3aWxsIG5vdCBiZWNvbWUgYSBtdWx0aW1lZGlhIGZsb3cuPGJyPg0KJmd0OyBob3cgdG8g cHJvY2VzcyB0aGUgZGF0YSBmbG93IGJ5IEVDTVA/PGJyPg0KJmd0OyBJTU8sIHRoZXJlIGFyZSB0 d28gc29sdXRpb25zOjxicj4NCiZndDsgMSBhdCBzaW5rIHBvaW50cywgdGhlcmUgYXJlIGVub3Vn aCBidWZmZXJzIHRvIHN0b3JlIHRoZSBkYXRhIGZsb3cuPGJyPg0KJmd0OyAyIGR1cmluZyB0cmFu c3BvcnRpbmcgdGhlIGRhdGEgZmxvdywgaXQgbXVzdCB0cmFuc3BvcnQgaW4gb3JkZXIuPGJyPg0K Jmd0Ozxicj4NCiZndDsgZG8geW91IHRoaW5rIHNvPzxicj4NCiZndDsgcmVnYXJkczxicj4NCiZn dDsgbGl1PGJyPg0KJmd0Ozxicj4NClllczxicj4NCjxicj4NClJlbWVtYmVyIHRoaXMgZHJhZnQg aXMgc2ltcGx5IGEgdG9vbCB0aGF0IGlzIHVzZWQgdG8gc3ByZWFkIG91dCBhbHJlYWR5PGJyPg0K aWRlbnRpZmllZCBmbG93cyBvdmVyIHRoZSBFQ01QIHNldC48YnI+DQo8YnI+DQpUaGUgcHJvY2Vz c2luZyBpbnRvIGFuZCBvdXQgb2YgYSBmYXQgcHcgaXMgb3V0c2lkZSBpdCdzIHNjb3BlLjxicj4N Cjxicj4NCkNsZWFybHkgeW91IGNhbiBlbmFibGUgcy9uIC0gYXBwbHkgdGhlIExCIGxhYmVsIC0g YW5kIHB1dCB0aGUgZmxvdyBiYWNrPGJyPg0KdG9nZXRoZXIgYXQgdGhlIGVncmVzcyBpZiB0aGF0 IHN1aXRzIHlvdSBhcHBsaWNhdGlvbiBvdGhlcndpc2UgYXMgeW91PGJyPg0Kc2F5IHlvdSBoYXZl IHRvIGhhdmUgbGFyZ2UgZW5vdWdoIGVuZCB0byBlbmQgYi93Ljxicj4NCjxicj4NClJlbWVtYmVy IHdoYXQgaXQgc2F5cyBpbiB0aGUgUFdFMyBjaGFydGVyIC0gaWYgdGhlIGJlc3QgZWZmb3J0IGVt dWxhdGlvbjxicj4NCnByb3ZpZGVkIGJ5IFBXRTMgaXMgbm90IGdvb2QgZW5vdWdoLCB0aGVuIGVp dGhlciBwcm9wb3NlIGEgYmV0dGVyPGJyPg0KZW11bGF0aW9uLCBvciB1c2UgYSByZWFsIHdpcmUu PGJyPg0KPGJyPg0KU3Rld2FydDxicj4NCjxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0K PGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGlj ZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7 dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7 bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtS ZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZu YnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7 bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2Nv bnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7 b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJz cDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlh bCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5i c3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRp dHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZu YnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2Vt YWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZu YnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5i c3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5i c3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtz ZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVk Jm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pU RSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 000DD2D348257597_=-- From stbryant@cisco.com Tue Apr 14 00:50:12 2009 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 CD58A3A6A76 for ; Tue, 14 Apr 2009 00:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.557 X-Spam-Level: X-Spam-Status: No, score=-9.557 tagged_above=-999 required=5 tests=[AWL=1.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Gnqj0XipUgu9 for ; Tue, 14 Apr 2009 00:50:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 390343A68AC for ; Tue, 14 Apr 2009 00:50:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,183,1238976000"; d="scan'208";a="38195451" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2009 07:51:21 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3E7pLli011497; Tue, 14 Apr 2009 09:51:21 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3E7pLeo022174; Tue, 14 Apr 2009 07:51:21 GMT Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n3E7pHC11115; Tue, 14 Apr 2009 08:51:17 +0100 (BST) Message-ID: <49E44075.8000808@cisco.com> Date: Tue, 14 Apr 2009 08:51:17 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Lucy Yong References: <008701c9b87e$dd04f710$670c7c0a@china.huawei.com> In-Reply-To: <008701c9b87e$dd04f710$670c7c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4716; t=1239695481; x=1240559481; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20draft-bryant-pwe3-packet-pw-00 .txt=20to=20WG=20draft? |Sender:=20; bh=abI1+o9GWVobF1l1OLt7pXTZvpXWICYcfnL24TkGU7Q=; b=ZSphzbT1caEFiIqSVl/qsqke4lxuUY0gb/tABJkgwR8ZE9ci4uE2i5mNoS DPBM2HI3XoCy1c09iZ2O6YxSmXw2PhRP54saP3DFTvKDD7Q2dG9kWELQKlGM YGTQDYczdx; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? 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: Tue, 14 Apr 2009 07:50:12 -0000 Lucy Turning off bits of the routing protocol is actually quite hard, risks breaking the protocol and requires us to track and reflect those changes in the surrogate protocol. We would therefore want to run the link state routing protocol unmodified including the hellos. Stewart Lucy Yong wrote: > > Hi Andy and XiaoWei, > > > > Since the purpose of packet-PW is to create a virtual physical > interface for two connected client LSRs and allow multiple client > protocols run over it. Assume the client LSP is IP router, it runs > OSPF or IS-IS. To support the routing protocol properly running, IP > interface is configured over a packet-PW. Hello protocol is normally > activated over IP interface. However, if we want to use packet-PW > state as IP interface state, we need to turn off hello protocol. Is > that right? That is my second point in previous e-mail. > > > > Thanks, > > Lucy > > > > ------------------------------------------------------------------------ > > *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On > Behalf Of *Andrew G. Malis > *Sent:* Wednesday, April 08, 2009 8:42 AM > *To:* jiang.xiaowei@zte.com.cn > *Cc:* pwe3@ietf.org; stbryant@cisco.com > *Subject:* Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? > > > > Jiang, > > > > I don't think so, but we should look more closely at the details on > mapping between the virtual interface state and PW status reporting > (without being implementation-dependent) to make sure we've got the > all of the details covered. Lucy's point 3 is a good one as well. > > > > Thanks, > > Andy > > > > On Wed, Apr 8, 2009 at 7:46 AM, > wrote: > > > Andy, > > Is there any need for Packet-PW to maintain any kind of state machine > for virtual interface status like Lucy Yong mentioned? > > Thanks, > Albert > > > > *Lucy Yong >* > sender: pwe3-bounces@ietf.org > > 2009-04-01 01:13 > > > > to > > > > 'Stewart Bryant' >, > pwe3@ietf.org , "'Malis, Andrew G. (Andy)'" > > > > cc > > > > > > topic > > > > [PWE3] comments on packet pw > > > > > > > > > > > > > Hi Stewart and Andy, > > I support this draft to become WG draft. Congratulation!! > I also have some comments on the draft: > > 1) Since Packet PW requires using CW, it is necessary to state how > to use flow label and S/N for packet PW. > 2) It is good to have the PW status mapped to virtual interfaces. > However, *each protocol interface may have its own link status > protocol* running, the draft should state the procedures to determine > interface status, or require each protocol interface to turn off its > link protocol when using Packet PW > 3) Since Packet PW acts as a data link between two clients LSRs, > the draft should state link operational procedures (for client > networks) over a packet PW such as how to determine admin cost, TE > metrics, etc. > 4) I assume that a Packet PW can obtain transport resiliency from > server MPLS network, it would be nice for the draft to state them and > considers that the consequence may change admin cost in client networks. > > Cheers, > Lucy_______________________________________________ > > > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > *"Andrew G. Malis" >* > > 2009-04-04 23:39 > > > > > > > > jiang.xiaowei@zte.com.cn > > > > > > stbryant@cisco.com , pwe3@ietf.org > > > > > > > Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? > > > > > > > > > > > > > Jiang, > > Yes it could, but in addition to higher overhead it would also require > running the PPP state machine and using PPP options. We wanted to keep > this as simple as possible. > > Thanks, > Andy > > 2009/4/3 >: > > > > Sir, > > > > Could rfc4618 Encapsulation Methods for Transport of PPP/High-Level Data > > Link Control (HDLC) over MPLS Networks > > be used as a solution for the scenario in this draft? (although have more > > encapsulation overhead) > > > > Thank you! > > > From stbryant@cisco.com Tue Apr 14 00:53:46 2009 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 C49623A692D for ; Tue, 14 Apr 2009 00:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.349 X-Spam-Level: X-Spam-Status: No, score=-8.349 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] 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 TjMhobJECv8J for ; Tue, 14 Apr 2009 00:53:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 546493A68AC for ; Tue, 14 Apr 2009 00:53:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,183,1238976000"; d="scan'208";a="38196132" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2009 07:54:47 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3E7skpL022433; Tue, 14 Apr 2009 09:54:46 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3E7skJH023595; Tue, 14 Apr 2009 07:54:46 GMT Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n3E7skC11226; Tue, 14 Apr 2009 08:54:46 +0100 (BST) Message-ID: <49E44145.7090802@cisco.com> Date: Tue, 14 Apr 2009 08:54:45 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: liu.guoman@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2612; t=1239695686; x=1240559686; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20draft-bryant-filsfils-fat-pw-0 3=20to=20WG=20draft? |Sender:=20; bh=URxy2mrUGeBZ1z5mhOMxrBXYD9aNO80v6XMkRd6vTBc=; b=ukd0NL+JW+DX5BjUrhg/pjRvOktQ13UDyDpCwBGpTVC6sEDoUYP+zuDdUU IUgliJ+y/B6nEovpSCRBDQAPnw7u470WS1qI3cmR1oC5dPH7xit4LGPojj2z CGAFcCeTuz; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? 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: Tue, 14 Apr 2009 07:53:46 -0000 liu.guoman@zte.com.cn wrote: > > Stewart: > I understand your meaning , but I think it unnecessary to use and > apply another flow label. we may add 2 bytes flow ID in services header, What do you mean by the services header? > so at sink point, it identify and re-encapsulate the services context > by flow id and SN in services header. > do you think so. Please can you sketch out your label stack and describe the operations you have in mind? Thanks Stewart > regards > liu > > > *Stewart Bryant * > > 2009-04-02 19:24 > Çë´ð¸´ ¸ø > stbryant@cisco.com > > > > ÊÕ¼þÈË > liu.guoman@zte.com.cn > ³­ËÍ > pwe3@ietf.org > Ö÷Ìâ > Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? > > > > > > > > > > liu.guoman@zte.com.cn wrote: > > > > Stewart: > > my problem is : if there is a multimedia data flow, the flow must be > > transported in order. or else it will not become a multimedia flow. > > how to process the data flow by ECMP? > > IMO, there are two solutions: > > 1 at sink points, there are enough buffers to store the data flow. > > 2 during transporting the data flow, it must transport in order. > > > > do you think so? > > regards > > liu > > > Yes > > Remember this draft is simply a tool that is used to spread out already > identified flows over the ECMP set. > > The processing into and out of a fat pw is outside it's scope. > > Clearly you can enable s/n - apply the LB label - and put the flow back > together at the egress if that suits you application otherwise as you > say you have to have large enough end to end b/w. > > Remember what it says in the PWE3 charter - if the best effort emulation > provided by PWE3 is not good enough, then either propose a better > emulation, or use a real wire. > > Stewart > > > > > -------------------------------------------------------- > 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. > From liu.guoman@zte.com.cn Tue Apr 14 02:20:56 2009 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 D01163A6AF8; Tue, 14 Apr 2009 02:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.335 X-Spam-Level: X-Spam-Status: No, score=-96.335 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 8QGhkas5yVhV; Tue, 14 Apr 2009 02:20:55 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id B2EDB3A6D0F; Tue, 14 Apr 2009 02:20:44 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111642967892178; Tue, 14 Apr 2009 17:12:16 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 47274.4742420231; Tue, 14 Apr 2009 17:18:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n3E9LTnN058098; Tue, 14 Apr 2009 17:21:29 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <49E44145.7090802@cisco.com> To: stbryant@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Tue, 14 Apr 2009 17:19:15 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-14 17:21:22, Serialize complete at 2009-04-14 17:21:22 Content-Type: multipart/alternative; boundary="=_alternative 0033635E48257598_=" X-MAIL: mse1.zte.com.cn n3E9LTnN058098 Cc: mpls@ietf.org, pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? 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, 14 Apr 2009 09:20:56 -0000 This is a multipart message in MIME format. --=_alternative 0033635E48257598_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 c3Rld2FydDoNCiAgaXQgaXMgbm90IGNsZWFyIGV4cHJlc3Npb24gaGVyZSB0byB1c2Ugc2Vydmlj ZSBoZWFkZXIgLiBJTU8sIGFkZGluZyBmbG93IA0KSUQgZm9sbG93aW5nIENXIGZpZWxkIHRvIGlk ZW50aWZ5IHdoaWNoIGZsb3cgdGhlIHNlcnZpY2UgZGF0YSB3aWxsIGJlbG9uZyANCnRvPyB0aGVu IHRoZSBzZXJ2aWNlIGRhdGEgbWF5IGJlIGNhcnJpZWQgYnkgRUNNUCB0byBhbm90aGVyIHNpbmsg cG9pbnRzLCANCnRoZSBzaW5rIHBvaW50cyB3aWxsIGlkZW50aWZ5IHRoZSBzZXJ2aWNlIGRhdGEg YnkgZmxvdyBJRCAuIGFuZCB0aGUgcGFja2V0IA0KZm9ybWF0cyB3aWxsIHRoZSBmb2xsb3dpbmc6 DQogDQogICAgICAgICAgTFNQIExhYmVsDQogICAgICAgICAgUFcgTGFiZWwNCiAgICAgICAgICAg Q1cgDQogICAgICAgICAgRmxvdyBJRCANCiAgICAgICAgICBTZXJ2aWNlIGRhdGEgDQoNCiAgIGlu IGFkZHRpb25zLiBpZiB1c2luZyBhIGZsb3cgbGFiZWwsIEkgdGhpbmsgdGhlIGRyYWZ0IHdpbGwg YmUgTVBMUyBvciANCk1QTFMtVFAgZHJhZnQgYW5kIHNob3VsZG4ndCBiZSBkaXNzY3Vzc2VkIGlu IHB3ZTMgd29yayBncm91cC4gDQp0aGFuayB5b3UuDQpsaXUNCg0KDQoNClN0ZXdhcnQgQnJ5YW50 IDxzdGJyeWFudEBjaXNjby5jb20+IA0KMjAwOS0wNC0xNCAxNTo1NA0Kx+u08Li0ILj4DQpzdGJy eWFudEBjaXNjby5jb20NCg0KDQrK1bz+yMsNCmxpdS5ndW9tYW5AenRlLmNvbS5jbg0Ks63LzQ0K cHdlM0BpZXRmLm9yZw0K1vfM4g0KUmU6IFtQV0UzXSBkcmFmdC1icnlhbnQtZmlsc2ZpbHMtZmF0 LXB3LTAzIHRvIFdHIGRyYWZ0Pw0KDQoNCg0KDQoNCg0KbGl1Lmd1b21hbkB6dGUuY29tLmNuIHdy b3RlOg0KPg0KPiBTdGV3YXJ0Og0KPiBJIHVuZGVyc3RhbmQgeW91ciBtZWFuaW5nICwgYnV0IEkg dGhpbmsgaXQgdW5uZWNlc3NhcnkgdG8gdXNlIGFuZA0KPiBhcHBseSBhbm90aGVyIGZsb3cgbGFi ZWwuIHdlIG1heSBhZGQgMiBieXRlcyBmbG93IElEIGluIHNlcnZpY2VzIGhlYWRlciwNCg0KV2hh dCBkbyB5b3UgbWVhbiBieSB0aGUgc2VydmljZXMgaGVhZGVyPw0KDQo+IHNvIGF0IHNpbmsgcG9p bnQsIGl0IGlkZW50aWZ5IGFuZCByZS1lbmNhcHN1bGF0ZSB0aGUgc2VydmljZXMgY29udGV4dA0K PiBieSBmbG93IGlkIGFuZCBTTiBpbiBzZXJ2aWNlcyBoZWFkZXIuDQo+IGRvIHlvdSB0aGluayBz by4NCg0KUGxlYXNlIGNhbiB5b3Ugc2tldGNoIG91dCB5b3VyIGxhYmVsIHN0YWNrIGFuZCBkZXNj cmliZSB0aGUgb3BlcmF0aW9ucw0KeW91IGhhdmUgaW4gbWluZD8NCg0KVGhhbmtzDQoNClN0ZXdh cnQNCj4gcmVnYXJkcw0KPiBsaXUNCj4NCj4NCj4gKlN0ZXdhcnQgQnJ5YW50IDxzdGJyeWFudEBj aXNjby5jb20+Kg0KPg0KPiAyMDA5LTA0LTAyIDE5OjI0DQo+IMfrtPC4tCC4+A0KPiBzdGJyeWFu dEBjaXNjby5jb20NCj4NCj4NCj4gDQo+IMrVvP7Iyw0KPiAgICAgICAgICAgICAgICBsaXUuZ3Vv bWFuQHp0ZS5jb20uY24NCj4gs63LzQ0KPiAgICAgICAgICAgICAgICBwd2UzQGlldGYub3JnDQo+ INb3zOINCj4gICAgICAgICAgICAgICAgUmU6IFtQV0UzXSBkcmFmdC1icnlhbnQtZmlsc2ZpbHMt ZmF0LXB3LTAzIHRvIFdHIGRyYWZ0Pw0KPg0KPg0KPg0KPiANCj4NCj4NCj4NCj4NCj4NCj4gbGl1 Lmd1b21hbkB6dGUuY29tLmNuIHdyb3RlOg0KPiA+DQo+ID4gU3Rld2FydDoNCj4gPiBteSBwcm9i bGVtIGlzIDogaWYgdGhlcmUgaXMgYSBtdWx0aW1lZGlhIGRhdGEgZmxvdywgdGhlIGZsb3cgbXVz dCBiZQ0KPiA+IHRyYW5zcG9ydGVkIGluIG9yZGVyLiBvciBlbHNlIGl0IHdpbGwgbm90IGJlY29t ZSBhIG11bHRpbWVkaWEgZmxvdy4NCj4gPiBob3cgdG8gcHJvY2VzcyB0aGUgZGF0YSBmbG93IGJ5 IEVDTVA/DQo+ID4gSU1PLCB0aGVyZSBhcmUgdHdvIHNvbHV0aW9uczoNCj4gPiAxIGF0IHNpbmsg cG9pbnRzLCB0aGVyZSBhcmUgZW5vdWdoIGJ1ZmZlcnMgdG8gc3RvcmUgdGhlIGRhdGEgZmxvdy4N Cj4gPiAyIGR1cmluZyB0cmFuc3BvcnRpbmcgdGhlIGRhdGEgZmxvdywgaXQgbXVzdCB0cmFuc3Bv cnQgaW4gb3JkZXIuDQo+ID4NCj4gPiBkbyB5b3UgdGhpbmsgc28/DQo+ID4gcmVnYXJkcw0KPiA+ IGxpdQ0KPiA+DQo+IFllcw0KPg0KPiBSZW1lbWJlciB0aGlzIGRyYWZ0IGlzIHNpbXBseSBhIHRv b2wgdGhhdCBpcyB1c2VkIHRvIHNwcmVhZCBvdXQgYWxyZWFkeQ0KPiBpZGVudGlmaWVkIGZsb3dz IG92ZXIgdGhlIEVDTVAgc2V0Lg0KPg0KPiBUaGUgcHJvY2Vzc2luZyBpbnRvIGFuZCBvdXQgb2Yg YSBmYXQgcHcgaXMgb3V0c2lkZSBpdCdzIHNjb3BlLg0KPg0KPiBDbGVhcmx5IHlvdSBjYW4gZW5h YmxlIHMvbiAtIGFwcGx5IHRoZSBMQiBsYWJlbCAtIGFuZCBwdXQgdGhlIGZsb3cgYmFjaw0KPiB0 b2dldGhlciBhdCB0aGUgZWdyZXNzIGlmIHRoYXQgc3VpdHMgeW91IGFwcGxpY2F0aW9uIG90aGVy d2lzZSBhcyB5b3UNCj4gc2F5IHlvdSBoYXZlIHRvIGhhdmUgbGFyZ2UgZW5vdWdoIGVuZCB0byBl bmQgYi93Lg0KPg0KPiBSZW1lbWJlciB3aGF0IGl0IHNheXMgaW4gdGhlIFBXRTMgY2hhcnRlciAt IGlmIHRoZSBiZXN0IGVmZm9ydCBlbXVsYXRpb24NCj4gcHJvdmlkZWQgYnkgUFdFMyBpcyBub3Qg Z29vZCBlbm91Z2gsIHRoZW4gZWl0aGVyIHByb3Bvc2UgYSBiZXR0ZXINCj4gZW11bGF0aW9uLCBv ciB1c2UgYSByZWFsIHdpcmUuDQo+DQo+IFN0ZXdhcnQNCj4NCj4NCj4NCj4NCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgDQppcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlv bi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gDQppcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMg bmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IA0KYW5kIGFyZSBu b3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRp b24gdG8gDQpvdGhlcnMuDQo+IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3 aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIA0KaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIA0KYWRkcmVzc2Vk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg dGhlIA0Kb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0 aGlzIG1lc3NhZ2UgYXJlIHRob3NlIA0Kb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KPiBUaGlz IG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50 aS1TcGFtIA0Kc3lzdGVtLg0KPiANCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5 IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5 IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5p Y2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdh dGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3Nl IHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFp bCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQg aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0 byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBB bnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2 aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMg YW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0033635E48257598_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnN0ZXdhcnQ6PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgaXQgaXMgbm90IGNsZWFyIGV4 cHJlc3Npb24gaGVyZQ0KdG8gdXNlIHNlcnZpY2UgaGVhZGVyIC4gSU1PLCBhZGRpbmcgZmxvdyBJ RCBmb2xsb3dpbmcgQ1cgZmllbGQgdG8gaWRlbnRpZnkNCndoaWNoIGZsb3cgdGhlIHNlcnZpY2Ug ZGF0YSB3aWxsIGJlbG9uZyB0bz8gdGhlbiB0aGUgc2VydmljZSBkYXRhIG1heSBiZQ0KY2Fycmll ZCBieSBFQ01QIHRvIGFub3RoZXIgc2luayBwb2ludHMsIHRoZSBzaW5rIHBvaW50cyB3aWxsIGlk ZW50aWZ5IHRoZQ0Kc2VydmljZSBkYXRhIGJ5IGZsb3cgSUQgLiBhbmQgdGhlIHBhY2tldCBmb3Jt YXRzIHdpbGwgdGhlIGZvbGxvd2luZzo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9u dD4NCjx0YWJsZSBib3JkZXI+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXY+PGZvbnQgc2l6 ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KTFNQIExhYmVsPC9mb250PjwvZGl2Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 Pjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNClBXIExhYmVsPC9mb250PjwvZGl2Pg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2Pjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO0NXIDwvZm9udD48L2Rpdj4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdj48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpGbG93IElEICZuYnNwOyAmbmJzcDs8 L2ZvbnQ+PC9kaXY+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXY+PGZvbnQgc2l6ZT0yIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K U2VydmljZSBkYXRhIDwvZm9udD48L2Rpdj48L3RhYmxlPg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7aW4gYWRkdGlvbnMuIGlmIHVzaW5nIGEN CmZsb3cgbGFiZWwsIEkgdGhpbmsgdGhlIGRyYWZ0IHdpbGwgYmUgTVBMUyBvciBNUExTLVRQIGRy YWZ0IGFuZCBzaG91bGRuJ3QNCmJlIGRpc3NjdXNzZWQgaW4gcHdlMyB3b3JrIGdyb3VwLiA8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRoYW5rIHlvdS48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmxpdTwvZm9udD4NCjxicj4NCjxi cj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9 MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5TdGV3YXJ0IEJyeWFudCAmbHQ7 c3RicnlhbnRAY2lzY28uY29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4yMDA5LTA0LTE0IDE1OjU0PC9mb250Pg0KPHRhYmxlIGJvcmRlcj4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIGJnY29sb3I9d2hpdGU+DQo8ZGl2IGFsaWduPWNlbnRlcj48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+x+u08Li0ILj4PGJyPg0Kc3RicnlhbnRAY2lzY28u Y29tPC9mb250PjwvZGl2PjwvdGFibGU+DQo8YnI+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdp ZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+bGl1Lmd1b21hbkB6dGUuY29tLmNuPC9mb250Pg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj5wd2UzQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW1BXRTNdIGRyYWZ0 LWJyeWFudC1maWxzZmlscy1mYXQtcHctMDMNCnRvIFdHIGRyYWZ0PzwvZm9udD48L3RhYmxlPg0K PGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48 L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+bGl1Lmd1b21hbkB6dGUu Y29tLmNuIHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IFN0ZXdhcnQ6PGJyPg0KJmd0OyBJIHVu ZGVyc3RhbmQgeW91ciBtZWFuaW5nICwgYnV0IEkgdGhpbmsgaXQgdW5uZWNlc3NhcnkgdG8gdXNl IGFuZDxicj4NCiZndDsgYXBwbHkgYW5vdGhlciBmbG93IGxhYmVsLiB3ZSBtYXkgYWRkIDIgYnl0 ZXMgZmxvdyBJRCBpbiBzZXJ2aWNlcyBoZWFkZXIsPGJyPg0KPGJyPg0KV2hhdCBkbyB5b3UgbWVh biBieSB0aGUgc2VydmljZXMgaGVhZGVyPzxicj4NCjxicj4NCiZndDsgc28gYXQgc2luayBwb2lu dCwgaXQgaWRlbnRpZnkgYW5kIHJlLWVuY2Fwc3VsYXRlIHRoZSBzZXJ2aWNlcyBjb250ZXh0PGJy Pg0KJmd0OyBieSBmbG93IGlkIGFuZCBTTiBpbiBzZXJ2aWNlcyBoZWFkZXIuPGJyPg0KJmd0OyBk byB5b3UgdGhpbmsgc28uPGJyPg0KPGJyPg0KUGxlYXNlIGNhbiB5b3Ugc2tldGNoIG91dCB5b3Vy IGxhYmVsIHN0YWNrIGFuZCBkZXNjcmliZSB0aGUgb3BlcmF0aW9uczxicj4NCnlvdSBoYXZlIGlu IG1pbmQ/PGJyPg0KPGJyPg0KVGhhbmtzPGJyPg0KPGJyPg0KU3Rld2FydDxicj4NCiZndDsgcmVn YXJkczxicj4NCiZndDsgbGl1PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICpTdGV3YXJ0 IEJyeWFudCAmbHQ7c3RicnlhbnRAY2lzY28uY29tJmd0Oyo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAy MDA5LTA0LTAyIDE5OjI0PGJyPg0KJmd0OyDH67TwuLQguPg8YnI+DQomZ3Q7IHN0YnJ5YW50QGNp c2NvLmNvbTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgytW8 /sjLPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2xpdS5ndW9tYW5AenRlLmNvbS5jbjxicj4NCiZndDsgs63LzTxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtwd2UzQGlldGYub3JnPGJyPg0KJmd0OyDW98ziPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O1JlOg0KW1BXRTNdIGRyYWZ0LWJyeWFudC1maWxzZmlscy1mYXQtcHctMDMgdG8gV0cgZHJhZnQ/ PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBsaXUuZ3Vv bWFuQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFN0ZXdh cnQ6PGJyPg0KJmd0OyAmZ3Q7IG15IHByb2JsZW0gaXMgOiBpZiB0aGVyZSBpcyBhIG11bHRpbWVk aWEgZGF0YSBmbG93LCB0aGUgZmxvdw0KbXVzdCBiZTxicj4NCiZndDsgJmd0OyB0cmFuc3BvcnRl ZCBpbiBvcmRlci4gb3IgZWxzZSBpdCB3aWxsIG5vdCBiZWNvbWUgYSBtdWx0aW1lZGlhDQpmbG93 Ljxicj4NCiZndDsgJmd0OyBob3cgdG8gcHJvY2VzcyB0aGUgZGF0YSBmbG93IGJ5IEVDTVA/PGJy Pg0KJmd0OyAmZ3Q7IElNTywgdGhlcmUgYXJlIHR3byBzb2x1dGlvbnM6PGJyPg0KJmd0OyAmZ3Q7 IDEgYXQgc2luayBwb2ludHMsIHRoZXJlIGFyZSBlbm91Z2ggYnVmZmVycyB0byBzdG9yZSB0aGUg ZGF0YQ0KZmxvdy48YnI+DQomZ3Q7ICZndDsgMiBkdXJpbmcgdHJhbnNwb3J0aW5nIHRoZSBkYXRh IGZsb3csIGl0IG11c3QgdHJhbnNwb3J0IGluIG9yZGVyLjxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBkbyB5b3UgdGhpbmsgc28/PGJyPg0KJmd0OyAmZ3Q7IHJlZ2FyZHM8YnI+DQomZ3Q7 ICZndDsgbGl1PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyBZZXM8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBSZW1lbWJlciB0aGlzIGRyYWZ0IGlzIHNpbXBseSBhIHRvb2wgdGhhdCBpcyB1c2VkIHRvIHNw cmVhZCBvdXQgYWxyZWFkeTxicj4NCiZndDsgaWRlbnRpZmllZCBmbG93cyBvdmVyIHRoZSBFQ01Q IHNldC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgcHJvY2Vzc2luZyBpbnRvIGFuZCBvdXQgb2Yg YSBmYXQgcHcgaXMgb3V0c2lkZSBpdCdzIHNjb3BlLjxicj4NCiZndDs8YnI+DQomZ3Q7IENsZWFy bHkgeW91IGNhbiBlbmFibGUgcy9uIC0gYXBwbHkgdGhlIExCIGxhYmVsIC0gYW5kIHB1dCB0aGUg Zmxvdw0KYmFjazxicj4NCiZndDsgdG9nZXRoZXIgYXQgdGhlIGVncmVzcyBpZiB0aGF0IHN1aXRz IHlvdSBhcHBsaWNhdGlvbiBvdGhlcndpc2UgYXMNCnlvdTxicj4NCiZndDsgc2F5IHlvdSBoYXZl IHRvIGhhdmUgbGFyZ2UgZW5vdWdoIGVuZCB0byBlbmQgYi93Ljxicj4NCiZndDs8YnI+DQomZ3Q7 IFJlbWVtYmVyIHdoYXQgaXQgc2F5cyBpbiB0aGUgUFdFMyBjaGFydGVyIC0gaWYgdGhlIGJlc3Qg ZWZmb3J0IGVtdWxhdGlvbjxicj4NCiZndDsgcHJvdmlkZWQgYnkgUFdFMyBpcyBub3QgZ29vZCBl bm91Z2gsIHRoZW4gZWl0aGVyIHByb3Bvc2UgYSBiZXR0ZXI8YnI+DQomZ3Q7IGVtdWxhdGlvbiwg b3IgdXNlIGEgcmVhbCB3aXJlLjxicj4NCiZndDs8YnI+DQomZ3Q7IFN0ZXdhcnQ8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzDQptYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9u LiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbg0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5h bWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3Qg cGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24g dG8NCm90aGVycy48YnI+DQomZ3Q7IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRl ZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kDQppbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUNCmFkZHJlc3Nl ZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5 IHRoZSBvcmlnaW5hdG9yDQpvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0 aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsDQpzZW5kZXIuPGJyPg0KJmd0 OyBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBa VEUgQW50aS1TcGFtDQpzeXN0ZW0uPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KPGJyPg0KPC90dD48 L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3Vy aXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVk Jm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJv cGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZu YnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlk ZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5i c3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQm bmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5i c3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9u Jm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkm bmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5i c3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtm b3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJz cDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJz cDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJz cDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90 aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2Fn ZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZu YnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5k aXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVl biZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZu YnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0033635E48257598_=-- From stbryant@cisco.com Tue Apr 14 04:16:59 2009 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 F21F43A6893; Tue, 14 Apr 2009 04:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.374 X-Spam-Level: X-Spam-Status: No, score=-8.374 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] 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 5Iz7t5okGflx; Tue, 14 Apr 2009 04:16:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5C7F13A67D7; Tue, 14 Apr 2009 04:16:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,184,1238976000"; d="scan'208";a="38234524" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2009 11:18:04 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3EBI4tZ009740; Tue, 14 Apr 2009 13:18:04 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3EBI4M2024155; Tue, 14 Apr 2009 11:18:04 GMT Received: from dhcp-gpk02-vlan300-64-103-65-25.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n3EBI3C25182; Tue, 14 Apr 2009 12:18:04 +0100 (BST) Message-ID: <49E470EB.7030401@cisco.com> Date: Tue, 14 Apr 2009 12:18:03 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: liu.guoman@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4978; t=1239707884; x=1240571884; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20draft-bryant-filsfils-fat-pw-0 3=20to=20WG=20draft? |Sender:=20; bh=j1+bRLQxhOPMjUAFYII/ZPmvFS3ycU+BhblHbykDlzQ=; b=rsmvEJ0h7k7rHqH483vZ/WI7Wp8BWPZjI+1S8ykscFEFMvQQVHIcezq+1R 7LZUBSamOwRQg4a+7sLK+/DMDRy9syuwdlPetd9h6iUuMQSyhxOHi9Woo8Lu NI3F3T7wPs; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: mpls@ietf.org, pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? 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: Tue, 14 Apr 2009 11:16:59 -0000 Liu You cannot use information in the payload (i.e. after BoS) to load balance, because in MPLS the payload is opaque. liu.guoman@zte.com.cn wrote: > > stewart: > it is not clear expression here to use service header . IMO, adding > flow ID following CW field to identify which flow the service data > will belong to? then the service data may be carried by ECMP to > another sink points, the sink points will identify the service data by > flow ID . and the packet formats will the following: > LSP Label > PW Label > CW > Flow ID > Service data > > > > in addtions. if using a flow label, I think the draft will be MPLS or > MPLS-TP draft and shouldn't be disscussed in pwe3 work group. > thank you. > liu > This is a PWE3 problem because: 1) PWE3 needs a method of addressing the ECMP case 2) PWE3 will signal this in a different way from MPLS 3) MPLS-TP does not have ECMP. Stewart > > *Stewart Bryant * > > 2009-04-14 15:54 > Çë´ð¸´ ¸ø > stbryant@cisco.com > > > > ÊÕ¼þÈË > liu.guoman@zte.com.cn > ³­ËÍ > pwe3@ietf.org > Ö÷Ìâ > Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? > > > > > > > > > > liu.guoman@zte.com.cn wrote: > > > > Stewart: > > I understand your meaning , but I think it unnecessary to use and > > apply another flow label. we may add 2 bytes flow ID in services header, > > What do you mean by the services header? > > > so at sink point, it identify and re-encapsulate the services context > > by flow id and SN in services header. > > do you think so. > > Please can you sketch out your label stack and describe the operations > you have in mind? > > Thanks > > Stewart > > regards > > liu > > > > > > *Stewart Bryant * > > > > 2009-04-02 19:24 > > Çë´ð¸´ ¸ø > > stbryant@cisco.com > > > > > > > > ÊÕ¼þÈË > > liu.guoman@zte.com.cn > > ³­ËÍ > > pwe3@ietf.org > > Ö÷Ìâ > > Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft? > > > > > > > > > > > > > > > > > > > > liu.guoman@zte.com.cn wrote: > > > > > > Stewart: > > > my problem is : if there is a multimedia data flow, the flow must be > > > transported in order. or else it will not become a multimedia flow. > > > how to process the data flow by ECMP? > > > IMO, there are two solutions: > > > 1 at sink points, there are enough buffers to store the data flow. > > > 2 during transporting the data flow, it must transport in order. > > > > > > do you think so? > > > regards > > > liu > > > > > Yes > > > > Remember this draft is simply a tool that is used to spread out already > > identified flows over the ECMP set. > > > > The processing into and out of a fat pw is outside it's scope. > > > > Clearly you can enable s/n - apply the LB label - and put the flow back > > together at the egress if that suits you application otherwise as you > > say you have to have large enough end to end b/w. > > > > Remember what it says in the PWE3 charter - if the best effort emulation > > provided by PWE3 is not good enough, then either propose a better > > emulation, or use a real wire. > > > > Stewart > > > > > > > > > > -------------------------------------------------------- > > 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. > > > > > > -------------------------------------------------------- > 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. > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From riccardo.martinotti@ericsson.com Tue Apr 14 09:46:59 2009 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 8D71D28C19E for ; Tue, 14 Apr 2009 09:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.585 X-Spam-Level: X-Spam-Status: No, score=-5.585 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 sTwGpPfzyiEI for ; Tue, 14 Apr 2009 09:46:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BF9D428C0E1 for ; Tue, 14 Apr 2009 09:46:53 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0317A20BA5; Tue, 14 Apr 2009 18:48:04 +0200 (CEST) X-AuditID: c1b4fb3c-ab7ccbb00000238f-83-49e4be4339bb Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C395B20B60; Tue, 14 Apr 2009 18:48:03 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 18:48:03 +0200 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_01C9BD20.C71F9AED" Date: Tue, 14 Apr 2009 18:51:15 +0200 Message-ID: <269AE8908A44C145A4745C3ED880B9A77370A9@esealmw110.eemea.ericsson.se> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] draft-bryant-pwe3-packet-pw-00.txt to WG draft? Thread-Index: Acmx+FcP5L7TrJafSfatI2vSUDObcALHv9rA References: <0458D2EE0C36744BABB36BE37805C29A0392FF7D@FRVELSMBS11.ad2.ad.alcatel.com> From: "Riccardo Martinotti" To: "BOCCI Matthew" , X-OriginalArrivalTime: 14 Apr 2009 16:48:03.0468 (UTC) FILETIME=[C7284CC0:01C9BD20] X-Brightmail-Tracker: AAAAAA== Subject: Re: [PWE3] [mpls-tp] draft-bryant-pwe3-packet-pw-00.txt to WG draft? 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, 14 Apr 2009 16:46:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BD20.C71F9AED Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Support, =20 however, following also my previous email on this subject, I would like = IETF during working group drafting could better specify the interworking = function on the virtual physical termination. I think that it's also important to address Lucy's third point. =20 Regards, Riccardo=20 =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of BOCCI Matthew Sent: marted=EC 31 marzo 2009 14.01 To: pwe3@ietf.org Cc: mpls-tp@ietf.org Subject: [mpls-tp] draft-bryant-pwe3-packet-pw-00.txt to WG draft? =20 This is the start of a two week poll to judge the consensus to move = draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group draft. Please can you respond, *to the PWE3 list only*, with your approval (or = otherwise).=20 This poll will close on 14th April 2009.=20 Regards=20 Matthew=20 =20 ------_=_NextPart_001_01C9BD20.C71F9AED Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-bryant-pwe3-packet-pw-00.txt to WG draft?

Support,

 

however, = following also my previous email on this subject, I would like IETF during working group = drafting could better specify the interworking function on the virtual physical termination.

I think that = it’s also important to address Lucy’s third = point.

 =

Regards,

Riccardo =

 =


From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of BOCCI Matthew
Sent: marted=EC 31 marzo = 2009 14.01
To: pwe3@ietf.org
Cc: mpls-tp@ietf.org
Subject: [mpls-tp] = draft-bryant-pwe3-packet-pw-00.txt to WG draft?

 

This is the start of a two week poll to judge the consensus to move draft-bryant-pwe3-packet-pw-00.txt to a PWE3 Working Group = draft.

Please can you respond, *to the PWE3 list only*, with your approval (or = otherwise).

This poll will close on 14th April 2009.

Regards

Matthew

 

------_=_NextPart_001_01C9BD20.C71F9AED-- From lucyyong@huawei.com Tue Apr 14 15:58:02 2009 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 31F1D3A6AF6 for ; Tue, 14 Apr 2009 15:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.521, 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 hB+CvkrWFhHU for ; Tue, 14 Apr 2009 15:58:01 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 18F8C3A6A29 for ; Tue, 14 Apr 2009 15:58:01 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI4004G356MF6@usaga02-in.huawei.com> for pwe3@ietf.org; Tue, 14 Apr 2009 15:59:11 -0700 (PDT) Received: from Y73674 ([10.124.12.103]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI400IJW3HSGJ@usaga02-in.huawei.com> for pwe3@ietf.org; Tue, 14 Apr 2009 15:22:41 -0700 (PDT) Date: Tue, 14 Apr 2009 17:22:40 -0500 From: Lucy Yong In-reply-to: <49E44075.8000808@cisco.com> To: stbryant@cisco.com Message-id: <005f01c9bd4f$863adb40$670c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acm81c/4wAfG4eVJRWGnfJZDPexB3QAdgGSw References: <008701c9b87e$dd04f710$670c7c0a@china.huawei.com> <49E44075.8000808@cisco.com> Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? 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, 14 Apr 2009 22:58:02 -0000 Hi Stewart, If link hello protocol can't be turned off, then the following statement in the section 4 does not apply. LSR has to use link state routing protocol to decide if the interface is up or down. I suggest revising the section 4 and adding your description (below) in. 4. Status Indication A pseudowire status indicating a fault can be considered equivalent to interface down and SHOULD be passed across the virtual interface to the local LSR. This improves scaling in PE with large numbers of c-resident LSRs and with LSRs that have large numbers of interfaces mapped to pseudowires. We should also mention in the draft that since client LSR runs its own link state protocols to its peers, there is no need to use PW status message to carry LSR local link state fault to Packet-PW remote. Regards, Lucy > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Tuesday, April 14, 2009 2:51 AM > To: Lucy Yong > Cc: 'Andrew G. Malis'; jiang.xiaowei@zte.com.cn; pwe3@ietf.org > Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? > > Lucy > > Turning off bits of the routing protocol is actually quite hard, risks > breaking the protocol and requires us to track and reflect those changes > in the surrogate protocol. We would therefore want to run the link state > routing protocol unmodified including the hellos. > > Stewart > > > Lucy Yong wrote: > > > > Hi Andy and XiaoWei, > > > > > > > > Since the purpose of packet-PW is to create a virtual physical > > interface for two connected client LSRs and allow multiple client > > protocols run over it. Assume the client LSP is IP router, it runs > > OSPF or IS-IS. To support the routing protocol properly running, IP > > interface is configured over a packet-PW. Hello protocol is normally > > activated over IP interface. However, if we want to use packet-PW > > state as IP interface state, we need to turn off hello protocol. Is > > that right? That is my second point in previous e-mail. > > > > > > > > Thanks, > > > > Lucy > > > > > > > > ------------------------------------------------------------------------ > > > > *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On > > Behalf Of *Andrew G. Malis > > *Sent:* Wednesday, April 08, 2009 8:42 AM > > *To:* jiang.xiaowei@zte.com.cn > > *Cc:* pwe3@ietf.org; stbryant@cisco.com > > *Subject:* Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? > > > > > > > > Jiang, > > > > > > > > I don't think so, but we should look more closely at the details on > > mapping between the virtual interface state and PW status reporting > > (without being implementation-dependent) to make sure we've got the > > all of the details covered. Lucy's point 3 is a good one as well. > > > > > > > > Thanks, > > > > Andy > > > > > > > > On Wed, Apr 8, 2009 at 7:46 AM, > > wrote: > > > > > > Andy, > > > > Is there any need for Packet-PW to maintain any kind of state machine > > for virtual interface status like Lucy Yong mentioned? > > > > Thanks, > > Albert > > > > > > > > *Lucy Yong >* > > sender: pwe3-bounces@ietf.org > > > > 2009-04-01 01:13 > > > > > > > > to > > > > > > > > 'Stewart Bryant' >, > > pwe3@ietf.org , "'Malis, Andrew G. (Andy)'" > > > > > > > cc > > > > > > > > > > > > topic > > > > > > > > [PWE3] comments on packet pw > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Stewart and Andy, > > > > I support this draft to become WG draft. Congratulation!! > > I also have some comments on the draft: > > > > 1) Since Packet PW requires using CW, it is necessary to state how > > to use flow label and S/N for packet PW. > > 2) It is good to have the PW status mapped to virtual interfaces. > > However, *each protocol interface may have its own link status > > protocol* running, the draft should state the procedures to determine > > interface status, or require each protocol interface to turn off its > > link protocol when using Packet PW > > 3) Since Packet PW acts as a data link between two clients LSRs, > > the draft should state link operational procedures (for client > > networks) over a packet PW such as how to determine admin cost, TE > > metrics, etc. > > 4) I assume that a Packet PW can obtain transport resiliency from > > server MPLS network, it would be nice for the draft to state them and > > considers that the consequence may change admin cost in client networks. > > > > Cheers, > > Lucy_______________________________________________ > > > > > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > *"Andrew G. Malis" >* > > > > 2009-04-04 23:39 > > > > > > > > > > > > > > > > jiang.xiaowei@zte.com.cn > > > > > > > > > > > > stbryant@cisco.com , pwe3@ietf.org > > > > > > > > > > > > > > Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? > > > > > > > > > > > > > > > > > > > > > > > > > > Jiang, > > > > Yes it could, but in addition to higher overhead it would also require > > running the PPP state machine and using PPP options. We wanted to keep > > this as simple as possible. > > > > Thanks, > > Andy > > > > 2009/4/3 >: > > > > > > Sir, > > > > > > Could rfc4618 Encapsulation Methods for Transport of PPP/High-Level Data > > > Link Control (HDLC) over MPLS Networks > > > be used as a solution for the scenario in this draft? (although have more > > > encapsulation overhead) > > > > > > Thank you! > > > > > > From hshah@ciena.com Tue Apr 14 18:56:34 2009 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 686503A699D for ; Tue, 14 Apr 2009 18:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.756, 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 cQSPh3CkwVfI for ; Tue, 14 Apr 2009 18:56:33 -0700 (PDT) Received: from ripley.ciena.com (ripley.ciena.com [63.118.34.24]) by core3.amsl.com (Postfix) with ESMTP id 6BDE83A6855 for ; Tue, 14 Apr 2009 18:56:32 -0700 (PDT) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_FF99E_01C9BD4C.0A41FA30" Date: Tue, 14 Apr 2009 21:57:43 -0400 Message-ID: <6535C9CED6F87446B41D20EF170F23623161EB@mamxm01.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? thread-index: Acm81c/4wAfG4eVJRWGnfJZDPexB3QAdgGSwAAgnuxE= Importance: normal Priority: normal References: <008701c9b87e$dd04f710$670c7c0a@china.huawei.com><49E44075.8000808@cisco.com> <005f01c9bd4f$863adb40$670c7c0a@china.huawei.com> From: "Shah, Himanshu" To: "Lucy Yong" , X-OriginalArrivalTime: 15 Apr 2009 01:57:44.0247 (UTC) FILETIME=[913BCC70:01C9BD6D] Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? 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, 15 Apr 2009 01:56:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_FF99E_01C9BD4C.0A41FA30 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BD6D.90C46882" ------_=_NextPart_001_01C9BD6D.90C46882 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Not sure where this discussion is going but... if a physical point-to-point connection is being mimicked by a 'virtual wire' (i.e. pw) with its corresponding mechanisms of up/down (i.e. pw status), etc, why should layer above (or for that matter layer below) start making exceptions?? what am I missing here??? /himanshu -----Original Message----- From: pwe3-bounces@ietf.org on behalf of Lucy Yong Sent: Tue 4/14/2009 6:22 PM To: stbryant@cisco.com Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? =20 Hi Stewart, If link hello protocol can't be turned off, then the following statement = in the section 4 does not apply. LSR has to use link state routing protocol = to decide if the interface is up or down. I suggest revising the section 4 = and adding your description (below) in.=20 4. Status Indication A pseudowire status indicating a fault can be considered equivalent to interface down and SHOULD be passed across the virtual interface to the local LSR. This improves scaling in PE with large numbers of c-resident LSRs and with LSRs that have large numbers of interfaces mapped to pseudowires. We should also mention in the draft that since client LSR runs its own = link state protocols to its peers, there is no need to use PW status message = to carry LSR local link state fault to Packet-PW remote. Regards, Lucy > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Tuesday, April 14, 2009 2:51 AM > To: Lucy Yong > Cc: 'Andrew G. Malis'; jiang.xiaowei@zte.com.cn; pwe3@ietf.org > Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? >=20 > Lucy >=20 > Turning off bits of the routing protocol is actually quite hard, risks > breaking the protocol and requires us to track and reflect those = changes > in the surrogate protocol. We would therefore want to run the link = state > routing protocol unmodified including the hellos. >=20 > Stewart >=20 >=20 > Lucy Yong wrote: > > > > Hi Andy and XiaoWei, > > > > > > > > Since the purpose of packet-PW is to create a virtual physical > > interface for two connected client LSRs and allow multiple client > > protocols run over it. Assume the client LSP is IP router, it runs > > OSPF or IS-IS. To support the routing protocol properly running, IP > > interface is configured over a packet-PW. Hello protocol is normally > > activated over IP interface. However, if we want to use packet-PW > > state as IP interface state, we need to turn off hello protocol. Is > > that right? That is my second point in previous e-mail. > > > > > > > > Thanks, > > > > Lucy > > > > > > > > = ------------------------------------------------------------------------ > > > > *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On > > Behalf Of *Andrew G. Malis > > *Sent:* Wednesday, April 08, 2009 8:42 AM > > *To:* jiang.xiaowei@zte.com.cn > > *Cc:* pwe3@ietf.org; stbryant@cisco.com > > *Subject:* Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG = draft? > > > > > > > > Jiang, > > > > > > > > I don't think so, but we should look more closely at the details on > > mapping between the virtual interface state and PW status reporting > > (without being implementation-dependent) to make sure we've got the > > all of the details covered. Lucy's point 3 is a good one as well. > > > > > > > > Thanks, > > > > Andy > > > > > > > > On Wed, Apr 8, 2009 at 7:46 AM, > > wrote: > > > > > > Andy, > > > > Is there any need for Packet-PW to maintain any kind of state = machine > > for virtual interface status like Lucy Yong mentioned? > > > > Thanks, > > Albert > > > > > > > > *Lucy Yong >* > > sender: pwe3-bounces@ietf.org > > > > 2009-04-01 01:13 > > > > > > > > to > > > > > > > > 'Stewart Bryant' >, > > pwe3@ietf.org , "'Malis, Andrew G. (Andy)'" > > > > > > > cc > > > > > > > > > > > > topic > > > > > > > > [PWE3] comments on packet pw > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Stewart and Andy, > > > > I support this draft to become WG draft. Congratulation!! > > I also have some comments on the draft: > > > > 1) Since Packet PW requires using CW, it is necessary to state = how > > to use flow label and S/N for packet PW. > > 2) It is good to have the PW status mapped to virtual = interfaces. > > However, *each protocol interface may have its own link status > > protocol* running, the draft should state the procedures to = determine > > interface status, or require each protocol interface to turn off its > > link protocol when using Packet PW > > 3) Since Packet PW acts as a data link between two clients LSRs, > > the draft should state link operational procedures (for client > > networks) over a packet PW such as how to determine admin cost, TE > > metrics, etc. > > 4) I assume that a Packet PW can obtain transport resiliency = from > > server MPLS network, it would be nice for the draft to state them = and > > considers that the consequence may change admin cost in client = networks. > > > > Cheers, > > Lucy_______________________________________________ > > > > > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > *"Andrew G. Malis" >* > > > > 2009-04-04 23:39 > > > > > > > > > > > > > > > > jiang.xiaowei@zte.com.cn > > > > > > > > > > > > stbryant@cisco.com , pwe3@ietf.org > > > > > > > > > > > > > > Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? > > > > > > > > > > > > > > > > > > > > > > > > > > Jiang, > > > > Yes it could, but in addition to higher overhead it would also = require > > running the PPP state machine and using PPP options. We wanted to = keep > > this as simple as possible. > > > > Thanks, > > Andy > > > > 2009/4/3 >: > > > > > > Sir, > > > > > > Could rfc4618 Encapsulation Methods for Transport of = PPP/High-Level Data > > > Link Control (HDLC) over MPLS Networks > > > be used as a solution for the scenario in this draft? (although = have more > > > encapsulation overhead) > > > > > > Thank you! > > > > > > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C9BD6D.90C46882 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG = draft?

Not sure where this discussion is going but...

if a physical point-to-point connection is being
mimicked by a 'virtual wire' (i.e. pw) with its
corresponding mechanisms of up/down (i.e. pw status), etc,
why should layer above (or for that matter layer below)
start making exceptions??

what am I missing here???

/himanshu




-----Original Message-----


From: pwe3-bounces@ietf.org on behalf of Lucy Yong
Sent: Tue 4/14/2009 6:22 PM
To: stbryant@cisco.com
Cc: pwe3@ietf.org
Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?

Hi Stewart,

If link hello protocol can't be turned off, then the following statement = in
the section 4 does not apply. LSR has to use link state routing protocol = to
decide if the interface is up or down. I suggest revising the section 4 = and
adding your description (below) in.

4.  Status Indication

   A pseudowire status indicating a fault can be considered = equivalent
   to interface down and SHOULD be passed across the virtual = interface
   to the local LSR.  This improves scaling in PE with = large numbers of
   c-resident LSRs and with LSRs that have large numbers of = interfaces
   mapped to pseudowires.

We should also mention in the draft that since client LSR runs its own = link
state protocols to its peers, there is no need to use PW status message = to
carry LSR local link state fault to Packet-PW remote.

Regards,
Lucy

> -----Original Message-----
> From: Stewart Bryant [mailto:stbryant@cisco.com]
> Sent: Tuesday, April 14, 2009 2:51 AM
> To: Lucy Yong
> Cc: 'Andrew G. Malis'; jiang.xiaowei@zte.com.cn; pwe3@ietf.org
> Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG = draft?
>
> Lucy
>
> Turning off bits of the routing protocol is actually quite hard, = risks
> breaking the protocol and requires us to track and reflect those = changes
> in the surrogate protocol. We would therefore want to run the link = state
> routing protocol unmodified including the hellos.
>
> Stewart
>
>
> Lucy Yong wrote:
> >
> > Hi Andy and XiaoWei,
> >
> >
> >
> > Since the purpose of packet-PW is to create a virtual = physical
> > interface for two connected client LSRs and allow multiple = client
> > protocols run over it. Assume the client LSP is IP router, it = runs
> > OSPF or IS-IS. To support the routing protocol properly = running, IP
> > interface is configured over a packet-PW. Hello protocol is = normally
> > activated over IP interface. However, if we want to use = packet-PW
> > state as IP interface state, we need to turn off hello = protocol. Is
> > that right? That is my second point in previous e-mail.
> >
> >
> >
> > Thanks,
> >
> > Lucy
> >
> >
> >
> > = ------------------------------------------------------------------------<= BR> > >
> > *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] = *On
> > Behalf Of *Andrew G. Malis
> > *Sent:* Wednesday, April 08, 2009 8:42 AM
> > *To:* jiang.xiaowei@zte.com.cn
> > *Cc:* pwe3@ietf.org; stbryant@cisco.com
> > *Subject:* Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG = draft?
> >
> >
> >
> > Jiang,
> >
> >
> >
> > I don't think so, but we should look more closely at the = details on
> > mapping between the virtual interface state and PW status = reporting
> > (without being implementation-dependent) to make sure we've = got the
> > all of the details covered. Lucy's point 3 is a good one as = well.
> >
> >
> >
> > Thanks,
> >
> > Andy
> >
> >
> >
> > On Wed, Apr 8, 2009 at 7:46 AM, = <jiang.xiaowei@zte.com.cn
> > <mailto:jiang.xiaowei@zte.com.cn<= /A>>> wrote:
> >
> >
> > Andy,
> >
> > Is there any need for Packet-PW to maintain any kind of state = machine
> > for virtual interface status like Lucy Yong mentioned?
> >
> > Thanks,
> > Albert
> >
> >
> >
> > *Lucy Yong <lucyyong@huawei.com <
mailto:lucyyong@huawei.com>>= ;*
> > sender:  pwe3-bounces@ietf.org <mailto:pwe3-bounces@ietf.org>= ;
> >
> > 2009-04-01 01:13
> >
> >
> >
> > to
> >
> >
> >
> > 'Stewart Bryant' <stbryant@cisco.com <mailto:stbryant@cisco.com>>,=
> > pwe3@ietf.org <mailto:pwe3@ietf.org>, = "'Malis, Andrew G. (Andy)'"
> > <andrew.g.malis@verizon.com <mailto:andrew.g.malis@verizon.= com>>
> >
> > cc
> >
> >
> >
> >
> >
> > topic
> >
> >
> >
> > [PWE3] comments on packet pw
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi Stewart and Andy,
> >
> > I support this draft to become WG draft. Congratulation!!
> > I also have some comments on the draft:
> >
> > 1)     Since Packet PW requires using CW, = it is necessary to state how
> > to use flow label and S/N for packet PW.
> > 2)     It is good to have the PW status = mapped to virtual interfaces.
> > However, *each protocol interface may have its own link = status
> > protocol* running, the draft should state the procedures to = determine
> > interface status, or require each protocol interface to turn = off its
> > link protocol when using Packet PW
> > 3)     Since Packet PW acts as a data link = between two clients LSRs,
> > the draft should state link operational procedures (for = client
> > networks) over a packet PW such as how to determine admin = cost, TE
> > metrics, etc.
> > 4)     I assume that a Packet PW can = obtain transport resiliency from
> > server MPLS network, it would be nice for the draft to state = them and
> > considers that the consequence may change admin cost in client = networks.
> >
> > Cheers,
> > Lucy_______________________________________________
> >
> >
> > pwe3 mailing list
> > pwe3@ietf.org <mailto:pwe3@ietf.org>
> > https://www.ietf.org/= mailman/listinfo/pwe3
> >
> >
> >
> >
> >
> > *"Andrew G. Malis" <amalis@gmail.com <mailto:amalis@gmail.com>>*
= > >
> > 2009-04-04 23:39
> >
> >
> >
> >
> >
> >
> >
> > jiang.xiaowei@zte.com.cn <mailto:jiang.xiaowei@zte.com.cn<= /A>>
> >
> >
> >
> >
> >
> > stbryant@cisco.com <
mailto:stbryant@cisco.com>, = pwe3@ietf.org
> > <mailto:pwe3@ietf.org>
> >
> >
> >
> >
> >
> > Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Jiang,
> >
> > Yes it could, but in addition to higher overhead it would also = require
> > running the PPP state machine and using PPP options. We wanted = to keep
> > this as simple as possible.
> >
> > Thanks,
> > Andy
> >
> > 2009/4/3  <jiang.xiaowei@zte.com.cn <mailto:jiang.xiaowei@zte.com.cn<= /A>>>:
> > >
> > > Sir,
> > >
> > > Could rfc4618 Encapsulation Methods for Transport of = PPP/High-Level
Data
> > > Link Control (HDLC) over MPLS Networks
> > > be used as a solution for the scenario in this draft? = (although have
more
> > > encapsulation overhead)
> > >
> > > Thank you!
> >
> >
> >

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/= mailman/listinfo/pwe3


------_=_NextPart_001_01C9BD6D.90C46882-- ------=_NextPart_000_FF99E_01C9BD4C.0A41FA30 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= ------=_NextPart_000_FF99E_01C9BD4C.0A41FA30-- From stbryant@cisco.com Wed Apr 15 03:52:40 2009 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 F40963A6917 for ; Wed, 15 Apr 2009 03:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.631 X-Spam-Level: X-Spam-Status: No, score=-9.631 tagged_above=-999 required=5 tests=[AWL=0.968, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 vrOyFbZwRH9h for ; Wed, 15 Apr 2009 03:52:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 16C193A67E7 for ; Wed, 15 Apr 2009 03:52:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,192,1238976000"; d="scan'208";a="38351306" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2009 10:53:49 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3FArnNE020009; Wed, 15 Apr 2009 12:53:49 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FArmg7029444; Wed, 15 Apr 2009 10:53:49 GMT Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n3FArle03579; Wed, 15 Apr 2009 11:53:48 +0100 (BST) Message-ID: <49E5BCBB.6060705@cisco.com> Date: Wed, 15 Apr 2009 11:53:47 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Lucy Yong References: <008701c9b87e$dd04f710$670c7c0a@china.huawei.com> <49E44075.8000808@cisco.com> <005f01c9bd4f$863adb40$670c7c0a@china.huawei.com> In-Reply-To: <005f01c9bd4f$863adb40$670c7c0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6978; t=1239792829; x=1240656829; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20draft-bryant-pwe3-packet-pw-00 .txt=20to=20WG=20draft? |Sender:=20; bh=53+g1yy42zqA9EXRnuiyv81+qBolYGlzkrHzXTJUa3Q=; b=TPnE9SXgLYb8JPwzSbWs0H9T+SKP+tMfmmnzQw6y953rHjOGG7hpy4SKGD /ydJx2wFn6XroKFrYYJ7Jmy3PrN6dfMCB2vx05A0knP3z9+g07TfI/Oe1eyX EVh98+LpHj; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: pwe3 Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? 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, 15 Apr 2009 10:52:40 -0000 Lucy The statement in (4) is still correct, because you can turn the hello rate down and use the network indication fault indication to indicate the absence of end to end connectivity. You can't turn hello's off because they carry all sorts of adjacency information, but you can still configure the system so that connectivity loss is primarily reported through loss of light or its functional equivalent (PW down) and this is what we propose in the text. It might be useful of I added some text to the draft stating that the scaling improvement occurs because the operator can reduce the hello packet and BFD rate. Stewart Lucy Yong wrote: > Hi Stewart, > > If link hello protocol can't be turned off, then the following statement in > the section 4 does not apply. LSR has to use link state routing protocol to > decide if the interface is up or down. I suggest revising the section 4 and > adding your description (below) in. > > 4. Status Indication > > A pseudowire status indicating a fault can be considered equivalent > to interface down and SHOULD be passed across the virtual interface > to the local LSR. This improves scaling in PE with large numbers of > c-resident LSRs and with LSRs that have large numbers of interfaces > mapped to pseudowires. > > We should also mention in the draft that since client LSR runs its own link > state protocols to its peers, there is no need to use PW status message to > carry LSR local link state fault to Packet-PW remote. > > Regards, > Lucy > > >> -----Original Message----- >> From: Stewart Bryant [mailto:stbryant@cisco.com] >> Sent: Tuesday, April 14, 2009 2:51 AM >> To: Lucy Yong >> Cc: 'Andrew G. Malis'; jiang.xiaowei@zte.com.cn; pwe3@ietf.org >> Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? >> >> Lucy >> >> Turning off bits of the routing protocol is actually quite hard, risks >> breaking the protocol and requires us to track and reflect those changes >> in the surrogate protocol. We would therefore want to run the link state >> routing protocol unmodified including the hellos. >> >> Stewart >> >> >> Lucy Yong wrote: >> >>> Hi Andy and XiaoWei, >>> >>> >>> >>> Since the purpose of packet-PW is to create a virtual physical >>> interface for two connected client LSRs and allow multiple client >>> protocols run over it. Assume the client LSP is IP router, it runs >>> OSPF or IS-IS. To support the routing protocol properly running, IP >>> interface is configured over a packet-PW. Hello protocol is normally >>> activated over IP interface. However, if we want to use packet-PW >>> state as IP interface state, we need to turn off hello protocol. Is >>> that right? That is my second point in previous e-mail. >>> >>> >>> >>> Thanks, >>> >>> Lucy >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On >>> Behalf Of *Andrew G. Malis >>> *Sent:* Wednesday, April 08, 2009 8:42 AM >>> *To:* jiang.xiaowei@zte.com.cn >>> *Cc:* pwe3@ietf.org; stbryant@cisco.com >>> *Subject:* Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? >>> >>> >>> >>> Jiang, >>> >>> >>> >>> I don't think so, but we should look more closely at the details on >>> mapping between the virtual interface state and PW status reporting >>> (without being implementation-dependent) to make sure we've got the >>> all of the details covered. Lucy's point 3 is a good one as well. >>> >>> >>> >>> Thanks, >>> >>> Andy >>> >>> >>> >>> On Wed, Apr 8, 2009 at 7:46 AM, >> > wrote: >>> >>> >>> Andy, >>> >>> Is there any need for Packet-PW to maintain any kind of state machine >>> for virtual interface status like Lucy Yong mentioned? >>> >>> Thanks, >>> Albert >>> >>> >>> >>> *Lucy Yong >* >>> sender: pwe3-bounces@ietf.org >>> >>> 2009-04-01 01:13 >>> >>> >>> >>> to >>> >>> >>> >>> 'Stewart Bryant' >, >>> pwe3@ietf.org , "'Malis, Andrew G. (Andy)'" >>> > >>> >>> cc >>> >>> >>> >>> >>> >>> topic >>> >>> >>> >>> [PWE3] comments on packet pw >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hi Stewart and Andy, >>> >>> I support this draft to become WG draft. Congratulation!! >>> I also have some comments on the draft: >>> >>> 1) Since Packet PW requires using CW, it is necessary to state how >>> to use flow label and S/N for packet PW. >>> 2) It is good to have the PW status mapped to virtual interfaces. >>> However, *each protocol interface may have its own link status >>> protocol* running, the draft should state the procedures to determine >>> interface status, or require each protocol interface to turn off its >>> link protocol when using Packet PW >>> 3) Since Packet PW acts as a data link between two clients LSRs, >>> the draft should state link operational procedures (for client >>> networks) over a packet PW such as how to determine admin cost, TE >>> metrics, etc. >>> 4) I assume that a Packet PW can obtain transport resiliency from >>> server MPLS network, it would be nice for the draft to state them and >>> considers that the consequence may change admin cost in client networks. >>> >>> Cheers, >>> Lucy_______________________________________________ >>> >>> >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> >>> >>> >>> >>> >>> *"Andrew G. Malis" >* >>> >>> 2009-04-04 23:39 >>> >>> >>> >>> >>> >>> >>> >>> jiang.xiaowei@zte.com.cn >>> >>> >>> >>> >>> >>> stbryant@cisco.com , pwe3@ietf.org >>> >>> >>> >>> >>> >>> >>> Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Jiang, >>> >>> Yes it could, but in addition to higher overhead it would also require >>> running the PPP state machine and using PPP options. We wanted to keep >>> this as simple as possible. >>> >>> Thanks, >>> Andy >>> >>> 2009/4/3 >: >>> >>>> Sir, >>>> >>>> Could rfc4618 Encapsulation Methods for Transport of PPP/High-Level >>>> > Data > >>>> Link Control (HDLC) over MPLS Networks >>>> be used as a solution for the scenario in this draft? (although have >>>> > more > >>>> encapsulation overhead) >>>> >>>> Thank you! >>>> >>> >>> > > > From stbryant@cisco.com Wed Apr 15 04:19:44 2009 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 403D23A6B85 for ; Wed, 15 Apr 2009 04:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.646 X-Spam-Level: X-Spam-Status: No, score=-9.646 tagged_above=-999 required=5 tests=[AWL=0.953, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 HGaimDvG+xFg for ; Wed, 15 Apr 2009 04:19:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 821EB3A6BBA for ; Wed, 15 Apr 2009 04:19:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,192,1238976000"; d="scan'208";a="38355238" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2009 11:20:53 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3FBKr4r029561; Wed, 15 Apr 2009 13:20:53 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FBKrH2009899; Wed, 15 Apr 2009 11:20:53 GMT Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n3FBKqe05973; Wed, 15 Apr 2009 12:20:52 +0100 (BST) Message-ID: <49E5C313.9020205@cisco.com> Date: Wed, 15 Apr 2009 12:20:51 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Shah, Himanshu" References: <008701c9b87e$dd04f710$670c7c0a@china.huawei.com><49E44075.8000808@cisco.com> <005f01c9bd4f$863adb40$670c7c0a@china.huawei.com> <6535C9CED6F87446B41D20EF170F23623161EB@mamxm01.ciena.com> In-Reply-To: <6535C9CED6F87446B41D20EF170F23623161EB@mamxm01.ciena.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8035; t=1239794453; x=1240658453; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20draft-bryant-pwe3-packet-pw-00 .txt=20to=20WG=20draft? |Sender:=20; bh=8KOV8dUoRcd8DfTlI3N9xfFZk5Av1fsQ2LrVioRmnGY=; b=lK5uCNhd91sDF6ML5egrgwHGk132ZLcW+m5vvntAsA5IAaumUXNa5y3igi vHOicbakW6xBvLYqBmE+I0HUmZt8ecPIImT/YfhwkMtzmHmO44hzdd2Hoa/u m9S1bZ9177; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? 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, 15 Apr 2009 11:19:44 -0000 Himanshu You are not missing anything. The protocol carried over the PW must remain unchanged. A failure of the PW looks like "loss of light" which is always reflected up to routing. The proposal is therefore to run the routing layer exactly as we normally do and to create a signal that is equivalent to LoL that is passed up to the virtual interface. Stewart Shah, Himanshu wrote: > > Not sure where this discussion is going but... > > if a physical point-to-point connection is being > mimicked by a 'virtual wire' (i.e. pw) with its > corresponding mechanisms of up/down (i.e. pw status), etc, > why should layer above (or for that matter layer below) > start making exceptions?? > > what am I missing here??? > > /himanshu > > > > > -----Original Message----- > > > From: pwe3-bounces@ietf.org on behalf of Lucy Yong > Sent: Tue 4/14/2009 6:22 PM > To: stbryant@cisco.com > Cc: pwe3@ietf.org > Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? > > Hi Stewart, > > If link hello protocol can't be turned off, then the following > statement in > the section 4 does not apply. LSR has to use link state routing > protocol to > decide if the interface is up or down. I suggest revising the section > 4 and > adding your description (below) in. > > 4. Status Indication > > A pseudowire status indicating a fault can be considered equivalent > to interface down and SHOULD be passed across the virtual interface > to the local LSR. This improves scaling in PE with large numbers of > c-resident LSRs and with LSRs that have large numbers of interfaces > mapped to pseudowires. > > We should also mention in the draft that since client LSR runs its own > link > state protocols to its peers, there is no need to use PW status message to > carry LSR local link state fault to Packet-PW remote. > > Regards, > Lucy > > > -----Original Message----- > > From: Stewart Bryant [mailto:stbryant@cisco.com] > > Sent: Tuesday, April 14, 2009 2:51 AM > > To: Lucy Yong > > Cc: 'Andrew G. Malis'; jiang.xiaowei@zte.com.cn; pwe3@ietf.org > > Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? > > > > Lucy > > > > Turning off bits of the routing protocol is actually quite hard, risks > > breaking the protocol and requires us to track and reflect those changes > > in the surrogate protocol. We would therefore want to run the link state > > routing protocol unmodified including the hellos. > > > > Stewart > > > > > > Lucy Yong wrote: > > > > > > Hi Andy and XiaoWei, > > > > > > > > > > > > Since the purpose of packet-PW is to create a virtual physical > > > interface for two connected client LSRs and allow multiple client > > > protocols run over it. Assume the client LSP is IP router, it runs > > > OSPF or IS-IS. To support the routing protocol properly running, IP > > > interface is configured over a packet-PW. Hello protocol is normally > > > activated over IP interface. However, if we want to use packet-PW > > > state as IP interface state, we need to turn off hello protocol. Is > > > that right? That is my second point in previous e-mail. > > > > > > > > > > > > Thanks, > > > > > > Lucy > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On > > > Behalf Of *Andrew G. Malis > > > *Sent:* Wednesday, April 08, 2009 8:42 AM > > > *To:* jiang.xiaowei@zte.com.cn > > > *Cc:* pwe3@ietf.org; stbryant@cisco.com > > > *Subject:* Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? > > > > > > > > > > > > Jiang, > > > > > > > > > > > > I don't think so, but we should look more closely at the details on > > > mapping between the virtual interface state and PW status reporting > > > (without being implementation-dependent) to make sure we've got the > > > all of the details covered. Lucy's point 3 is a good one as well. > > > > > > > > > > > > Thanks, > > > > > > Andy > > > > > > > > > > > > On Wed, Apr 8, 2009 at 7:46 AM, > > > wrote: > > > > > > > > > Andy, > > > > > > Is there any need for Packet-PW to maintain any kind of state machine > > > for virtual interface status like Lucy Yong mentioned? > > > > > > Thanks, > > > Albert > > > > > > > > > > > > *Lucy Yong >* > > > sender: pwe3-bounces@ietf.org > > > > > > 2009-04-01 01:13 > > > > > > > > > > > > to > > > > > > > > > > > > 'Stewart Bryant' >, > > > pwe3@ietf.org , "'Malis, Andrew G. (Andy)'" > > > > > > > > > > cc > > > > > > > > > > > > > > > > > > topic > > > > > > > > > > > > [PWE3] comments on packet pw > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Stewart and Andy, > > > > > > I support this draft to become WG draft. Congratulation!! > > > I also have some comments on the draft: > > > > > > 1) Since Packet PW requires using CW, it is necessary to state how > > > to use flow label and S/N for packet PW. > > > 2) It is good to have the PW status mapped to virtual interfaces. > > > However, *each protocol interface may have its own link status > > > protocol* running, the draft should state the procedures to determine > > > interface status, or require each protocol interface to turn off its > > > link protocol when using Packet PW > > > 3) Since Packet PW acts as a data link between two clients LSRs, > > > the draft should state link operational procedures (for client > > > networks) over a packet PW such as how to determine admin cost, TE > > > metrics, etc. > > > 4) I assume that a Packet PW can obtain transport resiliency from > > > server MPLS network, it would be nice for the draft to state them and > > > considers that the consequence may change admin cost in client > networks. > > > > > > Cheers, > > > Lucy_______________________________________________ > > > > > > > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > > > > > > *"Andrew G. Malis" >* > > > > > > 2009-04-04 23:39 > > > > > > > > > > > > > > > > > > > > > > > > jiang.xiaowei@zte.com.cn > > > > > > > > > > > > > > > > > > stbryant@cisco.com , pwe3@ietf.org > > > > > > > > > > > > > > > > > > > > > Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jiang, > > > > > > Yes it could, but in addition to higher overhead it would also require > > > running the PPP state machine and using PPP options. We wanted to keep > > > this as simple as possible. > > > > > > Thanks, > > > Andy > > > > > > 2009/4/3 >: > > > > > > > > Sir, > > > > > > > > Could rfc4618 Encapsulation Methods for Transport of PPP/High-Level > Data > > > > Link Control (HDLC) over MPLS Networks > > > > be used as a solution for the scenario in this draft? (although have > more > > > > encapsulation overhead) > > > > > > > > Thank you! > > > > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From lucyyong@huawei.com Wed Apr 15 07:42:32 2009 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 2A2FD28C23D for ; Wed, 15 Apr 2009 07:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.456, 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 45xJRupriiKj for ; Wed, 15 Apr 2009 07:42:31 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id C1D2E28C21C for ; Wed, 15 Apr 2009 07:42:30 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI500B5QCWUSC@usaga04-in.huawei.com> for pwe3@ietf.org; Wed, 15 Apr 2009 09:43:42 -0500 (CDT) Received: from Y73674 ([10.124.12.103]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI500ECQCWSMF@usaga04-in.huawei.com> for pwe3@ietf.org; Wed, 15 Apr 2009 09:43:42 -0500 (CDT) Date: Wed, 15 Apr 2009 09:43:40 -0500 From: Lucy Yong In-reply-to: <49E5BCBB.6060705@cisco.com> To: stbryant@cisco.com Message-id: <002101c9bdd8$9199ef60$670c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acm9uHh/bGIIXj4SRUK1+DZ4ytX6GwAHX7Eg References: <008701c9b87e$dd04f710$670c7c0a@china.huawei.com> <49E44075.8000808@cisco.com> <005f01c9bd4f$863adb40$670c7c0a@china.huawei.com> <49E5BCBB.6060705@cisco.com> Cc: 'pwe3' Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? 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, 15 Apr 2009 14:42:32 -0000 Hi Stewart, Thank you for the explanation. It is good to state this in the draft. In addition, clarify that org PW is responsible to pass local ACH fault to PW remote, but packet-PW is not necessary to carry client link fault to packet-PW remote because client has its own link state protocol. Regards, Lucy > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Wednesday, April 15, 2009 5:54 AM > To: Lucy Yong > Cc: pwe3 > Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? > > Lucy > > The statement in (4) is still correct, because you can turn the hello > rate down and > use the network indication fault indication to indicate the absence of > end to end > connectivity. > > You can't turn hello's off because they carry all sorts of adjacency > information, but > you can still configure the system so that connectivity loss is > primarily reported > through loss of light or its functional equivalent (PW down) and this is > what we > propose in the text. > > It might be useful of I added some text to the draft stating that the > scaling > improvement occurs because the operator can reduce the hello packet and > BFD rate. > > Stewart > > Lucy Yong wrote: > > Hi Stewart, > > > > If link hello protocol can't be turned off, then the following statement in > > the section 4 does not apply. LSR has to use link state routing protocol to > > decide if the interface is up or down. I suggest revising the section 4 and > > adding your description (below) in. > > > > 4. Status Indication > > > > A pseudowire status indicating a fault can be considered equivalent > > to interface down and SHOULD be passed across the virtual interface > > to the local LSR. This improves scaling in PE with large numbers of > > c-resident LSRs and with LSRs that have large numbers of interfaces > > mapped to pseudowires. > > > > We should also mention in the draft that since client LSR runs its own link > > state protocols to its peers, there is no need to use PW status message to > > carry LSR local link state fault to Packet-PW remote. > > > > Regards, > > Lucy > > > > > >> -----Original Message----- > >> From: Stewart Bryant [mailto:stbryant@cisco.com] > >> Sent: Tuesday, April 14, 2009 2:51 AM > >> To: Lucy Yong > >> Cc: 'Andrew G. Malis'; jiang.xiaowei@zte.com.cn; pwe3@ietf.org > >> Subject: Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? > >> > >> Lucy > >> > >> Turning off bits of the routing protocol is actually quite hard, risks > >> breaking the protocol and requires us to track and reflect those changes > >> in the surrogate protocol. We would therefore want to run the link state > >> routing protocol unmodified including the hellos. > >> > >> Stewart > >> > >> > >> Lucy Yong wrote: > >> > >>> Hi Andy and XiaoWei, > >>> > >>> > >>> > >>> Since the purpose of packet-PW is to create a virtual physical > >>> interface for two connected client LSRs and allow multiple client > >>> protocols run over it. Assume the client LSP is IP router, it runs > >>> OSPF or IS-IS. To support the routing protocol properly running, IP > >>> interface is configured over a packet-PW. Hello protocol is normally > >>> activated over IP interface. However, if we want to use packet-PW > >>> state as IP interface state, we need to turn off hello protocol. Is > >>> that right? That is my second point in previous e-mail. > >>> > >>> > >>> > >>> Thanks, > >>> > >>> Lucy > >>> > >>> > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> *From:* pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] *On > >>> Behalf Of *Andrew G. Malis > >>> *Sent:* Wednesday, April 08, 2009 8:42 AM > >>> *To:* jiang.xiaowei@zte.com.cn > >>> *Cc:* pwe3@ietf.org; stbryant@cisco.com > >>> *Subject:* Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? > >>> > >>> > >>> > >>> Jiang, > >>> > >>> > >>> > >>> I don't think so, but we should look more closely at the details on > >>> mapping between the virtual interface state and PW status reporting > >>> (without being implementation-dependent) to make sure we've got the > >>> all of the details covered. Lucy's point 3 is a good one as well. > >>> > >>> > >>> > >>> Thanks, > >>> > >>> Andy > >>> > >>> > >>> > >>> On Wed, Apr 8, 2009 at 7:46 AM, >>> > wrote: > >>> > >>> > >>> Andy, > >>> > >>> Is there any need for Packet-PW to maintain any kind of state machine > >>> for virtual interface status like Lucy Yong mentioned? > >>> > >>> Thanks, > >>> Albert > >>> > >>> > >>> > >>> *Lucy Yong >* > >>> sender: pwe3-bounces@ietf.org > >>> > >>> 2009-04-01 01:13 > >>> > >>> > >>> > >>> to > >>> > >>> > >>> > >>> 'Stewart Bryant' >, > >>> pwe3@ietf.org , "'Malis, Andrew G. (Andy)'" > >>> > > >>> > >>> cc > >>> > >>> > >>> > >>> > >>> > >>> topic > >>> > >>> > >>> > >>> [PWE3] comments on packet pw > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Hi Stewart and Andy, > >>> > >>> I support this draft to become WG draft. Congratulation!! > >>> I also have some comments on the draft: > >>> > >>> 1) Since Packet PW requires using CW, it is necessary to state how > >>> to use flow label and S/N for packet PW. > >>> 2) It is good to have the PW status mapped to virtual interfaces. > >>> However, *each protocol interface may have its own link status > >>> protocol* running, the draft should state the procedures to determine > >>> interface status, or require each protocol interface to turn off its > >>> link protocol when using Packet PW > >>> 3) Since Packet PW acts as a data link between two clients LSRs, > >>> the draft should state link operational procedures (for client > >>> networks) over a packet PW such as how to determine admin cost, TE > >>> metrics, etc. > >>> 4) I assume that a Packet PW can obtain transport resiliency from > >>> server MPLS network, it would be nice for the draft to state them and > >>> considers that the consequence may change admin cost in client networks. > >>> > >>> Cheers, > >>> Lucy_______________________________________________ > >>> > >>> > >>> pwe3 mailing list > >>> pwe3@ietf.org > >>> https://www.ietf.org/mailman/listinfo/pwe3 > >>> > >>> > >>> > >>> > >>> > >>> *"Andrew G. Malis" >* > >>> > >>> 2009-04-04 23:39 > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> jiang.xiaowei@zte.com.cn > >>> > >>> > >>> > >>> > >>> > >>> stbryant@cisco.com , pwe3@ietf.org > >>> > >>> > >>> > >>> > >>> > >>> > >>> Re: [PWE3] draft-bryant-pwe3-packet-pw-00.txt to WG draft? > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Jiang, > >>> > >>> Yes it could, but in addition to higher overhead it would also require > >>> running the PPP state machine and using PPP options. We wanted to keep > >>> this as simple as possible. > >>> > >>> Thanks, > >>> Andy > >>> > >>> 2009/4/3 >: > >>> > >>>> Sir, > >>>> > >>>> Could rfc4618 Encapsulation Methods for Transport of PPP/High-Level > >>>> > > Data > > > >>>> Link Control (HDLC) over MPLS Networks > >>>> be used as a solution for the scenario in this draft? (although have > >>>> > > more > > > >>>> encapsulation overhead) > >>>> > >>>> Thank you! > >>>> > >>> > >>> > > > > > > From root@core3.amsl.com Wed Apr 15 13:45:02 2009 Return-Path: X-Original-To: pwe3@ietf.org Delivered-To: pwe3@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 10E383A6C6C; Wed, 15 Apr 2009 13:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090415204502.10E383A6C6C@core3.amsl.com> Date: Wed, 15 Apr 2009 13:45:02 -0700 (PDT) Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-oam-msg-map-10.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, 15 Apr 2009 20:45:02 -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 : Pseudo Wire (PW) OAM Message Mapping Author(s) : L. Martini, M. Morrow Filename : draft-ietf-pwe3-oam-msg-map-10.txt Pages : 39 Date : 2009-04-15 This document specifies the mapping and notification of defect states between a Pseudo Wire and the Attachment Circuits (AC) of the end-to- end emulated service. This document covers the case whereby the ACs and the PWs are of the same type in accordance to the PWE3 architecture [RFC3985] such that a homogenous PW service can be constructed. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-oam-msg-map-10.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-oam-msg-map-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-15133713.I-D@ietf.org> --NextPart-- From stbryant@cisco.com Mon Apr 20 03:42:24 2009 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 263C93A6D30 for ; Mon, 20 Apr 2009 03:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.301 X-Spam-Level: X-Spam-Status: No, score=-9.301 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] 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 Odpv4qwOCekC for ; Mon, 20 Apr 2009 03:42:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8831B3A69F2 for ; Mon, 20 Apr 2009 03:42:22 -0700 (PDT) X-Files: I-D ACTION:draft-irtf-iccrg-welzl-congestion-control-open-research-03.txt.eml : None X-IronPort-AV: E=Sophos;i="4.40,217,1238976000"; d="eml'208?txt'208,208?scan'208,208,208";a="38661827" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Apr 2009 10:43:35 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3KAhZlg005938 for ; Mon, 20 Apr 2009 12:43:35 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3KAhZ3a005331 for ; Mon, 20 Apr 2009 10:43:35 GMT Received: from Stewarts-Computer.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n3KAhYH26811; Mon, 20 Apr 2009 11:43:34 +0100 (BST) Message-ID: <49EC51D5.3060604@cisco.com> Date: Mon, 20 Apr 2009 11:43:33 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: pwe3 Content-Type: multipart/mixed; boundary="------------090407060008060107070001" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5245; t=1240224215; x=1241088215; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20draft-irtf-iccrg-welzl-congestion-control-open- research-03.txt |Sender:=20; bh=F8Mezkyesge2B0h+Vh8NK0n5OXhtkMsibUlo9KEyNV0=; b=fLs86BrKVJej6C9vfWVjgaB58ELVANOHqSDm1/vbpcvrXc75VcZevcOR+N gKhJgxqn9/+azeC4nurgfzPvm5Sy4dQ6Fyh8se/4Ue1fh+hRIjXfrbFCiUNu bsiyyV16GP; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [PWE3] draft-irtf-iccrg-welzl-congestion-control-open-research-03.txt 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: Mon, 20 Apr 2009 10:42:24 -0000 This is a multi-part message in MIME format. --------------090407060008060107070001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This may be of interest to those of us thinking about congestion issues in PWE3 Stewart --------------090407060008060107070001 Content-Type: message/rfc822; name="I-D ACTION:draft-irtf-iccrg-welzl-congestion-control-open-research-03.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="I-D ACTION:draft-irtf-iccrg-welzl-congestion-control-open-r"; filename*1="esearch-03.txt.eml" X-Account-Key: account3 X-Mozilla-Keys: Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n3HNJGv23770 for ; Sat, 18 Apr 2009 00:19:16 +0100 (BST) X-Files: draft-irtf-iccrg-welzl-congestion-control-open-research-03.txt : None Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 17 Apr 2009 23:19:15 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3HNJF8k008493; Fri, 17 Apr 2009 16:19:15 -0700 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n3HNJCUX018468; Fri, 17 Apr 2009 23:19:15 GMT X-from-outside-Cisco: 64.170.98.32 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsAANWq6ElAqmIglGdsb2JhbACVQ3YBAQEBCQsICREFuDSDfQY X-IronPort-AV: E=Sophos;i="4.40,206,1238976000"; d="txt'208?scan'208,208";a="77045313" Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-d.cisco.com with ESMTP; 17 Apr 2009 23:19:15 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDAF928C279; Fri, 17 Apr 2009 16:15:04 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C03DD28C1CE; Fri, 17 Apr 2009 16:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-irtf-iccrg-welzl-congestion-control-open-research-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090417231501.C03DD28C1CE@core3.amsl.com> Date: Fri, 17 Apr 2009 16:15:01 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org Authentication-Results: sj-dkim-3; header.From=Internet-Drafts@ietf.org; dkim=neutral --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Open Research Issues in Internet Congestion Control Author(s) : M. Welzl, M. Scharf, B. Briscoe, D. Papadimitriou Filename : draft-irtf-iccrg-welzl-congestion-control-open-research-03.txt Pages : 42 Date : 2009-4-17 This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet- scale solutions can be confidently engineered and deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-iccrg-welzl-congestion-control-open-research-03.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-irtf-iccrg-welzl-congestion-control-open-research-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-4-17160715.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --------------090407060008060107070001-- From frederic.jounay@orange-ftgroup.com Mon Apr 20 05:54:39 2009 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 343843A6A03; Mon, 20 Apr 2009 05:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.041 X-Spam-Level: X-Spam-Status: No, score=-3.041 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 S7W8t7kFhQzo; Mon, 20 Apr 2009 05:54:38 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 100093A6880; Mon, 20 Apr 2009 05:54:36 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 14:55:51 +0200 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_01C9C1B7.54E3C9DB" Date: Mon, 20 Apr 2009 14:55:50 +0200 Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A15831A94@ftrdmel2> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-jounay-pwe3-leaf-initiated-p2mp-pw-01 Thread-Index: Acm9jlnaCD2g/oeyRcOBi1Jj3dpxHQEJlKhQ References: From: To: X-OriginalArrivalTime: 20 Apr 2009 12:55:51.0217 (UTC) FILETIME=[555E0210:01C9C1B7] Cc: l2vpn@ietf.org, l2vpn-bounces@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] Comments on draft-jounay-pwe3-leaf-initiated-p2mp-pw-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: Mon, 20 Apr 2009 12:54:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C1B7.54E3C9DB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWGlucXVhbiwNCiANClBsZWFzZSBzZWUgbXkgYW5zd2VyIGlubGluZSBbRkpdDQogDQpCZXN0 IFJlZ2FyZHMsDQpGcmVkDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K RGUgOiB6aGFuZy54aW5xdWFuQHp0ZS5jb20uY24gW21haWx0bzp6aGFuZy54aW5xdWFuQHp0ZS5j b20uY25dIA0KRW52b3nDqSA6IG1lcmNyZWRpIDE1IGF2cmlsIDIwMDkgMDc6NTANCsOAIDogSk9V TkFZIEZyZWRlcmljIFJELVJFU0EtTEFODQpDYyA6IGwydnBuQGlldGYub3JnOyBsMnZwbi1ib3Vu Y2VzQGlldGYub3JnDQpPYmpldCA6IENvbW1lbnRzIG9uIGRyYWZ0LWpvdW5heS1wd2UzLWxlYWYt aW5pdGlhdGVkLXAybXAtcHctMDENCg0KDQoNCkhpLCBGcmVkZXJpYywgDQoNCkkgaGF2ZSByZWFk IGRyYWZ0LWpvdW5heS1wd2UzLWxlYWYtaW5pdGlhdGVkLXAybXAtcHctMDEgYW5kIGhhdmUgc29t ZSBjb21tZW50cy4gcGxlYXNlIHNlZSBiZWxvdzogDQoNCjHjgIFzZWN0aW9uIDUuNC4gQ29uZmln dXJhdGlvbiANCiAgICANCiAgIEFmdGVyIGNvbmZpZ3VyaW5nIG9uIGVhY2ggVC1QRSB0aGUgYXR0 YWNoZWQgQUlJcywgaXQgaXMgYXNzdW1lZCB0aGF0IA0KICAgYWxsIHRoZSBQRXMgKEluZ3Jlc3Mv RWdyZXNzIFQtUEVzIGFuZCBhbGwgUy1QRXMpIG1haW50YWluIGFuIEFJSSBQVyANCiAgIHJvdXRp bmcgdGFibGUgd2hpY2ggZ2l2ZXMgZm9yIGVhY2ggQUlJIGFzIGVudHJ5IHRoZSAibmV4dCBob3Ai IHRvIA0KICAgcmVhY2ggdGhhdCBBSUkuIFRoaXMgQUlJIHJvdXRpbmcgdGFibGUgY2FuIGJlIGZp bGxlZCBtYW51YWxseSBvciANCiAgIHVwZGF0ZWQgZHluYW1pY2FsbHkgYnkgbWVhbnMgb2Ygc29t ZSBleHRlbmRlZCByb3V0aW5nIHByb3RvY29sIGxpa2UgDQogICBwcm9wb3NlZCBpbiBbRFlOIE1T LVBXXS4gVGhlIGNvbnN0cnVjdGlvbiBvZiB0aGUgdGFibGUgaXMgb3V0IG9mIA0KICAgc2NvcGUg b2YgdGhlIHByZXNlbnQgZG9jdW1lbnQuIA0KICAgIA0KICAgRWFjaCBQRSByZWxpZXMgb24gaXRz IEFJSSBQVyByb3V0aW5nIHRhYmxlIHRvIHNlbGVjdCB0aGUgbmV4dCBob3AgUEUgDQogICAoUy1Q RSBvciBULVBFKSB0byByZWFjaCBhIGdpdmVuIEFJSS4gDQoNCj4xICBEb2VzIHRoaXMgQUlJIHJv dXRpbmcgdGFibGUgaW5jbHVkZSBib3RoIFRBSUkgYW5kIFNBSUk/IA0KW0ZKXSBZZXMsIHRoZSBB SUkgcm91dGluZyB0YWJsZSBkeW5hbWljYWxseSBwb3B1bGF0ZWQgKEJHUCwgT1NQRiwgSVMtSVMg b3IgTERQKSBzaG91bGQgbWFpbnRhaW4gYm90aC4gVGhlIEVncmVzcyBULVBFIGpvaW5zIHRoZSBQ VyB0cmVlIGJ5IGluaXRpYXRpbmcgYSBMYWJlbCBNYXAgd2hvc2UgdGhlIEZFQyBjb250YWlucyB0 aGUgU0FJSSwgdGhlIFBXIHRyZWUgc291cmNlLiBIZW5jZSB1cG9uIHJlY2VpcHQgb2YgdGhlIG1l c3NhZ2UgdGhlIFMtUEUgZG9lcyBhIGxvb2t1cCB0byBzZWxlY3QgdGhlIE5IIHRvIHJlYWNoIHRo aXMgU0FJSS4gICAgICANCj4yICBJbiBTLVBFLCB0aGlzIEFJSSByb3V0aW5nIHRhYmxlIGluY2x1 ZGVzIGFsbCB0aGUgQUlJLCBvciBqdXN0IHBhcnQgb2YgdGhlIEFJSSggZS5nLiB3aGljaCBhcmUg aW4gaXRzIGRvd3N0cmVhbSk/IA0KIFtGSl0gdGhlIEFJSSByb3V0aW5nIHRhYmxlIHNob3VsZCBi ZSB1c2VkIGFsc28gZm9yIFZQV1Mgb3IgVlBMUywgc28gYmlkaXJlY3Rpb25hbCBQVy4gVGhlcmVm b3JlIHRoZSBBSUkgcm91dGluZyB0YWJsZSBtdXN0IHJlZmxlY3QgYWxsIHRoZSBBSUkgY29uZmln dXJlZCBvbiBULVBFcy4gT2YgY291cnNlIGFncmVnYXRlIEFJSSBmb3JtYXQgKGkuZS4gdy9vIEFD SUQgaW5mbykgYXMgZGVmaW5lZCBpbiBbRFlOIE1TLVBXXSBtdXN0IGJlIHVzZWQgdG8gb3B0aW1p emUgdGhlIEFJSSByb3V0aW5nIHRhYmxlDQoNCjLjgIFTZWN0aW9uIDUuNy4gVXNpbmcgVEFJSSBM ZWFmIFN1Yi1UTFYgDQogICAgDQogICBTZWN0aW9uIFRCRCANCiAgICANCiAgIFRoZSBUQUlJIExl YWYgc3ViLVRMViBNQVkgYmUgb3B0aW9uYWxseSB1c2VkIHdoZW4gYSBsZWFmIGpvaW5zIHRoZSBQ VyANCiAgIHRyZWUgdG8gYW5ub3VuY2UgdG8gdGhlIHNvdXJjZSB0aGF0IGl0IGlzIHBhcnQgZnJv bSB0aGUgUFcgdHJlZS4gSWYgDQogICB0aGlzIG9wdGlvbiBpcyBjaG9zZW4sIHRoZSBFZ3Jlc3Mg VC1QRSBhZGRzIHRvIHRoZSBGRUMgRWxlbWVudCB0aGlzIA0KICAgVEFJSSBzdWItVExWIGluIHRo ZSBMYWJlbCBNYXAgbWVzc2FnZS4gQXMgc29vbiBhcyBpbiB0aGUgc291cmNlIA0KICAgZGlyZWN0 aW9uIGEgTGFiZWwgTWFwIGlzIG5vdCByZXF1aXJlZCBzaW5jZSBmb3IgaW5zdGFuY2UgYSBTLVBF IA0KICAgYWxyZWFkeSBtYWludGFpbnMgYSBzdGF0ZSBmb3IgdGhpcyBNUy1QVyB0cmVlLCB0aGUg aW5mb3JtYXRpb24gDQogICByZWxhdGVkIHRvIHRoZSBMZWFmIFRBSUlzIGlzIHJldHJpZXZlZCBm cm9tIHRoZSBUQUlJIExlYWYgc3ViLVRMViBhbmQgDQogICBpcyBwcm9wYWdhdGVkIGJ5IG1lYW5z IG9mIGEgTERQIE5vdGlmaWNhdGlvbiBtZXNzYWdlIHVwIHRvIHRoZSANCiAgIGNvcnJlc3BvbmRp bmcgSW5ncmVzcyBULVBFLiAgIA0KPiBJIGFtIG5vdCBzdXJlIGFib3V0IHRoZSBwcm9wYWdhdGlv biBvZiBUQUlJIExlYWYgc3ViLVRMVi4gSXMgaXQgc2VudCB0byBpbmdyZXNzIFQtUEUgZGlyZWN0 bHksIG9yIHRvIHRoZSB1cHN0cmVhbSBTLVBFKGlmIHRoZXJlIGV4aXN0cyBzdWNoIFMtUEUgaW4g dGhlIHVwc3RyZWFtIGRpcmVjdGlvbik/ICANCltGSl0gVGhlIE5vdGlmaWNhdGlvbiBtZXNzYWdl IGNhbiBub3QgYmUgZGlyZWN0bHkgc2VudCB0byB0aGUgSW5ncmVzcyBULVBFIGlmIHRoZXJlIGlz IG5vdCBkaXJlY3QgVC1MRFAgc2Vzc2lvbiB0byByZWFjaCB0aGUgSW5ncmVzcyBULVBFLCBpLmUu IFMtUEUgaW4gYmV0d2Vlbi4gVGhhdCdzIHRoZSByZWFzb24gd2h5IHRoZSBtZXNzYWdlIHNob3Vs ZCBiZSBwcm9wYWdhdGVkIGhvcCBieSBob3AgKGkuZS4gUy1QRSBieSBTLVBFKSB1cCB0byB0aGUg SW5ncmVzcyBULVBFLg0KIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCdzIHdvcnRoIGNsYXJpZnlpbmcg dGhpcyBzZWN0aW9uLiANCg0KQmVzdCBSZWdhcmRzISANCg0KWGlucXVhbiBaaGFuZyANCg0KMjAw OS80LzE1IA0KDQoNCg0K ------_=_NextPart_001_01C9C1B7.54E3C9DB Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz05NDM0ODM2MTItMjAwNDIwMDk+PEZPTlQgZmFjZT1B cmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPkhpIFhpbnF1YW4sPC9GT05UPjwvU1BBTj48L0RJ Vj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTk0MzQ4MzYxMi0yMDA0MjAw OT48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4m bmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTk0MzQ4MzYx Mi0yMDA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+UGxlYXNl IHNlZSBteSBhbnN3ZXIgaW5saW5lIFtGSl08L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BB TiBjbGFzcz05NDM0ODM2MTItMjAwNDIwMDk+PC9TUEFOPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQg DQpjb2xvcj0jMDAwMGZmPjxGT05UIHNpemU9Mj48L0ZPTlQ+PC9GT05UPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIHNp emU9Mj48U1BBTiANCmNsYXNzPTk0MzQ4MzYxMi0yMDA0MjAwOT5CZXN0IFI8L1NQQU4+ZWdhcmRz LDwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjxGT05U IGNvbG9yPSMwMDAwZmY+PEZPTlQgc2l6ZT0yPkY8U1BBTiANCmNsYXNzPTk0MzQ4MzYxMi0yMDA0 MjAwOT5yZWQ8L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgY29s b3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PEJSPjwvRElWPg0KPERJViBjbGFzcz1PdXRsb29r TWVzc2FnZUhlYWRlciBsYW5nPWZyIGRpcj1sdHIgYWxpZ249bGVmdD4NCjxIUiB0YWJJbmRleD0t MT4NCjxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5EZSZuYnNwOzo8L0I+IHpoYW5nLnhpbnF1 YW5AenRlLmNvbS5jbiANClttYWlsdG86emhhbmcueGlucXVhbkB6dGUuY29tLmNuXSA8QlI+PEI+ RW52b3nDqSZuYnNwOzo8L0I+IG1lcmNyZWRpIDE1IGF2cmlsIA0KMjAwOSAwNzo1MDxCUj48Qj7D gCZuYnNwOzo8L0I+IEpPVU5BWSBGcmVkZXJpYyBSRC1SRVNBLUxBTjxCUj48Qj5DYyZuYnNwOzo8 L0I+IA0KbDJ2cG5AaWV0Zi5vcmc7IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8QlI+PEI+T2JqZXQm bmJzcDs6PC9CPiBDb21tZW50cyBvbiANCmRyYWZ0LWpvdW5heS1wd2UzLWxlYWYtaW5pdGlhdGVk LXAybXAtcHctMDE8QlI+PC9GT05UPjxCUj48L0RJVj4NCjxESVY+PC9ESVY+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+DQo8RElWPjxCUj48Rk9OVCBmYWNlPXNh bnMtc2VyaWYgc2l6ZT0yPkhpLCBGcmVkZXJpYyw8L0ZPTlQ+IDxCUj48QlI+PEZPTlQgDQpmYWNl PXNhbnMtc2VyaWYgc2l6ZT0yPkkgaGF2ZSByZWFkIGRyYWZ0LWpvdW5heS1wd2UzLWxlYWYtaW5p dGlhdGVkLXAybXAtcHctMDEgDQphbmQgaGF2ZSBzb21lIGNvbW1lbnRzLiBwbGVhc2Ugc2VlIGJl bG93OjwvRk9OVD4gPEJSPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgDQpzaXplPTI+MeOAgXNl Y3Rpb24gNS40LiBDb25maWd1cmF0aW9uIDwvRk9OVD48QlI+PEZPTlQgZmFjZT1zYW5zLXNlcmlm IA0Kc2l6ZT0yPiZuYnNwOyAmbmJzcDsgPC9GT05UPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYg c2l6ZT0yPiZuYnNwOyAmbmJzcDtBZnRlciANCmNvbmZpZ3VyaW5nIG9uIGVhY2ggVC1QRSB0aGUg YXR0YWNoZWQgQUlJcywgaXQgaXMgYXNzdW1lZCB0aGF0IDwvRk9OVD48QlI+PEZPTlQgDQpmYWNl PXNhbnMtc2VyaWYgc2l6ZT0yPiZuYnNwOyAmbmJzcDthbGwgdGhlIFBFcyAoSW5ncmVzcy9FZ3Jl c3MgVC1QRXMgYW5kIGFsbCANClMtUEVzKSBtYWludGFpbiBhbiBBSUkgUFcgPC9GT05UPjxCUj48 Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPiZuYnNwOyANCiZuYnNwO3JvdXRpbmcgdGFibGUg d2hpY2ggZ2l2ZXMgZm9yIGVhY2ggQUlJIGFzIGVudHJ5IHRoZSAibmV4dCBob3AiIHRvIA0KPC9G T05UPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPiZuYnNwOyAmbmJzcDtyZWFjaCB0 aGF0IEFJSS4gVGhpcyBBSUkgDQpyb3V0aW5nIHRhYmxlIGNhbiBiZSBmaWxsZWQgbWFudWFsbHkg b3IgPC9GT05UPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgDQpzaXplPTI+Jm5ic3A7ICZuYnNw O3VwZGF0ZWQgZHluYW1pY2FsbHkgYnkgbWVhbnMgb2Ygc29tZSBleHRlbmRlZCByb3V0aW5nIA0K cHJvdG9jb2wgbGlrZSA8L0ZPTlQ+PEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+Jm5i c3A7ICZuYnNwO3Byb3Bvc2VkIGluIA0KW0RZTiBNUy1QV10uIFRoZSBjb25zdHJ1Y3Rpb24gb2Yg dGhlIHRhYmxlIGlzIG91dCBvZiA8L0ZPTlQ+PEJSPjxGT05UIA0KZmFjZT1zYW5zLXNlcmlmIHNp emU9Mj4mbmJzcDsgJm5ic3A7c2NvcGUgb2YgdGhlIHByZXNlbnQgZG9jdW1lbnQuIA0KPC9GT05U PjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPiZuYnNwOyAmbmJzcDsgPC9GT05UPjxC Uj48Rk9OVCANCmZhY2U9c2Fucy1zZXJpZiBzaXplPTI+Jm5ic3A7ICZuYnNwO0VhY2ggUEUgcmVs aWVzIG9uIGl0cyBBSUkgUFcgcm91dGluZyB0YWJsZSANCnRvIHNlbGVjdCB0aGUgbmV4dCBob3Ag UEUgPC9GT05UPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPiZuYnNwOyANCiZuYnNw OyhTLVBFIG9yIFQtUEUpIHRvIHJlYWNoIGEgZ2l2ZW4gQUlJLiA8L0ZPTlQ+PEJSPjxCUj48Rk9O VCANCmZhY2U9c2Fucy1zZXJpZj48Rk9OVCBzaXplPTI+Jmd0OzEgJm5ic3A7RG9lcyB0aGlzIEFJ SSByb3V0aW5nIHRhYmxlIGluY2x1ZGUgDQpib3RoIFRBSUkgYW5kIFNBSUk/PFNQQU4gY2xhc3M9 OTQzNDgzNjEyLTIwMDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmPiZuYnNw OzwvRk9OVD48L1NQQU4+PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1zYW5z LXNlcmlmPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz05NDM0ODM2MTItMjAwNDIwMDk+PEZPTlQg DQpmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmY+W0ZKXSBZZXMsIHRoZSBBSUkgcm91dGluZyB0YWJs ZSBkeW5hbWljYWxseSBwb3B1bGF0ZWQgDQooQkdQLCBPU1BGLCBJUy1JUyBvciBMRFApJm5ic3A7 c2hvdWxkJm5ic3A7bWFpbnRhaW4gYm90aC4gVGhlIEVncmVzcyANClQtUEUmbmJzcDtqb2lucyB0 aGUgUFcgdHJlZSZuYnNwO2J5IGluaXRpYXRpbmcgYSBMYWJlbCBNYXAmbmJzcDt3aG9zZSB0aGUg RkVDIA0KY29udGFpbnMgdGhlIFNBSUksIHRoZSBQVyB0cmVlIHNvdXJjZS4mbmJzcDtIZW5jZSB1 cG9uIHJlY2VpcHQgb2YgdGhlIA0KbWVzc2FnZSZuYnNwO3RoZSBTLVBFIGRvZXMgYSBsb29rdXAg dG8gc2VsZWN0IHRoZSBOSCB0byByZWFjaCB0aGlzIA0KU0FJSS48L0ZPTlQ+PC9TUEFOPjwvRk9O VD48L0ZPTlQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmPjxGT05UIHNpemU9Mj48U1BBTiANCmNsYXNz PTk0MzQ4MzYxMi0yMDA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8L0ZPTlQ+Jm5ic3A7PC9TUEFOPjwvRk9OVD48L0ZPTlQ+IA0K PEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+Jmd0OzIgJm5ic3A7SW4gUy1QRSwgdGhp cyBBSUkgcm91dGluZyB0YWJsZSANCmluY2x1ZGVzIGFsbCB0aGUgQUlJLCBvciBqdXN0IHBhcnQg b2YgdGhlIEFJSSggZS5nLiB3aGljaCBhcmUgaW4gaXRzIA0KZG93c3RyZWFtKT88L0ZPTlQ+Jm5i c3A7PEJSPjxTUEFOIGNsYXNzPTk0MzQ4MzYxMi0yMDA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0K Y29sb3I9IzAwMDBmZiBzaXplPTI+Jm5ic3A7W0ZKXSB0aGUgQUlJIHJvdXRpbmcgdGFibGUgc2hv dWxkIGJlIHVzZWQgYWxzbyBmb3IgDQpWUFdTIG9yIFZQTFMsIHNvIGJpZGlyZWN0aW9uYWwgUFcu IFRoZXJlZm9yZSB0aGUgQUlJIHJvdXRpbmcgdGFibGUgbXVzdCByZWZsZWN0IA0KYWxsIHRoZSBB SUkgY29uZmlndXJlZCBvbiBULVBFcy4gT2YgY291cnNlIGFncmVnYXRlIEFJSSBmb3JtYXQgKGku ZS4gDQp3L28mbmJzcDtBQ0lEIGluZm8pJm5ic3A7YXMgZGVmaW5lZCBpbiBbRFlOIE1TLVBXXSZu YnNwO211c3QgYmUgdXNlZCB0byBvcHRpbWl6ZSANCnRoZSBBSUkgcm91dGluZyB0YWJsZTwvRk9O VD48L1NQQU4+PEJSPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgDQpzaXplPTI+MuOAgVNlY3Rp b24gNS43LiBVc2luZyBUQUlJIExlYWYgU3ViLVRMViA8L0ZPTlQ+PEJSPjxGT05UIGZhY2U9c2Fu cy1zZXJpZiANCnNpemU9Mj4mbmJzcDsgJm5ic3A7IDwvRk9OVD48QlI+PEZPTlQgZmFjZT1zYW5z LXNlcmlmIHNpemU9Mj4mbmJzcDsgDQombmJzcDtTZWN0aW9uIFRCRCA8L0ZPTlQ+PEJSPjxGT05U IGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+Jm5ic3A7ICZuYnNwOyANCjwvRk9OVD48QlI+PEZPTlQg ZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj4mbmJzcDsgJm5ic3A7VGhlIFRBSUkgTGVhZiBzdWItVExW IE1BWSANCmJlIG9wdGlvbmFsbHkgdXNlZCB3aGVuIGEgbGVhZiBqb2lucyB0aGUgUFcgPC9GT05U PjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgDQpzaXplPTI+Jm5ic3A7ICZuYnNwO3RyZWUgdG8g YW5ub3VuY2UgdG8gdGhlIHNvdXJjZSB0aGF0IGl0IGlzIHBhcnQgZnJvbSB0aGUgUFcgDQp0cmVl LiBJZiA8L0ZPTlQ+PEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+Jm5ic3A7ICZuYnNw O3RoaXMgb3B0aW9uIGlzIA0KY2hvc2VuLCB0aGUgRWdyZXNzIFQtUEUgYWRkcyB0byB0aGUgRkVD IEVsZW1lbnQgdGhpcyA8L0ZPTlQ+PEJSPjxGT05UIA0KZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj4m bmJzcDsgJm5ic3A7VEFJSSBzdWItVExWIGluIHRoZSBMYWJlbCBNYXAgbWVzc2FnZS4gQXMgDQpz b29uIGFzIGluIHRoZSBzb3VyY2UgPC9GT05UPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6 ZT0yPiZuYnNwOyANCiZuYnNwO2RpcmVjdGlvbiBhIExhYmVsIE1hcCBpcyBub3QgcmVxdWlyZWQg c2luY2UgZm9yIGluc3RhbmNlIGEgUy1QRSANCjwvRk9OVD48QlI+PEZPTlQgZmFjZT1zYW5zLXNl cmlmIHNpemU9Mj4mbmJzcDsgJm5ic3A7YWxyZWFkeSBtYWludGFpbnMgYSBzdGF0ZSANCmZvciB0 aGlzIE1TLVBXIHRyZWUsIHRoZSBpbmZvcm1hdGlvbiA8L0ZPTlQ+PEJSPjxGT05UIGZhY2U9c2Fu cy1zZXJpZiANCnNpemU9Mj4mbmJzcDsgJm5ic3A7cmVsYXRlZCB0byB0aGUgTGVhZiBUQUlJcyBp cyByZXRyaWV2ZWQgZnJvbSB0aGUgVEFJSSBMZWFmIA0Kc3ViLVRMViBhbmQgPC9GT05UPjxCUj48 Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPiZuYnNwOyAmbmJzcDtpcyBwcm9wYWdhdGVkIA0K YnkgbWVhbnMgb2YgYSBMRFAgTm90aWZpY2F0aW9uIG1lc3NhZ2UgdXAgdG8gdGhlIDwvRk9OVD48 QlI+PEZPTlQgDQpmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPiZuYnNwOyAmbmJzcDtjb3JyZXNwb25k aW5nIEluZ3Jlc3MgVC1QRS4gJm5ic3A7IA0KPC9GT05UPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2Vy aWYgc2l6ZT0yPiZndDsgSSBhbSBub3Qgc3VyZSBhYm91dCB0aGUgcHJvcGFnYXRpb24gDQpvZiBU QUlJIExlYWYgc3ViLVRMVi4gSXMgaXQgc2VudCB0byBpbmdyZXNzIFQtUEUgZGlyZWN0bHksIG9y IHRvIHRoZSB1cHN0cmVhbSANClMtUEUoaWYgdGhlcmUgZXhpc3RzIHN1Y2ggUy1QRSBpbiB0aGUg dXBzdHJlYW0gZGlyZWN0aW9uKT88L0ZPTlQ+Jm5ic3A7PFNQQU4gDQpjbGFzcz05NDM0ODM2MTIt MjAwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPiZuYnNwOzwv Rk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTk0MzQ4MzYxMi0yMDA0MjAwOT48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPltGSl0gDQpUaGUgTm90aWZpY2F0 aW9uJm5ic3A7bWVzc2FnZSBjYW4gbm90IGJlIGRpcmVjdGx5IHNlbnQgdG8gdGhlIEluZ3Jlc3Mg VC1QRSANCmlmJm5ic3A7dGhlcmUgaXMgbm90IGRpcmVjdCBULUxEUCBzZXNzaW9uIHRvIHJlYWNo IHRoZSZuYnNwO0luZ3Jlc3MgVC1QRSwgaS5lLiANClMtUEUgaW4gYmV0d2Vlbi4mbmJzcDtUaGF0 J3MgdGhlIHJlYXNvbiB3aHkmbmJzcDt0aGUgbWVzc2FnZSBzaG91bGQmbmJzcDtiZSANCnByb3Bh Z2F0ZWQgaG9wIGJ5IGhvcCAoaS5lLiBTLVBFIGJ5IFMtUEUpPC9GT05UPiZuYnNwOzxGT05UIGZh Y2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj51cCB0byB0aGUgSW5ncmVzcyBULVBFLjwv Rk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTk0MzQ4MzYxMi0yMDA0MjAwOT48 L1NQQU4+PFNQQU4gY2xhc3M9OTQzNDgzNjEyLTIwMDQyMDA5PjxGT05UIA0KZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIHNpemU9Mj4mbmJzcDtJIGFncmVlIHdpdGggeW91IHRoYXQncyB3b3J0aCBj bGFyaWZ5aW5nIA0KdGhpcyBzZWN0aW9uLiZuYnNwOzwvRk9OVD48L1NQQU4+PEJSPjxCUj48Rk9O VCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPkJlc3QgDQpSZWdhcmRzITwvRk9OVD4gPEJSPjxCUj48 Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPlhpbnF1YW4gWmhhbmc8L0ZPTlQ+IA0KPEJSPjxC Uj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjIwMDkvNC8xNTwvRk9OVD4gPEJSPjxCUj48 Rk9OVCANCmZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PEJSPjwvRElWPjwvRk9OVD48L0JPRFk+PC9I VE1MPg0K ------_=_NextPart_001_01C9C1B7.54E3C9DB-- From zhang.xinquan@zte.com.cn Mon Apr 20 18:23:59 2009 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 273CE28C120; Mon, 20 Apr 2009 18:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.014 X-Spam-Level: X-Spam-Status: No, score=-96.014 tagged_above=-999 required=5 tests=[AWL=0.979, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 bQrvinAS28xc; Mon, 20 Apr 2009 18:23:58 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 2336A28C0FC; Mon, 20 Apr 2009 18:23:56 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91103794527475; Tue, 21 Apr 2009 09:17:55 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 47274.4466930656; Tue, 21 Apr 2009 09:21:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n3L1P5uJ054344; Tue, 21 Apr 2009 09:25:06 +0800 (CST) (envelope-from zhang.xinquan@zte.com.cn) In-Reply-To: <8AA97249241F7148BE6D3D8B93D83F5A15831A94@ftrdmel2> To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.xinquan@zte.com.cn Date: Tue, 21 Apr 2009 09:22:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-04-21 09:25:06, Serialize complete at 2009-04-21 09:25:06 Content-Type: multipart/alternative; boundary="=_alternative 0007C46E4825759F_=" X-MAIL: mse1.zte.com.cn n3L1P5uJ054344 Cc: l2vpn@ietf.org, l2vpn-bounces@ietf.org, pwe3@ietf.org Subject: [PWE3] =?gb2312?b?tPC4tDogUkU6IENvbW1lbnRzIG9uIGRyYWZ0LWpvdW5h?= =?gb2312?b?eS1wd2UzLWxlYWYtaW5pdGlhdGVkLXAybXAtcHctMDE=?= 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, 21 Apr 2009 01:23:59 -0000 This is a multipart message in MIME format. --=_alternative 0007C46E4825759F_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgRnJlZGVyaWMsIA0KDQpUaGFua3MgZm9yIHlvdXIgY2xhcmlmaWNhdG9uLg0KDQpZb3UgaGF2 ZSB0d28gZHJhZnRzIGFib3V0IFAyTVAgUFcgc2lnbmFsaW5nLCBvbmUgaXMgbGVhZi1pbml0aWF0 ZWQgbW9kZSANCmFuZCB0aGUgb3RoZXIgaXMgc291cmNlLWluaXRpYXRlZCBtb2RlLiBJbiBteSBv cGluaW9uLCB5b3VyIG9yaWdpbmFsIA0KaW50ZW50aW9uIGlzIHRvIHByb3Bvc2UgbGVhZi1pbml0 aWF0ZWQgbW9kZSBhcyBhIHNvbHV0aW9uIGZvciBpbnRlci1kb21haW4gDQpzY2VuYXJpbywgYW5k IHNvdXJjZS1pbml0aWF0ZWQgbW9kZSBmb3IgaW50cmEtZG9tYWluIHNjZW5hcmlvLiBBbSBJIHJp Z2h0PyANCk9yIHlvdXIgaGF2ZSBvdGhlciBjb25zaWRlcmF0aW9ucz8NCg0KQmVzdCByZWdhcmRz IQ0KDQpYaW5xdWFuIFpoYW5nDQoNCjIwMDkvNC8yMQ0KDQoNCg0KDQoNCjxmcmVkZXJpYy5qb3Vu YXlAb3JhbmdlLWZ0Z3JvdXAuY29tPiANCuWPkeS7tuS6ujogIGwydnBuLWJvdW5jZXNAaWV0Zi5v cmcNCjIwMDktMDQtMjAgMjA6NTUNCg0K5pS25Lu25Lq6DQo8emhhbmcueGlucXVhbkB6dGUuY29t LmNuPg0K5oqE6YCBDQpsMnZwbkBpZXRmLm9yZywgbDJ2cG4tYm91bmNlc0BpZXRmLm9yZywgcHdl M0BpZXRmLm9yZw0K5Li76aKYDQpSRTogQ29tbWVudHMgb24gZHJhZnQtam91bmF5LXB3ZTMtbGVh Zi1pbml0aWF0ZWQtcDJtcC1wdy0wMQ0KDQoNCg0KDQoNCg0KSGkgWGlucXVhbiwNCiANClBsZWFz ZSBzZWUgbXkgYW5zd2VyIGlubGluZSBbRkpdDQogDQpCZXN0IFJlZ2FyZHMsDQpGcmVkDQoNCkRl IDogemhhbmcueGlucXVhbkB6dGUuY29tLmNuIFttYWlsdG86emhhbmcueGlucXVhbkB6dGUuY29t LmNuXSANCkVudm95w6kgOiBtZXJjcmVkaSAxNSBhdnJpbCAyMDA5IDA3OjUwDQrDgCA6IEpPVU5B WSBGcmVkZXJpYyBSRC1SRVNBLUxBTg0KQ2MgOiBsMnZwbkBpZXRmLm9yZzsgbDJ2cG4tYm91bmNl c0BpZXRmLm9yZw0KT2JqZXQgOiBDb21tZW50cyBvbiBkcmFmdC1qb3VuYXktcHdlMy1sZWFmLWlu aXRpYXRlZC1wMm1wLXB3LTAxDQoNCg0KSGksIEZyZWRlcmljLCANCg0KSSBoYXZlIHJlYWQgZHJh ZnQtam91bmF5LXB3ZTMtbGVhZi1pbml0aWF0ZWQtcDJtcC1wdy0wMSBhbmQgaGF2ZSBzb21lIA0K Y29tbWVudHMuIHBsZWFzZSBzZWUgYmVsb3c6IA0KDQox44CBc2VjdGlvbiA1LjQuIENvbmZpZ3Vy YXRpb24gDQogDQogICBBZnRlciBjb25maWd1cmluZyBvbiBlYWNoIFQtUEUgdGhlIGF0dGFjaGVk IEFJSXMsIGl0IGlzIGFzc3VtZWQgdGhhdCANCiAgIGFsbCB0aGUgUEVzIChJbmdyZXNzL0VncmVz cyBULVBFcyBhbmQgYWxsIFMtUEVzKSBtYWludGFpbiBhbiBBSUkgUFcgDQogICByb3V0aW5nIHRh YmxlIHdoaWNoIGdpdmVzIGZvciBlYWNoIEFJSSBhcyBlbnRyeSB0aGUgIm5leHQgaG9wIiB0byAN CiAgIHJlYWNoIHRoYXQgQUlJLiBUaGlzIEFJSSByb3V0aW5nIHRhYmxlIGNhbiBiZSBmaWxsZWQg bWFudWFsbHkgb3IgDQogICB1cGRhdGVkIGR5bmFtaWNhbGx5IGJ5IG1lYW5zIG9mIHNvbWUgZXh0 ZW5kZWQgcm91dGluZyBwcm90b2NvbCBsaWtlIA0KICAgcHJvcG9zZWQgaW4gW0RZTiBNUy1QV10u IFRoZSBjb25zdHJ1Y3Rpb24gb2YgdGhlIHRhYmxlIGlzIG91dCBvZiANCiAgIHNjb3BlIG9mIHRo ZSBwcmVzZW50IGRvY3VtZW50LiANCiANCiAgIEVhY2ggUEUgcmVsaWVzIG9uIGl0cyBBSUkgUFcg cm91dGluZyB0YWJsZSB0byBzZWxlY3QgdGhlIG5leHQgaG9wIFBFIA0KICAgKFMtUEUgb3IgVC1Q RSkgdG8gcmVhY2ggYSBnaXZlbiBBSUkuIA0KDQo+MSAgRG9lcyB0aGlzIEFJSSByb3V0aW5nIHRh YmxlIGluY2x1ZGUgYm90aCBUQUlJIGFuZCBTQUlJPyANCltGSl0gWWVzLCB0aGUgQUlJIHJvdXRp bmcgdGFibGUgZHluYW1pY2FsbHkgcG9wdWxhdGVkIChCR1AsIE9TUEYsIElTLUlTIG9yIA0KTERQ KSBzaG91bGQgbWFpbnRhaW4gYm90aC4gVGhlIEVncmVzcyBULVBFIGpvaW5zIHRoZSBQVyB0cmVl IGJ5IGluaXRpYXRpbmcgDQphIExhYmVsIE1hcCB3aG9zZSB0aGUgRkVDIGNvbnRhaW5zIHRoZSBT QUlJLCB0aGUgUFcgdHJlZSBzb3VyY2UuIEhlbmNlIA0KdXBvbiByZWNlaXB0IG9mIHRoZSBtZXNz YWdlIHRoZSBTLVBFIGRvZXMgYSBsb29rdXAgdG8gc2VsZWN0IHRoZSBOSCB0byANCnJlYWNoIHRo aXMgU0FJSS4gICAgICANCj4yICBJbiBTLVBFLCB0aGlzIEFJSSByb3V0aW5nIHRhYmxlIGluY2x1 ZGVzIGFsbCB0aGUgQUlJLCBvciBqdXN0IHBhcnQgb2YgDQp0aGUgQUlJKCBlLmcuIHdoaWNoIGFy ZSBpbiBpdHMgZG93c3RyZWFtKT8gDQogW0ZKXSB0aGUgQUlJIHJvdXRpbmcgdGFibGUgc2hvdWxk IGJlIHVzZWQgYWxzbyBmb3IgVlBXUyBvciBWUExTLCBzbyANCmJpZGlyZWN0aW9uYWwgUFcuIFRo ZXJlZm9yZSB0aGUgQUlJIHJvdXRpbmcgdGFibGUgbXVzdCByZWZsZWN0IGFsbCB0aGUgQUlJIA0K Y29uZmlndXJlZCBvbiBULVBFcy4gT2YgY291cnNlIGFncmVnYXRlIEFJSSBmb3JtYXQgKGkuZS4g dy9vIEFDSUQgaW5mbykgYXMgDQpkZWZpbmVkIGluIFtEWU4gTVMtUFddIG11c3QgYmUgdXNlZCB0 byBvcHRpbWl6ZSB0aGUgQUlJIHJvdXRpbmcgdGFibGUNCg0KMuOAgVNlY3Rpb24gNS43LiBVc2lu ZyBUQUlJIExlYWYgU3ViLVRMViANCiANCiAgIFNlY3Rpb24gVEJEIA0KIA0KICAgVGhlIFRBSUkg TGVhZiBzdWItVExWIE1BWSBiZSBvcHRpb25hbGx5IHVzZWQgd2hlbiBhIGxlYWYgam9pbnMgdGhl IFBXIA0KICAgdHJlZSB0byBhbm5vdW5jZSB0byB0aGUgc291cmNlIHRoYXQgaXQgaXMgcGFydCBm cm9tIHRoZSBQVyB0cmVlLiBJZiANCiAgIHRoaXMgb3B0aW9uIGlzIGNob3NlbiwgdGhlIEVncmVz cyBULVBFIGFkZHMgdG8gdGhlIEZFQyBFbGVtZW50IHRoaXMgDQogICBUQUlJIHN1Yi1UTFYgaW4g dGhlIExhYmVsIE1hcCBtZXNzYWdlLiBBcyBzb29uIGFzIGluIHRoZSBzb3VyY2UgDQogICBkaXJl Y3Rpb24gYSBMYWJlbCBNYXAgaXMgbm90IHJlcXVpcmVkIHNpbmNlIGZvciBpbnN0YW5jZSBhIFMt UEUgDQogICBhbHJlYWR5IG1haW50YWlucyBhIHN0YXRlIGZvciB0aGlzIE1TLVBXIHRyZWUsIHRo ZSBpbmZvcm1hdGlvbiANCiAgIHJlbGF0ZWQgdG8gdGhlIExlYWYgVEFJSXMgaXMgcmV0cmlldmVk IGZyb20gdGhlIFRBSUkgTGVhZiBzdWItVExWIGFuZCANCiAgIGlzIHByb3BhZ2F0ZWQgYnkgbWVh bnMgb2YgYSBMRFAgTm90aWZpY2F0aW9uIG1lc3NhZ2UgdXAgdG8gdGhlIA0KICAgY29ycmVzcG9u ZGluZyBJbmdyZXNzIFQtUEUuIA0KPiBJIGFtIG5vdCBzdXJlIGFib3V0IHRoZSBwcm9wYWdhdGlv biBvZiBUQUlJIExlYWYgc3ViLVRMVi4gSXMgaXQgc2VudCB0byANCmluZ3Jlc3MgVC1QRSBkaXJl Y3RseSwgb3IgdG8gdGhlIHVwc3RyZWFtIFMtUEUoaWYgdGhlcmUgZXhpc3RzIHN1Y2ggUy1QRSAN CmluIHRoZSB1cHN0cmVhbSBkaXJlY3Rpb24pPyAgDQpbRkpdIFRoZSBOb3RpZmljYXRpb24gbWVz c2FnZSBjYW4gbm90IGJlIGRpcmVjdGx5IHNlbnQgdG8gdGhlIEluZ3Jlc3MgVC1QRSANCmlmIHRo ZXJlIGlzIG5vdCBkaXJlY3QgVC1MRFAgc2Vzc2lvbiB0byByZWFjaCB0aGUgSW5ncmVzcyBULVBF LCBpLmUuIFMtUEUgDQppbiBiZXR3ZWVuLiBUaGF0J3MgdGhlIHJlYXNvbiB3aHkgdGhlIG1lc3Nh Z2Ugc2hvdWxkIGJlIHByb3BhZ2F0ZWQgaG9wIGJ5IA0KaG9wIChpLmUuIFMtUEUgYnkgUy1QRSkg dXAgdG8gdGhlIEluZ3Jlc3MgVC1QRS4NCiBJIGFncmVlIHdpdGggeW91IHRoYXQncyB3b3J0aCBj bGFyaWZ5aW5nIHRoaXMgc2VjdGlvbi4gDQoNCkJlc3QgUmVnYXJkcyEgDQoNClhpbnF1YW4gWmhh bmcgDQoNCjIwMDkvNC8xNSANCg0KDQoNCg== --=_alternative 0007C46E4825759F_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEZyZWRlcmljLDwvZm9udD48 Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHlv dXIgY2xhcmlmaWNhdG9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+WW91IGhhdmUgdHdvIGRyYWZ0cyBhYm91dCBQMk1QIFBXIHNpZ25hbGluZywNCm9u ZSBpcyBsZWFmLWluaXRpYXRlZCBtb2RlIGFuZCB0aGUgb3RoZXIgaXMgc291cmNlLWluaXRpYXRl ZCBtb2RlLiBJbiBteQ0Kb3BpbmlvbiwgeW91ciBvcmlnaW5hbCBpbnRlbnRpb24gaXMgdG8gcHJv cG9zZSBsZWFmLWluaXRpYXRlZCBtb2RlIGFzIGENCnNvbHV0aW9uIGZvciBpbnRlci1kb21haW4g c2NlbmFyaW8sIGFuZCBzb3VyY2UtaW5pdGlhdGVkIG1vZGUgZm9yIGludHJhLWRvbWFpbg0Kc2Nl bmFyaW8uIEFtIEkgcmlnaHQ/IE9yIHlvdXIgaGF2ZSBvdGhlciBjb25zaWRlcmF0aW9ucz88L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJlc3QgcmVnYXJk cyE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlhpbnF1 YW4gWmhhbmc8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PjIwMDkvNC8yMTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj48Yj4mbHQ7ZnJlZGVyaWMuam91bmF5QG9yYW5nZS1mdGdyb3VwLmNv bSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPuWP keS7tuS6ujogJm5ic3A7bDJ2cG4tYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA0LTIwIDIwOjU1PC9mb250Pg0KPHRkIHdpZHRo PTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7mlLbku7bkuro8L2ZvbnQ+ PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDt6aGFuZy54aW5x dWFuQHp0ZS5jb20uY24mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7mioTpgIE8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmwydnBuQGlldGYub3JnLCBs MnZwbi1ib3VuY2VzQGlldGYub3JnLA0KcHdlM0BpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+5Li76aKYPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5SRTogQ29tbWVudHMgb24gZHJhZnQtam91bmF5LXB3ZTMtbGVhZi1pbml0aWF0ZWQtcDJtcC1w dy0wMTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5IaSBYaW5xdWFuLDwvZm9udD4NCjxicj48Zm9udCBz aXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFy aWFsIj5QbGVhc2Ugc2VlIG15IGFuc3dlciBpbmxpbmUgW0ZKXTwvZm9udD4NCjxicj48Zm9udCBz aXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFy aWFsIj5CZXN0IFJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh Y2U9IkFyaWFsIj5GcmVkPC9mb250Pg0KPGJyPg0KPGJyPg0KPGhyPjxmb250IHNpemU9MiBmYWNl PSJUYWhvbWEiPjxiPkRlIDo8L2I+IHpoYW5nLnhpbnF1YW5AenRlLmNvbS5jbiBbbWFpbHRvOnpo YW5nLnhpbnF1YW5AenRlLmNvbS5jbl0NCjxiPjxicj4NCkVudm95w6kgOjwvYj4gbWVyY3JlZGkg MTUgYXZyaWwgMjAwOSAwNzo1MDxiPjxicj4NCsOAIDo8L2I+IEpPVU5BWSBGcmVkZXJpYyBSRC1S RVNBLUxBTjxiPjxicj4NCkNjIDo8L2I+IGwydnBuQGlldGYub3JnOyBsMnZwbi1ib3VuY2VzQGll dGYub3JnPGI+PGJyPg0KT2JqZXQgOjwvYj4gQ29tbWVudHMgb24gZHJhZnQtam91bmF5LXB3ZTMt bGVhZi1pbml0aWF0ZWQtcDJtcC1wdy0wMTwvZm9udD48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpIaSwgRnJlZGVyaWMs PC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQpJIGhhdmUgcmVhZCBkcmFmdC1qb3VuYXktcHdlMy1sZWFmLWluaXRpYXRl ZC1wMm1wLXB3LTAxIGFuZCBoYXZlIHNvbWUgY29tbWVudHMuDQpwbGVhc2Ugc2VlIGJlbG93Ojwv Zm9udD48Zm9udCBzaXplPTM+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+PGJyPg0KMeOAgXNlY3Rpb24gNS40LiBDb25maWd1cmF0aW9uIDxicj4NCiAmbmJzcDsg Jm5ic3A7PGJyPg0KICZuYnNwOyBBZnRlciBjb25maWd1cmluZyBvbiBlYWNoIFQtUEUgdGhlIGF0 dGFjaGVkIEFJSXMsIGl0IGlzIGFzc3VtZWQNCnRoYXQgPGJyPg0KICZuYnNwOyBhbGwgdGhlIFBF cyAoSW5ncmVzcy9FZ3Jlc3MgVC1QRXMgYW5kIGFsbCBTLVBFcykgbWFpbnRhaW4gYW4gQUlJDQpQ VyA8YnI+DQogJm5ic3A7IHJvdXRpbmcgdGFibGUgd2hpY2ggZ2l2ZXMgZm9yIGVhY2ggQUlJIGFz IGVudHJ5IHRoZSAmcXVvdDtuZXh0DQpob3AmcXVvdDsgdG8gPGJyPg0KICZuYnNwOyByZWFjaCB0 aGF0IEFJSS4gVGhpcyBBSUkgcm91dGluZyB0YWJsZSBjYW4gYmUgZmlsbGVkIG1hbnVhbGx5IG9y DQo8YnI+DQogJm5ic3A7IHVwZGF0ZWQgZHluYW1pY2FsbHkgYnkgbWVhbnMgb2Ygc29tZSBleHRl bmRlZCByb3V0aW5nIHByb3RvY29sDQpsaWtlIDxicj4NCiAmbmJzcDsgcHJvcG9zZWQgaW4gW0RZ TiBNUy1QV10uIFRoZSBjb25zdHJ1Y3Rpb24gb2YgdGhlIHRhYmxlIGlzIG91dCBvZg0KPGJyPg0K ICZuYnNwOyBzY29wZSBvZiB0aGUgcHJlc2VudCBkb2N1bWVudC4gPGJyPg0KICZuYnNwOyAmbmJz cDs8YnI+DQogJm5ic3A7IEVhY2ggUEUgcmVsaWVzIG9uIGl0cyBBSUkgUFcgcm91dGluZyB0YWJs ZSB0byBzZWxlY3QgdGhlIG5leHQgaG9wDQpQRSA8YnI+DQogJm5ic3A7IChTLVBFIG9yIFQtUEUp IHRvIHJlYWNoIGEgZ2l2ZW4gQUlJLiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KJmd0OzEgJm5ic3A7RG9lcyB0aGlz IEFJSSByb3V0aW5nIHRhYmxlIGluY2x1ZGUgYm90aCBUQUlJIGFuZCBTQUlJPzwvZm9udD48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPltGSl0gWWVzLCB0aGUgQUlJIHJvdXRpbmcgdGFi bGUNCmR5bmFtaWNhbGx5IHBvcHVsYXRlZCAoQkdQLCBPU1BGLCBJUy1JUyBvciBMRFApIHNob3Vs ZCBtYWludGFpbiBib3RoLiBUaGUNCkVncmVzcyBULVBFIGpvaW5zIHRoZSBQVyB0cmVlIGJ5IGlu aXRpYXRpbmcgYSBMYWJlbCBNYXAgd2hvc2UgdGhlIEZFQyBjb250YWlucw0KdGhlIFNBSUksIHRo ZSBQVyB0cmVlIHNvdXJjZS4gSGVuY2UgdXBvbiByZWNlaXB0IG9mIHRoZSBtZXNzYWdlIHRoZSBT LVBFDQpkb2VzIGEgbG9va3VwIHRvIHNlbGVjdCB0aGUgTkggdG8gcmVhY2ggdGhpcyBTQUlJLiAm bmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9u dD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQomZ3Q7MiAmbmJzcDtJbiBTLVBFLCB0aGlzIEFJSSByb3V0aW5nIHRhYmxlIGluY2x1 ZGVzIGFsbCB0aGUgQUlJLCBvciBqdXN0DQpwYXJ0IG9mIHRoZSBBSUkoIGUuZy4gd2hpY2ggYXJl IGluIGl0cyBkb3dzdHJlYW0pPzwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjxicj4NCiBbRkpdIHRoZSBBSUkgcm91dGluZyB0 YWJsZSBzaG91bGQgYmUgdXNlZCBhbHNvIGZvciBWUFdTIG9yIFZQTFMsIHNvIGJpZGlyZWN0aW9u YWwNClBXLiBUaGVyZWZvcmUgdGhlIEFJSSByb3V0aW5nIHRhYmxlIG11c3QgcmVmbGVjdCBhbGwg dGhlIEFJSSBjb25maWd1cmVkDQpvbiBULVBFcy4gT2YgY291cnNlIGFncmVnYXRlIEFJSSBmb3Jt YXQgKGkuZS4gdy9vIEFDSUQgaW5mbykgYXMgZGVmaW5lZA0KaW4gW0RZTiBNUy1QV10gbXVzdCBi ZSB1c2VkIHRvIG9wdGltaXplIHRoZSBBSUkgcm91dGluZyB0YWJsZTwvZm9udD48Zm9udCBzaXpl PTM+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQoy44CB U2VjdGlvbiA1LjcuIFVzaW5nIFRBSUkgTGVhZiBTdWItVExWIDxicj4NCiAmbmJzcDsgJm5ic3A7 PGJyPg0KICZuYnNwOyBTZWN0aW9uIFRCRCA8YnI+DQogJm5ic3A7ICZuYnNwOzxicj4NCiAmbmJz cDsgVGhlIFRBSUkgTGVhZiBzdWItVExWIE1BWSBiZSBvcHRpb25hbGx5IHVzZWQgd2hlbiBhIGxl YWYgam9pbnMNCnRoZSBQVyA8YnI+DQogJm5ic3A7IHRyZWUgdG8gYW5ub3VuY2UgdG8gdGhlIHNv dXJjZSB0aGF0IGl0IGlzIHBhcnQgZnJvbSB0aGUgUFcgdHJlZS4NCklmIDxicj4NCiAmbmJzcDsg dGhpcyBvcHRpb24gaXMgY2hvc2VuLCB0aGUgRWdyZXNzIFQtUEUgYWRkcyB0byB0aGUgRkVDIEVs ZW1lbnQNCnRoaXMgPGJyPg0KICZuYnNwOyBUQUlJIHN1Yi1UTFYgaW4gdGhlIExhYmVsIE1hcCBt ZXNzYWdlLiBBcyBzb29uIGFzIGluIHRoZSBzb3VyY2UNCjxicj4NCiAmbmJzcDsgZGlyZWN0aW9u IGEgTGFiZWwgTWFwIGlzIG5vdCByZXF1aXJlZCBzaW5jZSBmb3IgaW5zdGFuY2UgYSBTLVBFDQo8 YnI+DQogJm5ic3A7IGFscmVhZHkgbWFpbnRhaW5zIGEgc3RhdGUgZm9yIHRoaXMgTVMtUFcgdHJl ZSwgdGhlIGluZm9ybWF0aW9uDQo8YnI+DQogJm5ic3A7IHJlbGF0ZWQgdG8gdGhlIExlYWYgVEFJ SXMgaXMgcmV0cmlldmVkIGZyb20gdGhlIFRBSUkgTGVhZiBzdWItVExWDQphbmQgPGJyPg0KICZu YnNwOyBpcyBwcm9wYWdhdGVkIGJ5IG1lYW5zIG9mIGEgTERQIE5vdGlmaWNhdGlvbiBtZXNzYWdl IHVwIHRvIHRoZQ0KPGJyPg0KICZuYnNwOyBjb3JyZXNwb25kaW5nIEluZ3Jlc3MgVC1QRS4gJm5i c3A7IDxicj4NCiZndDsgSSBhbSBub3Qgc3VyZSBhYm91dCB0aGUgcHJvcGFnYXRpb24gb2YgVEFJ SSBMZWFmIHN1Yi1UTFYuIElzIGl0IHNlbnQNCnRvIGluZ3Jlc3MgVC1QRSBkaXJlY3RseSwgb3Ig dG8gdGhlIHVwc3RyZWFtIFMtUEUoaWYgdGhlcmUgZXhpc3RzIHN1Y2gNClMtUEUgaW4gdGhlIHVw c3RyZWFtIGRpcmVjdGlvbik/PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9 MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPltGSl0gVGhlIE5vdGlmaWNhdGlvbiBtZXNzYWdlDQpj YW4gbm90IGJlIGRpcmVjdGx5IHNlbnQgdG8gdGhlIEluZ3Jlc3MgVC1QRSBpZiB0aGVyZSBpcyBu b3QgZGlyZWN0IFQtTERQDQpzZXNzaW9uIHRvIHJlYWNoIHRoZSBJbmdyZXNzIFQtUEUsIGkuZS4g Uy1QRSBpbiBiZXR3ZWVuLiBUaGF0J3MgdGhlIHJlYXNvbg0Kd2h5IHRoZSBtZXNzYWdlIHNob3Vs ZCBiZSBwcm9wYWdhdGVkIGhvcCBieSBob3AgKGkuZS4gUy1QRSBieSBTLVBFKTwvZm9udD48Zm9u dCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPnVw IHRvIHRoZSBJbmdyZXNzIFQtUEUuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVl IGZhY2U9IkFyaWFsIj4mbmJzcDtJIGFncmVlIHdpdGggeW91IHRoYXQncw0Kd29ydGggY2xhcmlm eWluZyB0aGlzIHNlY3Rpb24uIDwvZm9udD48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpCZXN0IFJlZ2FyZHMhPC9mb250Pjxmb250 IHNpemU9Mz4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQpYaW5xdWFuIFpoYW5nPC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQoyMDA5LzQvMTU8L2ZvbnQ+PGZvbnQgc2l6ZT0z PiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9u dD4NCjxicj4NCg== --=_alternative 0007C46E4825759F_=-- From frederic.jounay@orange-ftgroup.com Tue Apr 21 07:53:24 2009 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 7D1F73A6D6E; Tue, 21 Apr 2009 07:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 s7hOPY1Q5qee; Tue, 21 Apr 2009 07:53:23 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 0C7983A7037; Tue, 21 Apr 2009 07:53:21 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 16:54:37 +0200 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_01C9C291.16F066BE" Date: Tue, 21 Apr 2009 16:54:35 +0200 Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A15832458@ftrdmel2> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-jounay-pwe3-leaf-initiated-p2mp-pw-01 Thread-Index: AcnCIAmXsfVwxAZ+TcOorrkpre7AlQAcMANw References: <8AA97249241F7148BE6D3D8B93D83F5A15831A94@ftrdmel2> From: To: X-OriginalArrivalTime: 21 Apr 2009 14:54:37.0268 (UTC) FILETIME=[173CD940:01C9C291] Cc: l2vpn@ietf.org, l2vpn-bounces@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] Comments on draft-jounay-pwe3-leaf-initiated-p2mp-pw-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: Tue, 21 Apr 2009 14:53:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C291.16F066BE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWGlucXVhbiwNCiANCiJJbiBteSBvcGluaW9uLCB5b3VyIG9yaWdpbmFsIGludGVudGlvbiBp cyB0byBwcm9wb3NlIGxlYWYtaW5pdGlhdGVkIG1vZGUgYXMgYSBzb2x1dGlvbiBmb3IgaW50ZXIt ZG9tYWluIHNjZW5hcmlvLCBhbmQgc291cmNlLWluaXRpYXRlZCBtb2RlIGZvciBpbnRyYS1kb21h aW4gc2NlbmFyaW8uIEFtIEkgcmlnaHQ/IiANCiANCm5vdCByZWFsbHksIGFjdHVhbGx5IGJvdGgg cHJvY2VkdXJlcyAobGVhZiBvciBzb3VyY2UgaW5pdGlhdGVkKSAgYXJlIG5vdCBsaW1pdGVkIGlu IHRoZWlyIG9wZXJhdGluZyBwcmluY2lwbGVzIGFuZCBhcyBzdWNoIGNvdWxkIGJlIHVzZWQgIHRv IGNvdmVyIFNTLVBXIGFuZCBNUy1QVyBjb25maWd1cmF0aW9uLiAgDQpGb3IgdGhlIHN0YW5kYXJk aXphdGlvbiB3b3JrIHdlIHByb3Bvc2UgdG8gZm9jdXMgZmlyc3Qgb24gUDJNUCBTUy1QVyAgYXMg aXQgaXMgdGhlIHNpbXBsZXN0IGNvbmZpZ3VyYXRpb24sIHRvIGFncmVlIG9uIHRoZSByZXF1aXJl ZCBuZXcgIGJ1aWxkaW5nIGJsb2NrcyA6IEZFQyBlbGVtZW50LCBzaWduYWxpbmcgcHJvY2VkdXJl cyBldGMuLi4gICANClRoZSBwYXJ0IHJlbGF0ZWQgdG8gUDJNUCBTUy1QVyBzZXR1cCBpbiB0aGUg bGVhZi1pbml0aWF0ZWQgZHJhZnQgYW5kIHRoZSBwYXJ0IHJlbGF0ZWQgdG8gUDJNUCBNUy1QVyBz ZXR1cCBpbiB0aGUgc291cmNlLWluaXRpYXRlZCBkcmFmdCBzaG91bGQgYmUgYWRkZWQgYXNhcCBv ciBjb25zaWRlcmVkIGluIGEgc2VwYXJhdGUgZG9jdW1lbnQuDQogDQpSZWdhcmRpbmcgdGhlaXIg bmV0d29yayBhcHBsaWNhYmlsaXR5IHRoZSBjaG9pY2UgYmV0d2VlbiBib3RoIGFwcHJvYWNoZXMg d2lsbCBoYXZlIHRvIGJlIG1hZGUgb24gYSBjYXNlIGJ5IGNhc2UgYmFzaXMsIGRyaXZlbiBieSBh cmNoaXRlY3R1cmFsIGFuZCBvcGVyYXRpb25hbCBjb25zdHJhaW50cy4gRm9yIHRoZSBtb21lbnQg d2UgZmVsdCB0aGUgbmVlZCB0byBpbnZlc3RpZ2F0ZSBib3RoIHNvbHV0aW9ucyBpbiBwYXJhbGxl bC4NCiANCkRvIHlvdSBoYXZlIGFueSBjb21tZW50IG9uIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRo ZSB0d28gYXBwcm9hY2hlcyA/ICBPciBhbnkgc3BlY2lmaWMgcmVxdWlyZW1lbnQgdGhhdCB3b3Vs ZCBuZWVkIHRvIGJlIGluY2x1ZGVkIGluIHRoZSByZXF1aXJlbWVudHMgZHJhZnQgb24gUDJNUCBQ VyA/DQogDQpCZXN0IFJlZ2FyZHMsDQogDQpGcmVkDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCkRlIDogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJv dW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgemhhbmcueGlucXVhbkB6dGUuY29tLmNuDQpF bnZvecOpIDogbWFyZGkgMjEgYXZyaWwgMjAwOSAwMzoyMw0Kw4AgOiBKT1VOQVkgRnJlZGVyaWMg UkQtUkVTQS1MQU4NCkNjIDogbDJ2cG5AaWV0Zi5vcmc7IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmc7 IHB3ZTNAaWV0Zi5vcmcNCk9iamV0IDog562U5aSNOiBSRTogQ29tbWVudHMgb24gZHJhZnQtam91 bmF5LXB3ZTMtbGVhZi1pbml0aWF0ZWQtcDJtcC1wdy0wMQ0KDQoNCg0KSGkgRnJlZGVyaWMsIA0K DQpUaGFua3MgZm9yIHlvdXIgY2xhcmlmaWNhdG9uLiANCg0KWW91IGhhdmUgdHdvIGRyYWZ0cyBh Ym91dCBQMk1QIFBXIHNpZ25hbGluZywgb25lIGlzIGxlYWYtaW5pdGlhdGVkIG1vZGUgYW5kIHRo ZSBvdGhlciBpcyBzb3VyY2UtaW5pdGlhdGVkIG1vZGUuIEluIG15IG9waW5pb24sIHlvdXIgb3Jp Z2luYWwgaW50ZW50aW9uIGlzIHRvIHByb3Bvc2UgbGVhZi1pbml0aWF0ZWQgbW9kZSBhcyBhIHNv bHV0aW9uIGZvciBpbnRlci1kb21haW4gc2NlbmFyaW8sIGFuZCBzb3VyY2UtaW5pdGlhdGVkIG1v ZGUgZm9yIGludHJhLWRvbWFpbiBzY2VuYXJpby4gQW0gSSByaWdodD8gT3IgeW91ciBoYXZlIG90 aGVyIGNvbnNpZGVyYXRpb25zPyANCg0KQmVzdCByZWdhcmRzISANCg0KWGlucXVhbiBaaGFuZyAN Cg0KMjAwOS80LzIxIA0KDQoNCg0KDQoNCjxmcmVkZXJpYy5qb3VuYXlAb3JhbmdlLWZ0Z3JvdXAu Y29tPiANCuWPkeS7tuS6ujogIGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgDQoNCjIwMDktMDQtMjAg MjA6NTUgDQoNCuaUtuS7tuS6ug0KPHpoYW5nLnhpbnF1YW5AenRlLmNvbS5jbj4gDQrmioTpgIEN CmwydnBuQGlldGYub3JnLCBsMnZwbi1ib3VuY2VzQGlldGYub3JnLCBwd2UzQGlldGYub3JnIA0K 5Li76aKYDQpSRTogQ29tbWVudHMgb24gZHJhZnQtam91bmF5LXB3ZTMtbGVhZi1pbml0aWF0ZWQt cDJtcC1wdy0wMQ0KDQoJDQoNCg0KDQoNCkhpIFhpbnF1YW4sIA0KICANClBsZWFzZSBzZWUgbXkg YW5zd2VyIGlubGluZSBbRkpdIA0KICANCkJlc3QgUmVnYXJkcywgDQpGcmVkIA0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRlIDogemhhbmcueGlucXVhbkB6dGUuY29t LmNuIFttYWlsdG86emhhbmcueGlucXVhbkB6dGUuY29tLmNuXSANCkVudm95w6kgOiBtZXJjcmVk aSAxNSBhdnJpbCAyMDA5IDA3OjUwDQrDgCA6IEpPVU5BWSBGcmVkZXJpYyBSRC1SRVNBLUxBTg0K Q2MgOiBsMnZwbkBpZXRmLm9yZzsgbDJ2cG4tYm91bmNlc0BpZXRmLm9yZw0KT2JqZXQgOiBDb21t ZW50cyBvbiBkcmFmdC1qb3VuYXktcHdlMy1sZWFmLWluaXRpYXRlZC1wMm1wLXB3LTAxDQoNCg0K SGksIEZyZWRlcmljLCANCg0KSSBoYXZlIHJlYWQgZHJhZnQtam91bmF5LXB3ZTMtbGVhZi1pbml0 aWF0ZWQtcDJtcC1wdy0wMSBhbmQgaGF2ZSBzb21lIGNvbW1lbnRzLiBwbGVhc2Ugc2VlIGJlbG93 OiANCg0KMeOAgXNlY3Rpb24gNS40LiBDb25maWd1cmF0aW9uIA0KICAgDQogIEFmdGVyIGNvbmZp Z3VyaW5nIG9uIGVhY2ggVC1QRSB0aGUgYXR0YWNoZWQgQUlJcywgaXQgaXMgYXNzdW1lZCB0aGF0 IA0KICBhbGwgdGhlIFBFcyAoSW5ncmVzcy9FZ3Jlc3MgVC1QRXMgYW5kIGFsbCBTLVBFcykgbWFp bnRhaW4gYW4gQUlJIFBXIA0KICByb3V0aW5nIHRhYmxlIHdoaWNoIGdpdmVzIGZvciBlYWNoIEFJ SSBhcyBlbnRyeSB0aGUgIm5leHQgaG9wIiB0byANCiAgcmVhY2ggdGhhdCBBSUkuIFRoaXMgQUlJ IHJvdXRpbmcgdGFibGUgY2FuIGJlIGZpbGxlZCBtYW51YWxseSBvciANCiAgdXBkYXRlZCBkeW5h bWljYWxseSBieSBtZWFucyBvZiBzb21lIGV4dGVuZGVkIHJvdXRpbmcgcHJvdG9jb2wgbGlrZSAN CiAgcHJvcG9zZWQgaW4gW0RZTiBNUy1QV10uIFRoZSBjb25zdHJ1Y3Rpb24gb2YgdGhlIHRhYmxl IGlzIG91dCBvZiANCiAgc2NvcGUgb2YgdGhlIHByZXNlbnQgZG9jdW1lbnQuIA0KICAgDQogIEVh Y2ggUEUgcmVsaWVzIG9uIGl0cyBBSUkgUFcgcm91dGluZyB0YWJsZSB0byBzZWxlY3QgdGhlIG5l eHQgaG9wIFBFIA0KICAoUy1QRSBvciBULVBFKSB0byByZWFjaCBhIGdpdmVuIEFJSS4gDQoNCj4x ICBEb2VzIHRoaXMgQUlJIHJvdXRpbmcgdGFibGUgaW5jbHVkZSBib3RoIFRBSUkgYW5kIFNBSUk/ IA0KW0ZKXSBZZXMsIHRoZSBBSUkgcm91dGluZyB0YWJsZSBkeW5hbWljYWxseSBwb3B1bGF0ZWQg KEJHUCwgT1NQRiwgSVMtSVMgb3IgTERQKSBzaG91bGQgbWFpbnRhaW4gYm90aC4gVGhlIEVncmVz cyBULVBFIGpvaW5zIHRoZSBQVyB0cmVlIGJ5IGluaXRpYXRpbmcgYSBMYWJlbCBNYXAgd2hvc2Ug dGhlIEZFQyBjb250YWlucyB0aGUgU0FJSSwgdGhlIFBXIHRyZWUgc291cmNlLiBIZW5jZSB1cG9u IHJlY2VpcHQgb2YgdGhlIG1lc3NhZ2UgdGhlIFMtUEUgZG9lcyBhIGxvb2t1cCB0byBzZWxlY3Qg dGhlIE5IIHRvIHJlYWNoIHRoaXMgU0FJSS4gICAgICANCj4yICBJbiBTLVBFLCB0aGlzIEFJSSBy b3V0aW5nIHRhYmxlIGluY2x1ZGVzIGFsbCB0aGUgQUlJLCBvciBqdXN0IHBhcnQgb2YgdGhlIEFJ SSggZS5nLiB3aGljaCBhcmUgaW4gaXRzIGRvd3N0cmVhbSk/IA0KW0ZKXSB0aGUgQUlJIHJvdXRp bmcgdGFibGUgc2hvdWxkIGJlIHVzZWQgYWxzbyBmb3IgVlBXUyBvciBWUExTLCBzbyBiaWRpcmVj dGlvbmFsIFBXLiBUaGVyZWZvcmUgdGhlIEFJSSByb3V0aW5nIHRhYmxlIG11c3QgcmVmbGVjdCBh bGwgdGhlIEFJSSBjb25maWd1cmVkIG9uIFQtUEVzLiBPZiBjb3Vyc2UgYWdyZWdhdGUgQUlJIGZv cm1hdCAoaS5lLiB3L28gQUNJRCBpbmZvKSBhcyBkZWZpbmVkIGluIFtEWU4gTVMtUFddIG11c3Qg YmUgdXNlZCB0byBvcHRpbWl6ZSB0aGUgQUlJIHJvdXRpbmcgdGFibGUNCg0KMuOAgVNlY3Rpb24g NS43LiBVc2luZyBUQUlJIExlYWYgU3ViLVRMViANCiAgIA0KICBTZWN0aW9uIFRCRCANCiAgIA0K ICBUaGUgVEFJSSBMZWFmIHN1Yi1UTFYgTUFZIGJlIG9wdGlvbmFsbHkgdXNlZCB3aGVuIGEgbGVh ZiBqb2lucyB0aGUgUFcgDQogIHRyZWUgdG8gYW5ub3VuY2UgdG8gdGhlIHNvdXJjZSB0aGF0IGl0 IGlzIHBhcnQgZnJvbSB0aGUgUFcgdHJlZS4gSWYgDQogIHRoaXMgb3B0aW9uIGlzIGNob3Nlbiwg dGhlIEVncmVzcyBULVBFIGFkZHMgdG8gdGhlIEZFQyBFbGVtZW50IHRoaXMgDQogIFRBSUkgc3Vi LVRMViBpbiB0aGUgTGFiZWwgTWFwIG1lc3NhZ2UuIEFzIHNvb24gYXMgaW4gdGhlIHNvdXJjZSAN CiAgZGlyZWN0aW9uIGEgTGFiZWwgTWFwIGlzIG5vdCByZXF1aXJlZCBzaW5jZSBmb3IgaW5zdGFu Y2UgYSBTLVBFIA0KICBhbHJlYWR5IG1haW50YWlucyBhIHN0YXRlIGZvciB0aGlzIE1TLVBXIHRy ZWUsIHRoZSBpbmZvcm1hdGlvbiANCiAgcmVsYXRlZCB0byB0aGUgTGVhZiBUQUlJcyBpcyByZXRy aWV2ZWQgZnJvbSB0aGUgVEFJSSBMZWFmIHN1Yi1UTFYgYW5kIA0KICBpcyBwcm9wYWdhdGVkIGJ5 IG1lYW5zIG9mIGEgTERQIE5vdGlmaWNhdGlvbiBtZXNzYWdlIHVwIHRvIHRoZSANCiAgY29ycmVz cG9uZGluZyBJbmdyZXNzIFQtUEUuICAgDQo+IEkgYW0gbm90IHN1cmUgYWJvdXQgdGhlIHByb3Bh Z2F0aW9uIG9mIFRBSUkgTGVhZiBzdWItVExWLiBJcyBpdCBzZW50IHRvIGluZ3Jlc3MgVC1QRSBk aXJlY3RseSwgb3IgdG8gdGhlIHVwc3RyZWFtIFMtUEUoaWYgdGhlcmUgZXhpc3RzIHN1Y2ggUy1Q RSBpbiB0aGUgdXBzdHJlYW0gZGlyZWN0aW9uKT8gICANCltGSl0gVGhlIE5vdGlmaWNhdGlvbiBt ZXNzYWdlIGNhbiBub3QgYmUgZGlyZWN0bHkgc2VudCB0byB0aGUgSW5ncmVzcyBULVBFIGlmIHRo ZXJlIGlzIG5vdCBkaXJlY3QgVC1MRFAgc2Vzc2lvbiB0byByZWFjaCB0aGUgSW5ncmVzcyBULVBF LCBpLmUuIFMtUEUgaW4gYmV0d2Vlbi4gVGhhdCdzIHRoZSByZWFzb24gd2h5IHRoZSBtZXNzYWdl IHNob3VsZCBiZSBwcm9wYWdhdGVkIGhvcCBieSBob3AgKGkuZS4gUy1QRSBieSBTLVBFKSB1cCB0 byB0aGUgSW5ncmVzcyBULVBFLiANCiBJIGFncmVlIHdpdGggeW91IHRoYXQncyB3b3J0aCBjbGFy aWZ5aW5nIHRoaXMgc2VjdGlvbi4gDQoNCkJlc3QgUmVnYXJkcyEgDQoNClhpbnF1YW4gWmhhbmcg DQoNCjIwMDkvNC8xNSANCg0KDQoNCg== ------_=_NextPart_001_01C9C291.16F066BE Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzUyNyIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTA3MTI0 NTYxMS0yMTA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPkhpIFhpbnF1YW4sPC9GT05U PjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTA3MTI0 NTYxMS0yMTA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5i c3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0wNzEyNDU2MTEt MjEwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj4iSW4gbXkgb3BpbmlvbiwgeW91ciBv cmlnaW5hbCBpbnRlbnRpb24gaXMgdG8gcHJvcG9zZSBsZWFmLWluaXRpYXRlZCBtb2RlIA0KYXMg YSBzb2x1dGlvbiBmb3IgaW50ZXItZG9tYWluIHNjZW5hcmlvLCBhbmQgc291cmNlLWluaXRpYXRl ZCBtb2RlIGZvciANCmludHJhLWRvbWFpbiBzY2VuYXJpby4gQW0gSSByaWdodD8iIDwvRk9OVD48 L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0wNzEyNDU2 MTEtMjEwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNw OzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MDcxMjQ1NjExLTIx MDQyMDA5PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+bm90IHJlYWxseSwgYWN0dWFsbHkgYm90 aCBwcm9jZWR1cmVzIChsZWFmIG9yIHNvdXJjZSANCmluaXRpYXRlZCkmbmJzcDs8U1BBTiBjbGFz cz0xMTMxMTQxMTItMjEwNDIwMDk+Jm5ic3A7YXJlIG5vdCBsaW1pdGVkIGluIHRoZWlyIA0Kb3Bl cmF0aW5nIHByaW5jaXBsZXMgYW5kIGFzIHN1Y2ggY291bGQgYmUgdXNlZCAmbmJzcDs8L1NQQU4+ dG8gY292ZXImbmJzcDtTUy1QVyANCmFuZCBNUy1QVyBjb25maWd1cmF0aW9uLiZuYnNwOzxTUEFO IA0KY2xhc3M9MTEzMTE0MTEyLTIxMDQyMDA5PiZuYnNwOzwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwv RElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MDcxMjQ1NjExLTIxMDQy MDA5Pg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MDcxMjQ1NjExLTIxMDQy MDA5PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgDQpzaXplPTI+PFNQQU4gY2xhc3M9MTEzMTE0MTEy LTIxMDQyMDA5PkZvciB0aGUgc3RhbmRhcmRpemF0aW9uIHdvcmsgDQp3PC9TUEFOPmUmbmJzcDtw cm9wb3NlIHRvIGZvY3VzIGZpcnN0IG9uIFAyTVAgU1MtUFc8U1BBTiANCmNsYXNzPTExMzExNDEx Mi0yMTA0MjAwOT4mbmJzcDsgYXMgaXQgaXMgdGhlIHNpbXBsZXN0IGNvbmZpZ3VyYXRpb248L1NQ QU4+LCB0byANCmFncmVlIG9uPFNQQU4gY2xhc3M9MTEzMTE0MTEyLTIxMDQyMDA5PiZuYnNwO3Ro ZSByZXF1aXJlZCA8L1NQQU4+bmV3Jm5ic3A7PFNQQU4gDQpjbGFzcz0xMTMxMTQxMTItMjEwNDIw MDk+Jm5ic3A7YnVpbGRpbmcgYmxvY2tzIDombmJzcDs8L1NQQU4+RkVDIGVsZW1lbnQsIA0Kc2ln bmFsaW5nIHByb2NlZHVyZXMgZXRjLi4uPFNQQU4gY2xhc3M9MTEzMTE0MTEyLTIxMDQyMDA5PiZu YnNwOyANCiZuYnNwOzwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L0RJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj5UaGUgcGFydCByZWxhdGVkIA0KdG8gUDJNUCBTUy1QVyBzZXR1cCZuYnNw O2luIHRoZSZuYnNwO2xlYWYtaW5pdGlhdGVkIGRyYWZ0IGFuZCB0aGUgcGFydCByZWxhdGVkIA0K dG8mbmJzcDtQMk1QIE1TLVBXIHNldHVwIGluIHRoZSBzb3VyY2UtaW5pdGlhdGVkIGRyYWZ0IHNo b3VsZCBiZSBhZGRlZCBhc2FwIA0Kb3ImbmJzcDtjb25zaWRlcmVkIGluIGEgc2VwYXJhdGUgZG9j dW1lbnQuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFO IGNsYXNzPTA3MTI0NTYxMS0yMTA0MjAwOT48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPjwvRk9O VD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFz cz0wNzEyNDU2MTEtMjEwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCANCnNpemU9Mj48U1BB TiBjbGFzcz0xMTMxMTQxMTItMjEwNDIwMDk+UmVnYXJkaW5nIHRoZWlyIG5ldHdvcmsgYXBwbGlj YWJpbGl0eSB0aGUgDQpjaG9pY2UgYmV0d2VlbiBib3RoIGFwcHJvYWNoZXMgd2lsbCBoYXZlIHRv IGJlIG1hZGUgb24gYSBjYXNlIGJ5IGNhc2UgYmFzaXMsIA0KZHJpdmVuIGJ5IGFyY2hpdGVjdHVy YWwgYW5kIG9wZXJhdGlvbmFsIGNvbnN0cmFpbnRzLiZuYnNwO0ZvciB0aGUgbW9tZW50IA0Kdzwv U1BBTj5lJm5ic3A7PFNQQU4gY2xhc3M9MTEzMTE0MTEyLTIxMDQyMDA5PmZlbDxTUEFOIA0KY2xh c3M9MTIzMjc1MjE0LTIxMDQyMDA5PnQ8L1NQQU4+IHRoZSA8L1NQQU4+bmVlZCB0byBpbnZlc3Rp Z2F0ZSZuYnNwO2JvdGggDQpzb2x1dGlvbnMgaW4gcGFyYWxsZWwuPC9GT05UPjwvRk9OVD48L1NQ QU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0wNzEyNDU2MTEt MjEwNDIwMDk+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwv RElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MDcxMjQ1NjExLTIxMDQy MDA5PjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+RG8geW91IGhhdmUgYW55IGNvbW1lbnQgb24g dGhlJm5ic3A7PFNQQU4gDQpjbGFzcz0xMTMxMTQxMTItMjEwNDIwMDk+YXBwbGljYWJpbGl0eSBv ZiB0aGUgdHdvIGFwcHJvYWNoZXMgPyZuYnNwOyZuYnNwO09yIA0KYW55Jm5ic3A7PC9TUEFOPnNw ZWNpZmljIHJlcXVpcmVtZW50PFNQQU4gY2xhc3M9MTEzMTE0MTEyLTIxMDQyMDA5PiZuYnNwO3Ro YXQgDQp3b3VsZCZuYnNwO25lZWQgdG8gYmUgaW5jbHVkZWQgaW4gdGhlIHJlcXVpcmVtZW50cyBk cmFmdCZuYnNwO29uIFAyTVAgUFcgDQo8L1NQQU4+PzwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElW IGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0wNzEyNDU2MTEtMjEwNDIwMDk+PEZPTlQg ZmFjZT1BcmlhbCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9 bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MDcxMjQ1NjExLTIxMDQyMDA5PjxGT05UIGZhY2U9 QXJpYWwgDQpzaXplPTI+QmVzdCBSZWdhcmRzLDwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRp cj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0wNzEyNDU2MTEtMjEwNDIwMDk+PEZPTlQgZmFj ZT1BcmlhbCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRy IGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MDcxMjQ1NjExLTIxMDQyMDA5PjxGT05UIGZhY2U9QXJp YWwgDQpzaXplPTI+RnJlZDwvRk9OVD48L1NQQU4+PC9ESVY+PC9ESVY+PEJSPg0KPERJViBjbGFz cz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWZyIGRpcj1sdHIgYWxpZ249bGVmdD4NCjxIUiB0 YWJJbmRleD0tMT4NCjxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5EZSZuYnNwOzo8L0I+IGwy dnBuLWJvdW5jZXNAaWV0Zi5vcmcgDQpbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIDxC PkRlIGxhIHBhcnQgZGU8L0I+IA0KemhhbmcueGlucXVhbkB6dGUuY29tLmNuPEJSPjxCPkVudm95 w6kmbmJzcDs6PC9CPiBtYXJkaSAyMSBhdnJpbCAyMDA5IA0KMDM6MjM8QlI+PEI+w4AmbmJzcDs6 PC9CPiBKT1VOQVkgRnJlZGVyaWMgUkQtUkVTQS1MQU48QlI+PEI+Q2MmbmJzcDs6PC9CPiANCmwy dnBuQGlldGYub3JnOyBsMnZwbi1ib3VuY2VzQGlldGYub3JnOyBwd2UzQGlldGYub3JnPEJSPjxC Pk9iamV0Jm5ic3A7OjwvQj4g562U5aSNOiANClJFOiBDb21tZW50cyBvbiBkcmFmdC1qb3VuYXkt cHdlMy1sZWFmLWluaXRpYXRlZC1wMm1wLXB3LTAxPEJSPjwvRk9OVD48QlI+PC9ESVY+DQo8RElW PjwvRElWPjxCUj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPkhpIEZyZWRlcmljLDwvRk9O VD48Rk9OVCBzaXplPTM+IA0KPC9GT05UPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PEJS PjwvRk9OVD48QlI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0Kc2l6ZT0yPlRoYW5rcyBmb3IgeW91 ciBjbGFyaWZpY2F0b24uPC9GT05UPiA8QlI+PEJSPjxGT05UIGZhY2U9c2Fucy1zZXJpZiANCnNp emU9Mj5Zb3UgaGF2ZSB0d28gZHJhZnRzIGFib3V0IFAyTVAgUFcgc2lnbmFsaW5nLCBvbmUgaXMg bGVhZi1pbml0aWF0ZWQgbW9kZSANCmFuZCB0aGUgb3RoZXIgaXMgc291cmNlLWluaXRpYXRlZCBt b2RlLiBJbiBteSBvcGluaW9uLCB5b3VyIG9yaWdpbmFsIGludGVudGlvbiANCmlzIHRvIHByb3Bv c2UgbGVhZi1pbml0aWF0ZWQgbW9kZSBhcyBhIHNvbHV0aW9uIGZvciBpbnRlci1kb21haW4gc2Nl bmFyaW8sIGFuZCANCnNvdXJjZS1pbml0aWF0ZWQgbW9kZSBmb3IgaW50cmEtZG9tYWluIHNjZW5h cmlvLiBBbSBJIHJpZ2h0PyBPciB5b3VyIGhhdmUgb3RoZXIgDQpjb25zaWRlcmF0aW9ucz88L0ZP TlQ+IDxCUj48QlI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj5CZXN0IHJlZ2FyZHMhPC9G T05UPiANCjxCUj48QlI+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj5YaW5xdWFuIFpoYW5n PC9GT05UPiA8QlI+PEJSPjxGT05UIA0KZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj4yMDA5LzQvMjE8 L0ZPTlQ+IDxCUj48QlI+PEJSPjxCUj48QlI+DQo8VEFCTEUgd2lkdGg9IjEwMCUiPg0KICA8VEJP RFk+DQogIDxUUiB2QWxpZ249dG9wPg0KICAgIDxURCB3aWR0aD0iMjYlIj48Rk9OVCBmYWNlPXNh bnMtc2VyaWYgDQogICAgICBzaXplPTE+PEI+Jmx0O2ZyZWRlcmljLmpvdW5heUBvcmFuZ2UtZnRn cm91cC5jb20mZ3Q7PC9CPiA8L0ZPTlQ+PEJSPjxGT05UIA0KICAgICAgZmFjZT1zYW5zLXNlcmlm IHNpemU9MT7lj5Hku7bkuro6ICZuYnNwO2wydnBuLWJvdW5jZXNAaWV0Zi5vcmc8L0ZPTlQ+IA0K ICAgICAgPFA+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT4yMDA5LTA0LTIwIDIwOjU1PC9G T05UPiA8L1A+DQogICAgPFREIHdpZHRoPSI3MyUiPg0KICAgICAgPFRBQkxFIHdpZHRoPSIxMDAl Ij4NCiAgICAgICAgPFRCT0RZPg0KICAgICAgICA8VFIgdkFsaWduPXRvcD4NCiAgICAgICAgICA8 VEQ+DQogICAgICAgICAgICA8RElWIGFsaWduPXJpZ2h0PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTE+5pS25Lu25Lq6PC9GT05UPjwvRElWPg0KICAgICAgICAgIDxURD48Rk9OVCBmYWNlPXNh bnMtc2VyaWYgDQogICAgICAgICAgICBzaXplPTE+Jmx0O3poYW5nLnhpbnF1YW5AenRlLmNvbS5j biZndDs8L0ZPTlQ+IA0KICAgICAgICA8VFIgdkFsaWduPXRvcD4NCiAgICAgICAgICA8VEQ+DQog ICAgICAgICAgICA8RElWIGFsaWduPXJpZ2h0PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+ 5oqE6YCBPC9GT05UPjwvRElWPg0KICAgICAgICAgIDxURD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYg c2l6ZT0xPmwydnBuQGlldGYub3JnLCANCiAgICAgICAgICAgIGwydnBuLWJvdW5jZXNAaWV0Zi5v cmcsIHB3ZTNAaWV0Zi5vcmc8L0ZPTlQ+IA0KICAgICAgICA8VFIgdkFsaWduPXRvcD4NCiAgICAg ICAgICA8VEQ+DQogICAgICAgICAgICA8RElWIGFsaWduPXJpZ2h0PjxGT05UIGZhY2U9c2Fucy1z ZXJpZiBzaXplPTE+5Li76aKYPC9GT05UPjwvRElWPg0KICAgICAgICAgIDxURD48Rk9OVCBmYWNl PXNhbnMtc2VyaWYgc2l6ZT0xPlJFOiBDb21tZW50cyBvbiANCiAgICAgICAgICAgIGRyYWZ0LWpv dW5heS1wd2UzLWxlYWYtaW5pdGlhdGVkLXAybXAtcHctMDE8L0ZPTlQ+PC9UUj48L1RCT0RZPjwv VEFCTEU+PEJSPg0KICAgICAgPFRBQkxFPg0KICAgICAgICA8VEJPRFk+DQogICAgICAgIDxUUiB2 QWxpZ249dG9wPg0KICAgICAgICAgIDxURD4NCiAgICAgICAgICA8VEQ+PC9UUj48L1RCT0RZPjwv VEFCTEU+PEJSPjwvVFI+PC9UQk9EWT48L1RBQkxFPjxCUj48QlI+PEJSPjxGT05UIGZhY2U9QXJp YWwgDQpjb2xvcj1ibHVlIHNpemU9Mj5IaSBYaW5xdWFuLDwvRk9OVD4gPEJSPjxGT05UIHNpemU9 Mz4mbmJzcDs8L0ZPTlQ+IDxCUj48Rk9OVCANCmZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+ UGxlYXNlIHNlZSBteSBhbnN3ZXIgaW5saW5lIFtGSl08L0ZPTlQ+IDxCUj48Rk9OVCANCnNpemU9 Mz4mbmJzcDs8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPkJl c3QgUmVnYXJkcyw8L0ZPTlQ+IA0KPEJSPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXpl PTI+RnJlZDwvRk9OVD4gPEJSPjxCUj4NCjxIUj4NCjxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48 Qj5EZSA6PC9CPiB6aGFuZy54aW5xdWFuQHp0ZS5jb20uY24gDQpbbWFpbHRvOnpoYW5nLnhpbnF1 YW5AenRlLmNvbS5jbl0gPEI+PEJSPkVudm95w6kgOjwvQj4gbWVyY3JlZGkgMTUgYXZyaWwgMjAw OSANCjA3OjUwPEI+PEJSPsOAIDo8L0I+IEpPVU5BWSBGcmVkZXJpYyBSRC1SRVNBLUxBTjxCPjxC Uj5DYyA6PC9CPiBsMnZwbkBpZXRmLm9yZzsgDQpsMnZwbi1ib3VuY2VzQGlldGYub3JnPEI+PEJS Pk9iamV0IDo8L0I+IENvbW1lbnRzIG9uIA0KZHJhZnQtam91bmF5LXB3ZTMtbGVhZi1pbml0aWF0 ZWQtcDJtcC1wdy0wMTwvRk9OVD48Rk9OVCANCnNpemU9Mz48QlI+PC9GT05UPjxCUj48Rk9OVCBm YWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxCUj5IaSwgRnJlZGVyaWMsPC9GT05UPjxGT05UIA0Kc2l6 ZT0zPiA8QlI+PC9GT05UPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PEJSPkkgaGF2ZSBy ZWFkIA0KZHJhZnQtam91bmF5LXB3ZTMtbGVhZi1pbml0aWF0ZWQtcDJtcC1wdy0wMSBhbmQgaGF2 ZSBzb21lIGNvbW1lbnRzLiBwbGVhc2Ugc2VlIA0KYmVsb3c6PC9GT05UPjxGT05UIHNpemU9Mz4g PEJSPjwvRk9OVD48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxCUj4x44CBc2VjdGlvbiAN CjUuNC4gQ29uZmlndXJhdGlvbiA8QlI+Jm5ic3A7ICZuYnNwOzxCUj4mbmJzcDsgQWZ0ZXIgY29u ZmlndXJpbmcgb24gZWFjaCBULVBFIA0KdGhlIGF0dGFjaGVkIEFJSXMsIGl0IGlzIGFzc3VtZWQg dGhhdCA8QlI+Jm5ic3A7IGFsbCB0aGUgUEVzIChJbmdyZXNzL0VncmVzcyANClQtUEVzIGFuZCBh bGwgUy1QRXMpIG1haW50YWluIGFuIEFJSSBQVyA8QlI+Jm5ic3A7IHJvdXRpbmcgdGFibGUgd2hp Y2ggZ2l2ZXMgZm9yIA0KZWFjaCBBSUkgYXMgZW50cnkgdGhlICJuZXh0IGhvcCIgdG8gPEJSPiZu YnNwOyByZWFjaCB0aGF0IEFJSS4gVGhpcyBBSUkgcm91dGluZyANCnRhYmxlIGNhbiBiZSBmaWxs ZWQgbWFudWFsbHkgb3IgPEJSPiZuYnNwOyB1cGRhdGVkIGR5bmFtaWNhbGx5IGJ5IG1lYW5zIG9m IHNvbWUgDQpleHRlbmRlZCByb3V0aW5nIHByb3RvY29sIGxpa2UgPEJSPiZuYnNwOyBwcm9wb3Nl ZCBpbiBbRFlOIE1TLVBXXS4gVGhlIA0KY29uc3RydWN0aW9uIG9mIHRoZSB0YWJsZSBpcyBvdXQg b2YgPEJSPiZuYnNwOyBzY29wZSBvZiB0aGUgcHJlc2VudCBkb2N1bWVudC4gDQo8QlI+Jm5ic3A7 ICZuYnNwOzxCUj4mbmJzcDsgRWFjaCBQRSByZWxpZXMgb24gaXRzIEFJSSBQVyByb3V0aW5nIHRh YmxlIHRvIHNlbGVjdCANCnRoZSBuZXh0IGhvcCBQRSA8QlI+Jm5ic3A7IChTLVBFIG9yIFQtUEUp IHRvIHJlYWNoIGEgZ2l2ZW4gQUlJLiA8L0ZPTlQ+PEZPTlQgDQpzaXplPTM+PEJSPjwvRk9OVD48 Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxCUj4mZ3Q7MSAmbmJzcDtEb2VzIHRoaXMgQUlJ IA0Kcm91dGluZyB0YWJsZSBpbmNsdWRlIGJvdGggVEFJSSBhbmQgU0FJST88L0ZPTlQ+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj1ibHVlIA0Kc2l6ZT0yPiA8L0ZPTlQ+PEJSPjxGT05UIGZhY2U9QXJp YWwgY29sb3I9Ymx1ZSBzaXplPTI+W0ZKXSBZZXMsIHRoZSBBSUkgcm91dGluZyANCnRhYmxlIGR5 bmFtaWNhbGx5IHBvcHVsYXRlZCAoQkdQLCBPU1BGLCBJUy1JUyBvciBMRFApIHNob3VsZCBtYWlu dGFpbiBib3RoLiBUaGUgDQpFZ3Jlc3MgVC1QRSBqb2lucyB0aGUgUFcgdHJlZSBieSBpbml0aWF0 aW5nIGEgTGFiZWwgTWFwIHdob3NlIHRoZSBGRUMgY29udGFpbnMgDQp0aGUgU0FJSSwgdGhlIFBX IHRyZWUgc291cmNlLiBIZW5jZSB1cG9uIHJlY2VpcHQgb2YgdGhlIG1lc3NhZ2UgdGhlIFMtUEUg ZG9lcyBhIA0KbG9va3VwIHRvIHNlbGVjdCB0aGUgTkggdG8gcmVhY2ggdGhpcyBTQUlJLiAmbmJz cDsgJm5ic3A7PC9GT05UPjxGT05UIA0KZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj4gPC9GT05UPjxG T05UIHNpemU9Mz4mbmJzcDs8L0ZPTlQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIA0Kc2l6ZT0yPjxC Uj4mZ3Q7MiAmbmJzcDtJbiBTLVBFLCB0aGlzIEFJSSByb3V0aW5nIHRhYmxlIGluY2x1ZGVzIGFs bCB0aGUgQUlJLCBvciANCmp1c3QgcGFydCBvZiB0aGUgQUlJKCBlLmcuIHdoaWNoIGFyZSBpbiBp dHMgZG93c3RyZWFtKT88L0ZPTlQ+PEZPTlQgc2l6ZT0zPiANCjwvRk9OVD48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxCUj5bRkpdIHRoZSBBSUkgcm91dGluZyB0YWJsZSBzaG91 bGQgDQpiZSB1c2VkIGFsc28gZm9yIFZQV1Mgb3IgVlBMUywgc28gYmlkaXJlY3Rpb25hbCBQVy4g VGhlcmVmb3JlIHRoZSBBSUkgcm91dGluZyANCnRhYmxlIG11c3QgcmVmbGVjdCBhbGwgdGhlIEFJ SSBjb25maWd1cmVkIG9uIFQtUEVzLiBPZiBjb3Vyc2UgYWdyZWdhdGUgQUlJIA0KZm9ybWF0IChp LmUuIHcvbyBBQ0lEIGluZm8pIGFzIGRlZmluZWQgaW4gW0RZTiBNUy1QV10gbXVzdCBiZSB1c2Vk IHRvIG9wdGltaXplIA0KdGhlIEFJSSByb3V0aW5nIHRhYmxlPC9GT05UPjxGT05UIHNpemU9Mz48 QlI+PC9GT05UPjxGT05UIGZhY2U9c2Fucy1zZXJpZiANCnNpemU9Mj48QlI+MuOAgVNlY3Rpb24g NS43LiBVc2luZyBUQUlJIExlYWYgU3ViLVRMViA8QlI+Jm5ic3A7ICZuYnNwOzxCUj4mbmJzcDsg DQpTZWN0aW9uIFRCRCA8QlI+Jm5ic3A7ICZuYnNwOzxCUj4mbmJzcDsgVGhlIFRBSUkgTGVhZiBz dWItVExWIE1BWSBiZSBvcHRpb25hbGx5IA0KdXNlZCB3aGVuIGEgbGVhZiBqb2lucyB0aGUgUFcg PEJSPiZuYnNwOyB0cmVlIHRvIGFubm91bmNlIHRvIHRoZSBzb3VyY2UgdGhhdCBpdCANCmlzIHBh cnQgZnJvbSB0aGUgUFcgdHJlZS4gSWYgPEJSPiZuYnNwOyB0aGlzIG9wdGlvbiBpcyBjaG9zZW4s IHRoZSBFZ3Jlc3MgVC1QRSANCmFkZHMgdG8gdGhlIEZFQyBFbGVtZW50IHRoaXMgPEJSPiZuYnNw OyBUQUlJIHN1Yi1UTFYgaW4gdGhlIExhYmVsIE1hcCBtZXNzYWdlLiANCkFzIHNvb24gYXMgaW4g dGhlIHNvdXJjZSA8QlI+Jm5ic3A7IGRpcmVjdGlvbiBhIExhYmVsIE1hcCBpcyBub3QgcmVxdWly ZWQgc2luY2UgDQpmb3IgaW5zdGFuY2UgYSBTLVBFIDxCUj4mbmJzcDsgYWxyZWFkeSBtYWludGFp bnMgYSBzdGF0ZSBmb3IgdGhpcyBNUy1QVyB0cmVlLCANCnRoZSBpbmZvcm1hdGlvbiA8QlI+Jm5i c3A7IHJlbGF0ZWQgdG8gdGhlIExlYWYgVEFJSXMgaXMgcmV0cmlldmVkIGZyb20gdGhlIFRBSUkg DQpMZWFmIHN1Yi1UTFYgYW5kIDxCUj4mbmJzcDsgaXMgcHJvcGFnYXRlZCBieSBtZWFucyBvZiBh IExEUCBOb3RpZmljYXRpb24gbWVzc2FnZSANCnVwIHRvIHRoZSA8QlI+Jm5ic3A7IGNvcnJlc3Bv bmRpbmcgSW5ncmVzcyBULVBFLiAmbmJzcDsgPEJSPiZndDsgSSBhbSBub3Qgc3VyZSANCmFib3V0 IHRoZSBwcm9wYWdhdGlvbiBvZiBUQUlJIExlYWYgc3ViLVRMVi4gSXMgaXQgc2VudCB0byBpbmdy ZXNzIFQtUEUgZGlyZWN0bHksIA0Kb3IgdG8gdGhlIHVwc3RyZWFtIFMtUEUoaWYgdGhlcmUgZXhp c3RzIHN1Y2ggUy1QRSBpbiB0aGUgdXBzdHJlYW0gDQpkaXJlY3Rpb24pPzwvRk9OVD48Rk9OVCBz aXplPTM+IDwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgDQpzaXplPTI+Jm5ic3A7 PC9GT05UPiA8QlI+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj5bRkpdIFRoZSAN Ck5vdGlmaWNhdGlvbiBtZXNzYWdlIGNhbiBub3QgYmUgZGlyZWN0bHkgc2VudCB0byB0aGUgSW5n cmVzcyBULVBFIGlmIHRoZXJlIGlzIA0Kbm90IGRpcmVjdCBULUxEUCBzZXNzaW9uIHRvIHJlYWNo IHRoZSBJbmdyZXNzIFQtUEUsIGkuZS4gUy1QRSBpbiBiZXR3ZWVuLiBUaGF0J3MgDQp0aGUgcmVh c29uIHdoeSB0aGUgbWVzc2FnZSBzaG91bGQgYmUgcHJvcGFnYXRlZCBob3AgYnkgaG9wIChpLmUu IFMtUEUgYnkgDQpTLVBFKTwvRk9OVD48Rk9OVCBzaXplPTM+IDwvRk9OVD48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPWJsdWUgc2l6ZT0yPnVwIHRvIHRoZSANCkluZ3Jlc3MgVC1QRS48L0ZPTlQ+IDxC Uj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPiZuYnNwO0kgYWdyZWUgd2l0aCAN CnlvdSB0aGF0J3Mgd29ydGggY2xhcmlmeWluZyB0aGlzIHNlY3Rpb24uIDwvRk9OVD48Rk9OVCBz aXplPTM+PEJSPjwvRk9OVD48Rk9OVCANCmZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PEJSPkJlc3Qg UmVnYXJkcyE8L0ZPTlQ+PEZPTlQgc2l6ZT0zPiA8QlI+PC9GT05UPjxGT05UIA0KZmFjZT1zYW5z LXNlcmlmIHNpemU9Mj48QlI+WGlucXVhbiBaaGFuZzwvRk9OVD48Rk9OVCBzaXplPTM+IDxCUj48 L0ZPTlQ+PEZPTlQgDQpmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxCUj4yMDA5LzQvMTU8L0ZPTlQ+ PEZPTlQgc2l6ZT0zPiA8QlI+PC9GT05UPjxGT05UIA0KZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48 QlI+PC9GT05UPjxCUj48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C9C291.16F066BE-- From igoyret@alcatel-lucent.com Wed Apr 22 11:18:10 2009 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 9FE5B3A6D23; Wed, 22 Apr 2009 11:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 U2-CDNBWVYUx; Wed, 22 Apr 2009 11:18:09 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id AB9363A679C; Wed, 22 Apr 2009 11:18:08 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n3MIJIZi006869; Wed, 22 Apr 2009 13:19:18 -0500 (CDT) Received: from cliff.eng.ascend.com (cliff.eng.ascend.com [135.140.53.169]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n3MIJGeK008857; Wed, 22 Apr 2009 13:19:17 -0500 (CDT) Received: from igoyret-c1.alcatel-lucent.com (dhcp-135-140-27-183 [135.140.27.183]) by cliff.eng.ascend.com (8.13.1/8.13.1) with ESMTP id n3MIJFk3001802; Wed, 22 Apr 2009 11:19:15 -0700 Message-Id: <200904221819.n3MIJFk3001802@cliff.eng.ascend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 22 Apr 2009 11:17:06 -0700 To: mustapha.aissaoui@alcatel-lucent.com, busschbach@alcatel-lucent.com, dallan@nortel.com, lmartini@cisco.com, tom.nadeau@bt.com, mmorrow@cisco.com, yaakov_s@rad.com From: Ignacio Goyret Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: pwe3@ietf.org, l2tpext@ietf.org Subject: [PWE3] pwe3-oam-msg-map reference correction 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, 22 Apr 2009 18:18:10 -0000 Hi, Your draft-ietf-pwe3-oam-msg-map-10.txt contains an informative reference to: [L2TP-Status] McGill, N. Pignataro, C., "L2TPv3 Extended Circuit Status Values", draft-nmcgill-l2tpext-circuit-status-extensions- 01 (work in progress), June 2008. The correct name for this draft is draft-ietf-l2tpext-circuit-status-extensions. Note also that this draft just went through WGLC and it is getting ready to be sent to the IESG. Cheers, -Ignacio Goyret l2tpext WG chair From dward@cisco.com Thu Apr 23 14:06:06 2009 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 15CC13A7312; Thu, 23 Apr 2009 14:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 4VnoSDy0qf9M; Thu, 23 Apr 2009 14:06:05 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C3E063A72BE; Thu, 23 Apr 2009 14:06:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,237,1238976000"; d="scan'208,217";a="42590613" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Apr 2009 21:07:22 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3NL7MYe006773; Thu, 23 Apr 2009 17:07:22 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3NL7MS4025418; Thu, 23 Apr 2009 21:07:22 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 17:07:22 -0400 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 17:07:21 -0400 Message-Id: <5EE53708-2D8B-4DFB-8365-27041AACB0BE@cisco.com> From: David Ward To: softwires@ietf.org, l3vpn@ietf.org, pwe3@ietf.org, Ralph Droms , Jari Arkko Content-Type: multipart/alternative; boundary=Apple-Mail-6-220634604 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 23 Apr 2009 16:07:19 -0500 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 23 Apr 2009 21:07:21.0896 (UTC) FILETIME=[7E6BC280:01C9C457] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1275; t=1240520842; x=1241384842; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20WG=20LC=20softwire-lb |Sender:=20 |To:=20softwires@ietf.org,=20l3vpn@ietf.org,=20pwe3@ietf.or g,=0A=20=20=20=20=20=20=20=20Ralph=20Droms=20,=20Jari=20Arkko=20; bh=YHBPf2MZluD4AJ4bzzOApyLxmi6XzDJ/2uuyDX1GuMw=; b=h5P3sauBsJ6RGQ0ukhh9v2mevtTYsMBSqZbXbUBD+Qd2SmIfmP06153evy J7sdgI2PeADwXT9cdQ33mz4CytTxnCMu8U+JwPZQdoYQshZl/I8DGeDItrw9 Nl8Lgmii1I; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Alain Durand , Carlos Pignataro , "Pradosh \(pmohapat\) Mohapatra" , David Ward , Clarence Filsfils Subject: [PWE3] WG LC softwire-lb 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, 23 Apr 2009 21:06:06 -0000 --Apple-Mail-6-220634604 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit All - Following the last IETF meeting all comments have been addressed in: http://tools.ietf.org/html/draft-ietf-softwire-lb-02 The authors have requested a WG LC and I have added L3VPN and PWE3 that may be interested and have comments on the technology. Please send back all comments by May 7, 2009. Thanks DWard, Alain --Apple-Mail-6-220634604 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit All -
Following the last IETF meeting all comments have been addressed in:



The authors have requested a WG LC and I have added L3VPN and PWE3 that may be interested and have comments on the technology. Please send back all comments by May 7, 2009.

Thanks

DWard, Alain
--Apple-Mail-6-220634604-- From Martin.Vigoureux@alcatel-lucent.com Fri Apr 24 04:12:12 2009 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 082EB3A6FFC; Fri, 24 Apr 2009 04:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 xeXwbBp53d2V; Fri, 24 Apr 2009 04:12:11 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 71B8F3A6FFF; Fri, 24 Apr 2009 04:11:14 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3OBCSZ8011888; Fri, 24 Apr 2009 13:12:28 +0200 Received: from [135.244.36.16] ([135.244.36.16]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Apr 2009 13:12:27 +0200 Message-ID: <49F19E8F.7050105@alcatel-lucent.com> Date: Fri, 24 Apr 2009 13:12:15 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2009 11:12:28.0253 (UTC) FILETIME=[8DC3D0D0:01C9C4CD] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: ccamp@ops.ietf.org, l2vpn@ietf.org, pwe3@ietf.org, mpls-tp@ietf.org Subject: [PWE3] IETF 74 - MPLS WG minutes 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, 24 Apr 2009 11:12:12 -0000 all, the minutes of the mpls wg sessions are available on-line: http://tools.ietf.org/wg/mpls/minutes Please have a look at them and let me know if you would like additional details to be reflected. Three slide sets are still missing, I'll contact the presenters and upload them as soon as I receive them. regards, martin From robert@raszuk.net Fri Apr 24 01:32:42 2009 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 F13153A6B58 for ; Fri, 24 Apr 2009 01:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 mS1ySHSDHpUj for ; Fri, 24 Apr 2009 01:32:42 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 1970C3A6A98 for ; Fri, 24 Apr 2009 01:30:35 -0700 (PDT) Received: (qmail 3738 invoked by uid 399); 24 Apr 2009 08:31:48 -0000 Received: from unknown (HELO ?172.30.29.64?) (80.187.215.123) by mail37.opentransfer.com with SMTP; 24 Apr 2009 08:31:48 -0000 Message-ID: <49F178ED.2080905@raszuk.net> Date: Fri, 24 Apr 2009 01:31:41 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Ward References: <5EE53708-2D8B-4DFB-8365-27041AACB0BE@cisco.com> In-Reply-To: <5EE53708-2D8B-4DFB-8365-27041AACB0BE@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 24 Apr 2009 08:06:05 -0700 Cc: Carlos Pignataro , l3vpn@ietf.org, Clarence Filsfils , Ralph Droms , Alain Durand , softwires@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] WG LC softwire-lb X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 08:32:43 -0000 Hi David, Perhaps I may have missed the discussion on this in the other WGs but I have two comments/questions ... * Why the decision on enhancing the load balancing capability of IP encapsulated packet has to be signaled as opposed to be a local matter of the ingress router performing encapsulation ? * Reg use of GRE key for the purpose of load balancing I must say that GRE key has already been proposed in number of solutions today. Therefor overloading more on it may be impractical. Did authors analyzed use of Sequence Numbers in GRE header instead for the purpose of increasing effectiveness of load-balancing by the transit nodes ? Cheers, R. > All - > Following the last IETF meeting all comments have been addressed in: > > http://tools.ietf.org/html/draft-ietf-softwire-lb-02 > > The authors have requested a WG LC and I have added L3VPN and PWE3 that > may be interested and have comments on the technology. Please send back > all comments by May 7, 2009. > > Thanks > > DWard, Alain From prvs=35820fe87=euddasi@redback.com Fri Apr 24 09:12:04 2009 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 1570C3A6E03 for ; Fri, 24 Apr 2009 09:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 xnpR3ekS5QwX for ; Fri, 24 Apr 2009 09:12:03 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 2A2263A6C35 for ; Fri, 24 Apr 2009 09:12:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,242,1239001200"; d="scan'208";a="1182134" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 24 Apr 2009 09:13:22 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A05AA44B3E8 for ; Fri, 24 Apr 2009 09:13:21 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24870-04 for ; Fri, 24 Apr 2009 09:13:21 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id 559D9811B3 for ; Fri, 24 Apr 2009 09:13:21 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Fri, 24 Apr 2009 09:13:21 -0700 From: David Sinicrope To: "pwe3@ietf.org" Date: Fri, 24 Apr 2009 09:13:19 -0700 Thread-Topic: Call for consensus on draft-ietf-pwe3-ms-pw-arch-06.txt Thread-Index: AcnE95TZoaKjNF4m70uiZsasjR1CUA== Message-ID: Accept-Language: en-US Content-Language: en 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 Subject: [PWE3] Call for consensus on draft-ietf-pwe3-ms-pw-arch-06.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: Fri, 24 Apr 2009 18:10:06 -0000 At the San Francisco meeting the PWE3 Chairs requested that I make the consensus call on draft-ietf-pwe3-ms-pw-arch-06 because they are both co-editors. I=B9ve reviewed the PWE3 last call comments and the updated version of the draft. There is WG consensus to proceed with the publicatio= n process. Thanks, Dave From xueli@huawei.com Sat Apr 25 00:40:22 2009 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 176213A67FF for ; Sat, 25 Apr 2009 00:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.246 X-Spam-Level: *** X-Spam-Status: No, score=3.246 tagged_above=-999 required=5 tests=[AWL=3.445, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_56=0.6] 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 v8NKMY9foz6R for ; Sat, 25 Apr 2009 00:40:21 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 7EA333A69B8 for ; Sat, 25 Apr 2009 00:40:20 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIN005MXC1DDU@szxga04-in.huawei.com> for pwe3@ietf.org; Sat, 25 Apr 2009 15:41:37 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIN007NIC1DAW@szxga04-in.huawei.com> for pwe3@ietf.org; Sat, 25 Apr 2009 15:41:37 +0800 (CST) Received: from x68103 ([10.111.12.100]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIN00BF7C1CWW@szxml04-in.huawei.com> for pwe3@ietf.org; Sat, 25 Apr 2009 15:41:36 +0800 (CST) Date: Sat, 25 Apr 2009 15:41:36 +0800 From: Sherry Xue In-reply-to: To: frederic.jounay@orange-ftgroup.com Message-id: <002d01c9c579$43479850$640c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnCkVIWWgfDILkTRYGEW5WeRW4bvgC2kmtQ Cc: pwe3@ietf.org Subject: Re: [PWE3] Comments on draft-jounay-pwe3-leaf-initiated-p2mp-pw-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: Sat, 25 Apr 2009 07:40:22 -0000 Hi, Fred, I totally agree with your opinion that the leaf-initiated mode and source-initiated mode are not restricted in the application of SS-PW and MS-PW. IMO, leaf initiated mode is more conveniently for MS-PW, and in the source initiated mode, more work should be considered for MS-PW, such as AD and PW routing. I agree the standardization work course with admiration. For P2MP SS-PW setup in leaf-initiated mode, it may be divided into two instances: 1)over P2P PSN : this case may be according to MP2P signaling, similarly as star-topology(logically), in which P2MP SS-PW is composed of m(leaf no.)*P2P SS-PW, and all the P2P SS-PWs should be setup individually without consideration of the merge-node(physically). That is to say in the merge node, there will be different labels allocated upstream for different downstream T-PEs. 2) over P2MP PSN The merge-node should record the Label(called label L) allocated by the downstream TAII(called X) with SAII( S ), and if another signaling message from other TAII(i.e.,Y) is received with same SAII, the merge-node should allocated label L for TAII Y(upstream label assignment), and then allocate upstream label to next upstream hop. IMO, if the P2MP PW is initiated by the leafs, the PSN tunnel should be restrict to P2P, because it sounds illogical that the leaf node is used to manage a P2MP LSP or PW? What about your opinion? For P2MP MS-PW setup in source-initiated mode, the explicit routing should be provided in the source PE. So the LDP should be extended for MS-PW setup according explicit routing. Right? Whether the explicit routing is the only method for the PW routing? Regarding the P2P PW setup procedure, there are two protocols, LDP and BGP. Could we use BGP for P2MP PW setup? Best wishes and regards Sherry > Hi Xinquan > > "In my opinion, your original intention is to propose leaf-initiated mode as > a solution for inter-domain scenario, and source-initiated mode for > intra-domain scenario. Am I right?" > > not really, actually both procedures (leaf or source initiated) are not > limited in their operating principles and as such could be used to cover SS-PW > and MS-PW configuration. > For the standardization work we propose to focus first on P2MP SS-PW as it > is the simplest configuration, to agree on the required new building blocks : > FEC element, signaling procedures etc... > The part related to P2MP SS-PW setup in the leaf-initiated draft and the part > related to P2MP MS-PW setup in the source-initiated draft should be added asap > or considered in a separate document. > > Regarding their network applicability the choice between both approaches will > have to be made on a case by case basis, driven by architectural and operational > constraints. For the moment we felt the need to investigate both solutions in > parallel. > > Do you have any comment on the applicability of the two approaches ? Or any > specific requirement that would need to be included in the requirements draft > on P2MP PW ? > > Best Regards, > > Fred > > ________________________________ > > De : l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] De la part de > zhang.xinquan@zte.com.cn > Envoy? : mardi 21 avril 2009 03:23 > ? : JOUNAY Frederic RD-RESA-LAN > Cc : l2vpn@ietf.org; l2vpn-bounces@ietf.org; pwe3@ietf.org > Objet : ??: RE: Comments on draft-jounay-pwe3-leaf-initiated-p2mp-pw-01 > > > > Hi Frederic, > > Thanks for your clarificaton. > > You have two drafts about P2MP PW signaling, one is leaf-initiated mode and > the other is source-initiated mode. In my opinion, your original intention is > to propose leaf-initiated mode as a solution for inter-domain scenario, and > source-initiated mode for intra-domain scenario. Am I right? Or your have other > considerations? > > Best regards! > > Xinquan Zhang > > 2009/4/21 > > > > > > > ???: l2vpn-bounces@ietf.org > > 2009-04-20 20:55 > > ??? > > ?? > l2vpn@ietf.org, l2vpn-bounces@ietf.org, pwe3@ietf.org > ?? > RE: Comments on draft-jounay-pwe3-leaf-initiated-p2mp-pw-01 > > > > > > > Hi Xinquan, > > Please see my answer inline [FJ] > > Best Regards, > Fred > > > ________________________________ > > De : zhang.xinquan@zte.com.cn [mailto:zhang.xinquan@zte.com.cn] > Envoy? : mercredi 15 avril 2009 07:50 > ? : JOUNAY Frederic RD-RESA-LAN > Cc : l2vpn@ietf.org; l2vpn-bounces@ietf.org > Objet : Comments on draft-jounay-pwe3-leaf-initiated-p2mp-pw-01 > > > Hi, Frederic, > > I have read draft-jounay-pwe3-leaf-initiated-p2mp-pw-01 and have some > comments. please see below: > > 1?section 5.4. Configuration > > After configuring on each T-PE the attached AIIs, it is assumed that > all the PEs (Ingress/Egress T-PEs and all S-PEs) maintain an AII PW > routing table which gives for each AII as entry the "next hop" to > reach that AII. This AII routing table can be filled manually or > updated dynamically by means of some extended routing protocol like > proposed in [DYN MS-PW]. The construction of the table is out of > scope of the present document. > > Each PE relies on its AII PW routing table to select the next hop PE > (S-PE or T-PE) to reach a given AII. > > >1 Does this AII routing table include both TAII and SAII? > [FJ] Yes, the AII routing table dynamically populated (BGP, OSPF, IS-IS or LDP) > should maintain both. The Egress T-PE joins the PW tree by initiating a Label > Map whose the FEC contains the SAII, the PW tree source. Hence upon receipt > of the message the S-PE does a lookup to select the NH to reach this SAII. > >2 In S-PE, this AII routing table includes all the AII, or just part of the > AII( e.g. which are in its dowstream)? > [FJ] the AII routing table should be used also for VPWS or VPLS, so bidirectional > PW. Therefore the AII routing table must reflect all the AII configured on T-PEs. > Of course agregate AII format (i.e. w/o ACID info) as defined in [DYN MS-PW] > must be used to optimize the AII routing table > > 2?Section 5.7. Using TAII Leaf Sub-TLV > > Section TBD > > The TAII Leaf sub-TLV MAY be optionally used when a leaf joins the PW > tree to announce to the source that it is part from the PW tree. If > this option is chosen, the Egress T-PE adds to the FEC Element this > TAII sub-TLV in the Label Map message. As soon as in the source > direction a Label Map is not required since for instance a S-PE > already maintains a state for this MS-PW tree, the information > related to the Leaf TAIIs is retrieved from the TAII Leaf sub-TLV and > is propagated by means of a LDP Notification message up to the > corresponding Ingress T-PE. > > I am not sure about the propagation of TAII Leaf sub-TLV. Is it sent to ingress > T-PE directly, or to the upstream S-PE(if there exists such S-PE in the upstream > direction)? > [FJ] The Notification message can not be directly sent to the Ingress T-PE if > there is not direct T-LDP session to reach the Ingress T-PE, i.e. S-PE in between. > That's the reason why the message should be propagated hop by hop (i.e. S-PE > by S-PE) up to the Ingress T-PE. > I agree with you that's worth clarifying this section. > > Best Regards! > > Xinquan Zhang > > 2009/4/15 > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > ttachment.htm> > > ------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > End of pwe3 Digest, Vol 60, Issue 26 > ************************************ From Black_David@emc.com Mon Apr 27 17:31:47 2009 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 64A733A6BCE for ; Mon, 27 Apr 2009 17:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 dN1J6m-v0OyO for ; Mon, 27 Apr 2009 17:31:46 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 41E663A6B11 for ; Mon, 27 Apr 2009 17:31:45 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n3S0X3pK013422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Apr 2009 20:33:04 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor) for ; Mon, 27 Apr 2009 20:32:55 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n3S0WnSu007092 for ; Mon, 27 Apr 2009 20:32:55 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 20:32:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Apr 2009 20:32:49 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A02890437@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Fibre Channel Drafts - Last Call Thread-Index: AckCNDNITbqJL0uJRV+TYel42k3kjwFkTD3gL/TBfQA= To: X-OriginalArrivalTime: 28 Apr 2009 00:32:50.0361 (UTC) FILETIME=[DC693A90:01C9C798] X-EMM-EM: Active Subject: Re: [PWE3] Fibre Channel Drafts - Last Call 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, 28 Apr 2009 00:31:47 -0000 With the split of the FC PW into two drafts, the changes below apply to Section 3 of draft-ietf-pwe3-fc-flow-00.txt . They still need to be made. Thanks, --David -----Original Message----- From: Black, David=20 Sent: Tuesday, August 26, 2008 6:35 PM To: pwe3@ietf.org Cc: Black, David; 'Moran Roth' Subject: FW: [PWE3] I-D Action:draft-ietf-pwe3-fc-encap-08.txt The draft was posted this time. I've diff'ed this draft against the -07 version. The results look good; I have a few minor edits to the new timing material in Section 7: OLD: while the device is unable to forward these Primitive Sequence due to backpressure indication, it shall flush its respective buffer (PSN- facing if the Primitive Sequences were received from the CE, CE- facing if they were received from the remote PE), and shall forward=20 the Primitive Sequences.=20 =20 NEW: (change "shall" to "MUST")=20 while the device is unable to forward these Primitive Sequence due to backpressure indication, it MUST flush its respective buffer (PSN- facing if the Primitive Sequences were received from the CE, CE- facing if they were received from the remote PE), and MUST forward=20 the Primitive Sequences.=20 OLD: Another case is when there is no specific backpressure indication,=20 rather Primitive Sequences are being delayed due to retransmission of dropped frames. In this case also, the PE shall flush its PSN-facing=20 buffer and shall forward the Primitive Sequences. NEW: (clarify paragraph, add retransmission sentence, add explanation of why R_T_TOV is important) Another case is when there is no specific backpressure indication,=20 but the Primitive Sequences cannot be immediately forwarded due to frames awaiting retransmission that must be sent first. In this case, the PE MUST flush its PSN-facing buffer and MUST forward the Primitive Sequences. Long sequences of the same Primitive Sequence MUST be suppressed as described in [FC-BB]. If the buffer clearing actions described in the previous paragraphs fail to ensure that the round trip latency for Primitive Sequences is less than R_T_TOV, the Fibre Channel link that is carried by the pseudowire may fail or may go offline and remain in that state because an R_T_TOV timeout in used in Fibre Channel's Link Initialization, Link Failure and Link Reset protocols (see Section 7 of [FC-FS]). Therefore, the FC PW SHOULD NOT be used when the latency across the FC PW may exceed 0.5 * R_T_TOV. OLD: To guarantee correct operation of this mechanism FC PW SHOULD NOT be=20 used in environments where the RTT may have high variability, i.e.,=20 environments where the estimated RTT may not be off by more than 5%=20 of MIN(E_D_TOV,R_A_TOV). NEW: To guarantee correct operation of this mechanism FC PW SHOULD NOT be=20 used in environments where the RTT may have high variability, i.e.,=20 environments where the estimated RTT may be off by more than 5%=20 of MIN(E_D_TOV,R_A_TOV). ^ =20 | Remove "not" ------------------------------/ I think this is ready to go with these changes - if we treat the last one as a thinko, they're all editorial and could be dealt with at IETF Last Call. Thanks, --David -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, August 19, 2008 3:45 PM To: i-d-announce@ietf.org Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-fc-encap-08.txt 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 frames Over MPLS Networks Author(s) : M. Roth, et al. Filename : draft-ietf-pwe3-fc-encap-08.txt Pages : 40 Date : 2008-08-19 A Fibre Channel pseudowire (PW) is used to carry Fibre Channel frames=20 over an MPLS network. This enables service providers to offer=20 "emulated" Fibre Channel services over existing MPLS networks. This=20 document specifies the encapsulation of Fibre Channel PDUs within a=20 pseudowire. It also specifies the procedures for using a PW to=20 provide a Fibre Channel service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fc-encap-08.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. From cpignata@cisco.com Wed Apr 29 08:22:18 2009 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 9CCB03A67F3; Wed, 29 Apr 2009 08:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.262 X-Spam-Level: X-Spam-Status: No, score=-6.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 tB1MBWoEcw4U; Wed, 29 Apr 2009 08:22:17 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 1E3063A715A; Wed, 29 Apr 2009 08:22:16 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n3TFNbX4025253; Wed, 29 Apr 2009 11:23:37 -0400 (EDT) Received: from [64.102.157.114] (dhcp-64-102-157-114.cisco.com [64.102.157.114]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n3TFNaJe023981; Wed, 29 Apr 2009 11:23:37 -0400 (EDT) Message-ID: <49F870F8.9070301@cisco.com> Date: Wed, 29 Apr 2009 11:23:36 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: robert@raszuk.net References: <5EE53708-2D8B-4DFB-8365-27041AACB0BE@cisco.com> <49F178ED.2080905@raszuk.net> In-Reply-To: <49F178ED.2080905@raszuk.net> X-Enigmail-Version: 0.95.7 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: l3vpn@ietf.org, Clarence Filsfils , Ralph Droms , Alain Durand , pwe3@ietf.org, David Ward , softwires@ietf.org Subject: Re: [PWE3] [Softwires] WG LC softwire-lb 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, 29 Apr 2009 15:22:18 -0000 Hi Robert, Thank you for your comments, please see inline. On 4/24/2009 4:31 AM, Robert Raszuk wrote: > Hi David, > > Perhaps I may have missed the discussion on this in the other WGs but I > have two comments/questions ... > > * Why the decision on enhancing the load balancing capability of IP > encapsulated packet has to be signaled as opposed to be a local matter > of the ingress router performing encapsulation ? This is because the load-balancing field is signaled (see RFC5512), so using for lb it needs signaling of a block to avoid collisions. Note also the context from the title, lb for Mesh Softwires. For the L2TPv3 case, and from , the only encapsulating header field that is always there is the Session ID (Cookie is optional), which is signaled; the case for GRE is equivalent, but also please see below. If it's only a local matter, the encapsulating header's fields could not be used and you would be limited to playing with e.g., the source IP address. > > * Reg use of GRE key for the purpose of load balancing I must say that > GRE key has already been proposed in number of solutions today. Therefor > overloading more on it may be impractical. Did authors analyzed use of > Sequence Numbers in GRE header instead for the purpose of increasing > effectiveness of load-balancing by the transit nodes ? Yes, it was considered, but we need a field that can be used for flow identification. From RFC2890, the seq # MUST be used by the receiver to establish packet transmission order, so it's incompatible with a per-flow use. The GRE Key's semantics from RFC2890 match this use, : The Key field contains a four octet number which was inserted by the encapsulator. The actual method by which this Key is obtained is beyond the scope of the document. The Key field is intended to be used for identifying an individual traffic flow within a tunnel. Thanks, -- Carlos. > > Cheers, > R. > > >> All - >> Following the last IETF meeting all comments have been addressed in: >> >> http://tools.ietf.org/html/draft-ietf-softwire-lb-02 >> >> The authors have requested a WG LC and I have added L3VPN and PWE3 that >> may be interested and have comments on the technology. Please send back >> all comments by May 7, 2009. >> >> Thanks >> >> DWard, Alain > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From lmartini@cisco.com Thu Apr 30 15:58:00 2009 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 C15213A6E73 for ; Thu, 30 Apr 2009 15:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 aLaIE7FnG1Lc for ; Thu, 30 Apr 2009 15:57:58 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [67.41.208.110]) by core3.amsl.com (Postfix) with ESMTP id A80F53A6900 for ; Thu, 30 Apr 2009 15:57:57 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id n3UMxBct005647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2009 16:59:13 -0600 (MDT) Message-ID: <49FA2D3F.70702@cisco.com> Date: Thu, 30 Apr 2009 16:59:11 -0600 From: Luca Martini User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: hhelvoort@chello.nl References: <49D4F11A.1020905@cisco.com> <49D610C7.1070307@chello.nl> In-Reply-To: <49D610C7.1070307@chello.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 209.245.27.1 Cc: pwe3 Subject: Re: [PWE3] Should draft-martini-pwe3-iccp-01 be a WG doc? 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, 30 Apr 2009 22:58:00 -0000 Huub, You are correct, we have not included the SONET APS support yet. This is something that we plan to include shortly, depending on how much interest the WG has in this topic. Thanks. Luca Huub van Helvoort wrote: > To the authors: > > What do you mean by "SONET APS" and where is it located > in figure 1? > > I could not find any reference in the refence sections either. > > Regards, Huub. > > ===================== >> The authors of draft-martini-pwe3-iccp-01.txt >> >> http://tools.ietf.org/id/draft-martini-pwe3-iccp-01.txt >> >> have requested that this become a PWE3 WG document. >> >> Please can you send comments to the list by 20th April >> so that the chairs can judge consensus. >> >> Thanks >> >> Stewart > >