From javi@trajano.us.es Tue Feb 1 05:11:05 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6BD73A6D79 for ; Tue, 1 Feb 2011 05:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 cSvLpsdMfEph for ; Tue, 1 Feb 2011 05:11:01 -0800 (PST) Received: from mail.us.es (mail.us.es [193.147.175.20]) by core3.amsl.com (Postfix) with ESMTP id 898723A6CCD for ; Tue, 1 Feb 2011 05:11:00 -0800 (PST) Received: (qmail 1292 invoked from network); 1 Feb 2011 14:14:16 +0100 Received: from unknown (HELO us.es) (192.168.2.13) by us.es with SMTP; 1 Feb 2011 14:14:16 +0100 Received: (qmail 10471 invoked by uid 507); 1 Feb 2011 13:14:14 -0000 Received: from 127.0.0.1 by antivirus3 (envelope-from , uid 501) with qmail-scanner-2.08 (clamdscan: 0.96.5/12599. Clear:RC:1(127.0.0.1):. Processed in 0.0396 secs); 01 Feb 2011 13:14:14 -0000 Received: from unknown (HELO antivirus3) (127.0.0.1) by us.es with SMTP; 1 Feb 2011 13:14:14 -0000 Received: from 192.168.1.13 (192.168.1.13) by antivirus3 (F-Secure/fsigk_smtp/403/antivirus3); Tue, 01 Feb 2011 14:14:14 +0100 (CET) X-Virus-Status: clean(F-Secure/fsigk_smtp/403/antivirus3) Received: (qmail 3478 invoked from network); 1 Feb 2011 14:14:14 +0100 Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 1 Feb 2011 14:14:14 +0100 Received: from [193.147.162.138] (adriano.us.es [193.147.162.138]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p11DEE5a023123; Tue, 1 Feb 2011 14:14:14 +0100 Message-ID: <4D48077F.1090007@trajano.us.es> Date: Tue, 01 Feb 2011 14:15:43 +0100 From: =?ISO-8859-1?Q?Javi_Mu=F1oz?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pwe3@ietf.org References: <4D4369B5.9010102@trajano.us.es> <4D43DE5C.4090008@cisco.com> <4D440389.9040405@trajano.us.es> In-Reply-To: <4D440389.9040405@trajano.us.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PWE3] TDMPW and MeGaCo/SDP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 13:11:05 -0000 That's right, but it is necessary to define it. Does any working group, as mmusic, not plan to define it in collaboration with PWE3? Normally, each transport proposal includes SDP extensions it needs. For instance: + IETF RFC4733 (RTP Payload for tones): codecs "telephone-event" (a=rtpmap:100 telephone-event/8000) and "tone" (a=rtpmap:101 tone/8000) + IETF RFC4734 (Events for Modem signals): codes (a=fmtp:101 0-15,32-41,43,46,48-49,52-68) + ITU-T V.152 (VBDoIP): clausule 7.1 (attribute "a=gpmd") + ITU-T T.38: Annex D and E (protocol "udptl" and "tcptl") + ITU-T V.150.1: Annex E (attribute and codec "a=sprtmap: v150mr/8000") + ITU-T V.151: Annex C (codec T.140: "a=rtpmap: t140c/8000") ... So, I think it would be logical that the SDP extensions needed to describe PWs were done by a PW document. For instance, we may propose any like this: m=audio RTP/AVP a=rtpmap: TDMoIP/8000 Would it be necessary to indicate to the Media Gateway other PW parameters such as?: a=pw:Payload_Type (SAToP, CESoPSN, TDMoIP_AAL1, TDMoIP_AAL2) a=pw:PW_Identifier or, is it enough to negotiate them by the PW control plane? Thanks Javier Muñoz > > > El 29/01/2011 10:31, Stewart Bryant escribió: >> That is outside the scope of the PW. >> >> The NSP (specifically excluded from the domain of the PW) would need >> to handle that. >> >> Stewart >> >> On 29/01/2011 01:13, Javi wrote: >>> Assuming the next situation: >>> >>> ISDN Terminal 1 - MG1 - [IP network] - MG2 - ISDN Terminal 2 >>> >>> where the MGs (Media Gateway) are controlled by a MGC (Media Gateway >>> Controller) via MeGaCo[H.248.1]. >>> >>> [ITU-T Y.2262 / Annex IV] proposses that MGs may transport ISDN >>> B-channels over the IP network: >>> >>> + By a single RTP session (when monochannels ISDN services) >>> >>> + Or by TDMoIP (= UDP TDMPWs), when multichannels ISDN services. >>> >>> >>> How may MGC indicate to the MG that it uses PWs at the IP termination? >>> >>> It may be done by MeGaCo, using SDP[RFC4566] at Local/Remote >>> descriptors. However, how may be that SDP description of TDMPWs? >>> >>> Thanks, >>> >>> Javier Muñoz >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> >> >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From yaakov_s@rad.com Tue Feb 1 07:50:10 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81E0B3A6C1D for ; Tue, 1 Feb 2011 07:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWdlEIrMKZ9B for ; Tue, 1 Feb 2011 07:50:09 -0800 (PST) Received: from antivir1.rad.co.il (antivir1.rad.co.il [62.0.23.193]) by core3.amsl.com (Postfix) with ESMTP id 506313A6AC9 for ; Tue, 1 Feb 2011 07:50:08 -0800 (PST) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir1.rad.co.il with ESMTP; 01 Feb 2011 17:53:24 +0200 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 1 Feb 2011 17:53:24 +0200 Received: from EXRAD5.ad.rad.co.il ([fe80::ec3e:feb5:8bef:e3ba]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Tue, 1 Feb 2011 17:53:24 +0200 From: Yaakov Stein To: Javi , "pwe3@ietf.org" Thread-Topic: [PWE3] TDMPW and MeGaCo/SDP Thread-Index: AQHLv1HJ/2+hqZZkjUml4mRXd7ggj5PnjlkAgAAsUYCABRWpoA== Date: Tue, 1 Feb 2011 15:53:23 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903CDC087@EXRAD5.ad.rad.co.il> References: <4D4369B5.9010102@trajano.us.es> <4D43DE5C.4090008@cisco.com> <4D440389.9040405@trajano.us.es> In-Reply-To: <4D440389.9040405@trajano.us.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.37] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PWE3] TDMPW and MeGaCo/SDP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 15:50:10 -0000 Javi Can you explain what you think needs defining via SDP here ? The PW between your MGs is completely transparent to the MGs (logically, your MGs are connected via a TDM interface) and the MGC should not be meddling with its parameters at all. You examples of carrying tones or VBD over RTP are not analogous, as here the PW is providing the transport BELOW the logical flow, not a feature being carried OVER the RTP transport. Y(J)S -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Jav= i Sent: Saturday, January 29, 2011 14:10 To: pwe3@ietf.org Subject: Re: [PWE3] TDMPW and MeGaCo/SDP Possible, but it is necessary to define it. No working group, as mmusic, plans to define it in collaboration with PWE3? Normally, each transport proposal includes SDP extensions it needs. For=20 instance: + IETF RFC4733 (RTP Payload for tones): codecs "telephone-event"=20 (a=3Drtpmap:100 telephone-event/8000) and "tone" (a=3Drtpmap:101 tone/8000) + IETF RFC4734 (Events for Modem signals): codes (a=3Dfmtp:101=20 0-15,32-41,43,46,48-49,52-68) + ITU-T V.152 (VBDoIP): clausule 7.1 (attribute "a=3Dgpmd") + ITU-T T.38: Annex D and E (protocol "udptl" and "tcptl") + ITU-T V.150.1: Annex E (attribute and codec "a=3Dsprtmap:= =20 v150mr/8000") + ITU-T V.151: Annex C (codec T.140: "a=3Drtpmap: t140c/8000= ") ... So, I think it would be logical that the SDP extensions needed to=20 describe PWs weredone by a PW document. Thanks Javier Mu=F1oz El 29/01/2011 10:31, Stewart Bryant escribi=F3: > That is outside the scope of the PW. > > The NSP (specifically excluded from the domain of the PW) would need=20 > to handle that. > > Stewart > > On 29/01/2011 01:13, Javi wrote: >> Assuming the next situation: >> >> ISDN Terminal 1 - MG1 - [IP network] - MG2 - ISDN Terminal 2 >> >> where the MGs (Media Gateway) are controlled by a MGC (Media Gateway=20 >> Controller) via MeGaCo[H.248.1]. >> >> [ITU-T Y.2262 / Annex IV] proposses that MGs may transport ISDN=20 >> B-channels over the IP network: >> >> + By a single RTP session (when monochannels ISDN services) >> >> + Or by TDMoIP (=3D UDP TDMPWs), when multichannels ISDN services. >> >> >> How may MGC indicate to the MG that it uses PWs at the IP termination? >> >> It may be done by MeGaCo, using SDP[RFC4566] at Local/Remote=20 >> descriptors. However, how may be that SDP description of TDMPWs? >> >> Thanks, >> >> Javier Mu=F1oz >> _______________________________________________ >> 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 Alexander.Vainshtein@ecitele.com Tue Feb 1 07:53:27 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008F43A6C1A for ; Tue, 1 Feb 2011 07:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.303, 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 BkEF-mpbj+4L for ; Tue, 1 Feb 2011 07:53:25 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 161663A6AC9 for ; Tue, 1 Feb 2011 07:53:24 -0800 (PST) X-AuditID: 93eaf2e7-b7bb0ae000002499-f7-4d482d3a2b47 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id BD.3A.09369.A3D284D4; Tue, 1 Feb 2011 17:56:42 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 1 Feb 2011 17:58:11 +0200 From: Alexander Vainshtein To: Yaakov Stein , Javi Date: Tue, 1 Feb 2011 17:56:38 +0200 Thread-Topic: [PWE3] TDMPW and MeGaCo/SDP Thread-Index: AQHLv1HJ/2+hqZZkjUml4mRXd7ggj5PnjlkAgAAsUYCABRWpoIAAAayA Message-ID: References: <4D4369B5.9010102@trajano.us.es> <4D43DE5C.4090008@cisco.com> <4D440389.9040405@trajano.us.es> <07F7D7DED63154409F13298786A2ADC903CDC087@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC903CDC087@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAARdDr2o= Cc: "pwe3@ietf.org" Subject: Re: [PWE3] TDMPW and MeGaCo/SDP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 15:53:27 -0000 Yaakov, Javi, and all, I concur with Yaakov. TDM PWs should not be involved in the MG signaling. Regards, Sasha -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaa= kov Stein Sent: Tuesday, February 01, 2011 5:53 PM To: Javi; pwe3@ietf.org Subject: Re: [PWE3] TDMPW and MeGaCo/SDP Javi Can you explain what you think needs defining via SDP here ? The PW between your MGs is completely transparent to the MGs (logically, your MGs are connected via a TDM interface) and the MGC should not be meddling with its parameters at all. You examples of carrying tones or VBD over RTP are not analogous, as here the PW is providing the transport BELOW the logical flow, not a feature being carried OVER the RTP transport. Y(J)S -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Jav= i Sent: Saturday, January 29, 2011 14:10 To: pwe3@ietf.org Subject: Re: [PWE3] TDMPW and MeGaCo/SDP Possible, but it is necessary to define it. No working group, as mmusic, plans to define it in collaboration with PWE3? Normally, each transport proposal includes SDP extensions it needs. For=20 instance: + IETF RFC4733 (RTP Payload for tones): codecs "telephone-event"=20 (a=3Drtpmap:100 telephone-event/8000) and "tone" (a=3Drtpmap:101 tone/8000) + IETF RFC4734 (Events for Modem signals): codes (a=3Dfmtp:101=20 0-15,32-41,43,46,48-49,52-68) + ITU-T V.152 (VBDoIP): clausule 7.1 (attribute "a=3Dgpmd") + ITU-T T.38: Annex D and E (protocol "udptl" and "tcptl") + ITU-T V.150.1: Annex E (attribute and codec "a=3Dsprtmap:= =20 v150mr/8000") + ITU-T V.151: Annex C (codec T.140: "a=3Drtpmap: t140c/8000= ") ... So, I think it would be logical that the SDP extensions needed to=20 describe PWs weredone by a PW document. Thanks Javier Mu=F1oz El 29/01/2011 10:31, Stewart Bryant escribi=F3: > That is outside the scope of the PW. > > The NSP (specifically excluded from the domain of the PW) would need=20 > to handle that. > > Stewart > > On 29/01/2011 01:13, Javi wrote: >> Assuming the next situation: >> >> ISDN Terminal 1 - MG1 - [IP network] - MG2 - ISDN Terminal 2 >> >> where the MGs (Media Gateway) are controlled by a MGC (Media Gateway=20 >> Controller) via MeGaCo[H.248.1]. >> >> [ITU-T Y.2262 / Annex IV] proposses that MGs may transport ISDN=20 >> B-channels over the IP network: >> >> + By a single RTP session (when monochannels ISDN services) >> >> + Or by TDMoIP (=3D UDP TDMPWs), when multichannels ISDN services. >> >> >> How may MGC indicate to the MG that it uses PWs at the IP termination? >> >> It may be done by MeGaCo, using SDP[RFC4566] at Local/Remote=20 >> descriptors. However, how may be that SDP description of TDMPWs? >> >> Thanks, >> >> Javier Mu=F1oz >> _______________________________________________ >> 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 javi@trajano.us.es Tue Feb 1 09:09:58 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F194C3A6CCE for ; Tue, 1 Feb 2011 09:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_34=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 sG-zxAX+Ok9e for ; Tue, 1 Feb 2011 09:09:57 -0800 (PST) Received: from mail.us.es (mail.us.es [193.147.175.20]) by core3.amsl.com (Postfix) with ESMTP id 9F0033A6959 for ; Tue, 1 Feb 2011 09:09:56 -0800 (PST) Received: (qmail 32254 invoked from network); 1 Feb 2011 18:13:13 +0100 Received: from unknown (HELO us.es) (192.168.2.11) by us.es with SMTP; 1 Feb 2011 18:13:13 +0100 Received: (qmail 20557 invoked by uid 507); 1 Feb 2011 17:13:12 -0000 Received: from 127.0.0.1 by antivirus1 (envelope-from , uid 501) with qmail-scanner-2.08 (clamdscan: 0.96.5/12600. Clear:RC:1(127.0.0.1):. Processed in 0.037868 secs); 01 Feb 2011 17:13:12 -0000 Received: from unknown (HELO antivirus1) (127.0.0.1) by us.es with SMTP; 1 Feb 2011 17:13:12 -0000 Received: from 192.168.1.13 (192.168.1.13) by antivirus1 (F-Secure/fsigk_smtp/403/antivirus1); Tue, 01 Feb 2011 18:13:12 +0100 (CET) X-Virus-Status: clean(F-Secure/fsigk_smtp/403/antivirus1) Received: (qmail 10035 invoked from network); 1 Feb 2011 18:13:12 +0100 Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 1 Feb 2011 18:13:12 +0100 Received: from [192.168.1.40] (125.Red-81-44-191.dynamicIP.rima-tde.net [81.44.191.125]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p11HDBKc028927; Tue, 1 Feb 2011 18:13:11 +0100 Message-ID: <4D483F19.9010708@trajano.us.es> Date: Tue, 01 Feb 2011 18:12:57 +0100 From: Javi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "pwe3@ietf.org" References: <4D4369B5.9010102@trajano.us.es> <4D43DE5C.4090008@cisco.com> <4D440389.9040405@trajano.us.es> <07F7D7DED63154409F13298786A2ADC903CDC087@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC903CDC087@EXRAD5.ad.rad.co.il> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [PWE3] TDMPW terminated at terminal equipment 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, 01 Feb 2011 17:09:58 -0000 Assuming the next edge to edge comunication ISDN TE <--- [D/B channels] ---> AGW <----[NGN (IP) network ]----> NGN TE * TE: Terminal equipment * AGW: Access Gateway [ITU-T Y.2262/Appendix IV] propose: a) ISDN Monorate bearer services (1 × 64-kbit/s): may be emulated by a single RTP session. ISDN TE <--- [1xB channel] ---> AGW <----[RTP session]----> NGN TE b) ISDN Multirate bearer services (N x 64-kbit/s): may be emulated by TDMoIP[Y.1453] (=UDP/IP TDMPWs). We may suppose the next scheme: ISDN TE <--- [NxB channels] ---> AGW <----[TDMPW]----> NGN TE If it was so, "NGN TE" would be implement the PW stack protocol: TDMPW Payload Type CW RTP UDP IP Here, AGW and NGN TE would be PEs (at L2TPv3 notation: AGW=LCCE LAC; NGN TE=LCCE LNS). Is it right that a terminal equipment (TE NGN) is a PW edge?. I think it is not good choice. Then, which would be the right scheme for "b)"? Javier Muñoz From Alexander.Vainshtein@ecitele.com Tue Feb 1 09:48:32 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D67D3A6D87 for ; Tue, 1 Feb 2011 09:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_34=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 9fIlkjGXenn8 for ; Tue, 1 Feb 2011 09:48:31 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 0C1623A6959 for ; Tue, 1 Feb 2011 09:48:30 -0800 (PST) X-AuditID: 93eaf2e7-b7bb0ae000002499-4b-4d4848354731 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id A4.AC.09369.538484D4; Tue, 1 Feb 2011 19:51:49 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 1 Feb 2011 19:53:18 +0200 From: Alexander Vainshtein To: Javi Date: Tue, 1 Feb 2011 19:51:42 +0200 Thread-Topic: [PWE3] TDMPW terminated at terminal equipment Thread-Index: AcvCM1NNRqpZK6otQF+2WX9iF7b9IQABJTqw Message-ID: References: <4D4369B5.9010102@trajano.us.es> <4D43DE5C.4090008@cisco.com> <4D440389.9040405@trajano.us.es> <07F7D7DED63154409F13298786A2ADC903CDC087@EXRAD5.ad.rad.co.il> <4D483F19.9010708@trajano.us.es> In-Reply-To: <4D483F19.9010708@trajano.us.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: "pwe3@ietf.org" Subject: Re: [PWE3] TDMPW terminated at terminal equipment 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, 01 Feb 2011 17:48:32 -0000 Javi, and all, You refer to an ITU-T standard that proposes usage of TDM PWs but referenc= es yet another ITU-T standard. To the best of my recollection, ITU-T has not ever asked PWE3 to review thi= s proposal (whether this was necessary is a different issue). So I'd say that your questions should be addressed to the ITU-T Question/St= udy Group that has created the ITU standard in question. Regards, Sasha -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Jav= i Sent: Tuesday, February 01, 2011 7:13 PM To: pwe3@ietf.org Subject: [PWE3] TDMPW terminated at terminal equipment Assuming the next edge to edge comunication ISDN TE <--- [D/B channels] ---> AGW <----[NGN (IP) network ]----> NGN TE * TE: Terminal equipment * AGW: Access Gateway [ITU-T Y.2262/Appendix IV] propose: a) ISDN Monorate bearer services (1 =D7 64-kbit/s): may be emulated by a=20 single RTP session. ISDN TE <--- [1xB channel] ---> AGW <----[RTP session]----> NGN TE b) ISDN Multirate bearer services (N x 64-kbit/s): may be emulated by=20 TDMoIP[Y.1453] (=3DUDP/IP TDMPWs). We may suppose the next scheme: ISDN TE <--- [NxB channels] ---> AGW <----[TDMPW]----> NGN TE If it was so, "NGN TE" would be implement the PW stack protocol: TDMPW Payload Type CW RTP UDP IP Here, AGW and NGN TE would be PEs (at L2TPv3 notation: AGW=3DLCCE LAC; NGN= =20 TE=3DLCCE LNS). Is it right that a terminal equipment (TE NGN) is a PW edge?. I think it=20 is not good choice. Then, which would be the right scheme for "b)"? Javier Mu=F1oz _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From nick.delregno@verizon.com Wed Feb 2 05:40:05 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B82B3A6BF8; Wed, 2 Feb 2011 05:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.082, 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 DFs9RlqHoMDT; Wed, 2 Feb 2011 05:39:59 -0800 (PST) Received: from ashesmtp01.verizonbusiness.com (ashesmtp01.verizonbusiness.com [198.4.8.163]) by core3.amsl.com (Postfix) with ESMTP id AA4133A6BAB; Wed, 2 Feb 2011 05:39:59 -0800 (PST) Received: from pdcismtp02.vzbi.com ([unknown] [166.40.77.70]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LFZ001VDSS68890@firewall.verizonbusiness.com>; Wed, 02 Feb 2011 13:43:19 +0000 (GMT) Received: from pdcismtp02.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LFZ00J2NSS6FA00@pdcismtp02.vzbi.com>; Wed, 02 Feb 2011 13:43:18 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([unknown] [153.39.68.168]) by pdcismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LFZ00JCMSS6E400@pdcismtp02.vzbi.com>; Wed, 02 Feb 2011 13:43:18 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 02 Feb 2011 13:43:18 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01CBC2DF.25B422D5" Date: Wed, 02 Feb 2011 13:43:20 +0000 Message-id: <14584D6EE26B314187A4F68BA2060600067709F5@ASHEVS008.mcilink.com> In-reply-to: <14584D6EE26B314187A4F68BA206060005DB543A@ASHEVS008.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: REMINDER: PW / VCCV User Implementation Survey Thread-index: Act8YpSEMMoOD4/+SCeRBwpsUYLmAgTfklMQDL9wpzA= References: <14584D6EE26B314187A4F68BA206060005AE91E1@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA206060005DB543A@ASHEVS008.mcilink.com> From: "Delregno, Christopher N (Nick DelRegno)" To: pwe3 , mpls@ietf.org, l2vpn@ietf.org X-OriginalArrivalTime: 02 Feb 2011 13:43:18.0431 (UTC) FILETIME=[262F22F0:01CBC2DF] Subject: [PWE3] REMINDER: PW / VCCV User Implementation Survey 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, 02 Feb 2011 13:40:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC2DF.25B422D5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, we still only have 6 responses to the VCCV User Survey. Time is running out. The deadline for submissions is February 25th. =20 It is important that we get as many participants as possible to ensure fair representation in any future PW Control Word and VCCV related work in the PWE3 working group. =20 Thanks, Nick =20 =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=3D=3D=3D=3D=3D=3D =20 All: =20 Per the direction of the PWE3 working group, beginning in IETF77 and reinforced in IETF78, the PWE3 working group is conducting a Service Provider implementation survey related to: =20 - Pseudowire Encapsulations - Control Word Support - Control Word Use - VCCV Control Channel Support - VCCV Control Channel Use =20 http://www.surveymonkey.com/s/pwe3 =20 This is a short survey directed toward Service Providers who currently operate networks using any of the defined PWE3 encapsulations. The results of this survey will be used to determine the direction of the Control Word support in current and future encapsulations as well as solutions to VCCV interoperability challenges. =20 We sincerely urge all service providers to participate. We ask that all equipment providers encourage participation by their Service Provider customers. The more feedback we receive, the better view of the existing network we can have on which to base going-forward direction. =20 If you have any questions, regarding the survey, especially of a technical nature, please contact me. If you have non-technical questions, feel free to reach out to the PWE3 WG chairs and myself. =20 The results of the survey will be aggregated and shared at a high level. No low-level details of network implementations will be shared. All participant's responses will remain private, if not anonymous. =20 All responses will require a valid email address to help ensure the survey's validity. =20 Thanks, Nick =20 Christopher N. "Nick" DelRegno, PMTS CNT, Ethernet Network Architecture & Design 400 International Pkwy Richardson, TX 75081 Tel: 972-729-3411 Email: Nick.DelRegno@verizon.com =20 ------_=_NextPart_001_01CBC2DF.25B422D5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks, we = still only have 6 responses to the VCCV User Survey.  Time is = running out.  The deadline for submissions is February = 25th.

 

It is = important that we get as many participants as possible to ensure fair = representation in any future PW Control Word and VCCV related work in = the PWE3 working group.

 

Thanks,

Nick

 

=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=3D=3D=3D=3D=3D=3D

 

All:

 

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

 

-          = Pseudowire Encapsulations

-          = Control Word Support

-          = Control Word Use

-          = VCCV Control Channel Support

-          = VCCV Control Channel Use

 

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

 

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

 

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

 

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

 

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

 

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

 

Thanks,

Nick

 

Christopher N. “Nick” DelRegno, = PMTS

CNT, Ethernet Network Architecture & = Design

400 International Pkwy

Richardson, TX  = 75081

Tel:  972-729-3411

Email:  = Nick.DelRegno@verizon.com

 

------_=_NextPart_001_01CBC2DF.25B422D5-- From Robert.Rennison@ecitele.com Wed Feb 2 07:47:14 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92F783A6CD9 for ; Wed, 2 Feb 2011 07:47:14 -0800 (PST) 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 pURK2Jk2gbur for ; Wed, 2 Feb 2011 07:47:12 -0800 (PST) Received: from uspitbmg01.ecitele.com (uspitbmg01-out.ecitele.com [63.94.127.136]) by core3.amsl.com (Postfix) with ESMTP id 840C33A6C25 for ; Wed, 2 Feb 2011 07:47:12 -0800 (PST) X-AuditID: 3f5e7f87-b7b42ae000002f5c-08-4d49a571aadd Received: from uspitexch01.ecitele.com ( [10.0.0.71]) by uspitbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id D6.30.12124.175A94D4; Wed, 2 Feb 2011 13:41:53 -0500 (EST) Received: from USPITMAIL01.ecitele.com ([10.0.0.82]) by uspitexch01.ecitele.com ([10.0.0.71]) with mapi; Wed, 2 Feb 2011 10:52:03 -0500 From: Robert Rennison To: "pwe3@ietf.org" Date: Wed, 2 Feb 2011 10:52:02 -0500 Thread-Topic: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt Thread-Index: Act6rtHV8qWlypdjRSyGPTWm7kuiSgAATeAgDyUlWVAAAHeLAAGWdAtAAVPRajA= Message-ID: <786AD2EC3D80A1428B921CDC9BE9EE54603DDB45A2@USPITMAIL01.ecitele.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Muley, Praveen V \(Praveen\)" , "Aissaoui, Mustapha \(Mustapha\)" Subject: [PWE3] FW: WG last call for draft-ietf-pwe3-redundancy-bit-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: Wed, 02 Feb 2011 15:47:14 -0000 All, Mustapha and I recently had some more correspondence on the redundancy-bit-= draft. Matthew asked that since this was in a last call if we could copy the comments to the list. First Mustapha's response to me. Then in a follow up email, my response to = Mustapha. Cheers Rob Rennison ------------------------------------------------------------------ -----Original Message----- From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel-lucen= t.com] Sent: Friday, January 28, 2011 5:30 PM To: Robert Rennison Cc: Muley, Praveen V (Praveen); Bocci, Matthew (Matthew); Aissaoui, Mustaph= a (Mustapha) Subject: RE: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt Hi Rob, See below for some elements of response to your comments indexed by "MA>". Let me know what you think. Regards, Mustapha. -----Original Message----- From: Aissaoui, Mustapha (Mustapha) Sent: Tuesday, January 18, 2011 2:35 PM To: Robert Rennison Cc: Muley, Praveen V (Praveen); Bocci, Matthew (Matthew) Subject: RE: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt Hi Rob, I apologize but I did not have a chance to look into them with more details= . As you guessed, I was swamped with work lately so the update of the IETF = drafts took a hit :-) I will get back to you shortly with my proposal how to address them. Thank you again for the review. Mustapha. -----Original Message----- From: Robert Rennison [mailto:Robert.Rennison@ecitele.com] Sent: Tuesday, January 18, 2011 2:29 PM To: Aissaoui, Mustapha (Mustapha) Cc: Muley, Praveen V (Praveen) Subject: FW: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt Mustapha, I'm not sure if you have tried to follow up with me and I've perhaps lost o= r mis-filtered your email or if like many you were too swamped and this fel= l into the cracks. I should have "pinged" you sooner. Hopefully we can discuss some of the points I made. I've pasted them in this email at the very bottom for easy reference. Cheers Rob Rennison -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ais= saoui, Mustapha (Mustapha) Sent: Tuesday, November 02, 2010 1:25 PM To: Andrew G. Malis; pwe3@ietf.org Subject: Re: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt Thanks Andy. We will with Rob to address his comments. Mustapha. -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of And= rew G. Malis Sent: Tuesday, November 02, 2010 12:54 PM To: pwe3@ietf.org Subject: Re: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt This completes the working group last call, with one set of comments receiv= ed. Authors, please work with Rob to resolve the comments and post an updat= ed draft to be forwarded to the IESG. Thanks, Andy On Tue, Oct 19, 2010 at 2:31 PM, Andrew G. Malis wrote: > This email starts a two week working group last call on > draft-ietf-pwe3-redundancy-bit-03.txt. > > Note that changes may be required to this draft as a result of the > comments received on draft-ietf-pwe3-redundancy-03.txt. If so, I would > like to ask the authors to post these changes to the pwe3 list as last > call comments on draft-ietf-pwe3-redundancy-bit-03.txt, and the actual > changes will be made following the end of the last call. > > The draft can be found at > http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-bit-03 > > Please post any comments to the PWE3 list. > > This WG last call closes on Tuesday, November 2. > > Note that since Matthew is a co-author of this document, Andy will act > as document shepherd. > > Regards, > Matthew and Andy > _______________________________________________ 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 ----------------------- Praveen, Mustapha, Lots of very useful functionality can be added with the use of this additio= nal bit, and its companion switchover bit. Overall a nicely written document, I appreciated the examples in the append= ix to illustrate how this could be used. My main comments regard the descriptions of what the active/standby bit rep= resents. For a given PW there are actually two states. The configured/ desired state= and the actual operational state. In some cases the draft could be perhaps= more explicit in pointing this out or pointing out whether we are signalli= ng and actual vs. a desired state, since the usage varies depending on the = mode. MA> Yes, we should clarify that. I would however like to keep referring to = the new bit as the "preferential forwarding status bit" because it has been= there for years and in implementations. I know that in Master/Slave mode i= t is not exactly a preference as you mentioned further below but I think th= is is further explained in that section. See below for the proposed changes= to the state definitions. --------------------------------------------------------- Section 5.1 ----------- For example the draft states " 5.1. Independent Mode: PW endpoint nodes independently select which PW they intend to make active and which PWs they intend to make standby. They advertise the corresponding Active/Standby forwarding state for each PW. Each PW endpoint compares local and remote status and uses the PW that is operationally UP at both endpoints and that shows Active states at both the local and remote endpoint. " I'd suggest changing this to .... They advertizes the corresponding _desir= ed_ Active/Standby Forwarding states.... Upon first reading the wording of corresponding had me thinking they advert= ized the states corresponding to their actual operations states not to thei= r desired states. One quickly figures out thing would not work in this case= and hence the meaning must be of the corresponding desired states but I'd= like to save this headache for future readers. MA> Here is my proposal for this paragraph: " 5.1. Independent Mode: PW endpoint nodes independently select which PW they intend to make active = and which PWs they intend to make standby. They advertise the corresponding= Active/Standby preferential forwarding status for each PW. Each PW endpoin= t compares local and remote status bits and uses the PW that is operational= ly UP at both endpoints and that advertised Active preferential forwarding = status at both the local and remote endpoints. In this mode of operation, the preferential forwarding status indicates the= prefered forwarding state of each endpoint and the actual forwarding state= of the PW is the result of the comparison of the local and remote forwardi= ng status bits. " --------------------------------------------------------- The definition following is in the same section 5.1 and is somewhat uncle= ar/inaccurate , The draft states " o Active State A PW is considered to be in Active state when the PW labels are exchanged between its two endpoints, and the status bits exchanged between the endpoints indicate the PW is UP and Active at both endpoints. In this state user traffic can flow over the PW in both directions. " 1. It's self referential/recursive, stating that Active state (of the= PW) depends on both ends indicating Active state (of the PW) 2. This is inaccurate since the status bits are not indicating that th= e PW is UP and Active at both ends they are really indicating that the PW i= s UP and each end has a desire or preference for the PW to be active. If the wording is changed to reflect the point made in #2 then the objecti= on raised in #1 is retracted since the definition is no longer recursive. MA> Making the same change here would give this: " o Active State A PW is considered to be in Active state when the PW labels are exchanged b= etween its two endpoints and the status bits exchanged between the endpoint= s indicate the PW is operationally UP and its preferential forwarding statu= s is Active at both endpoints. In this state user traffic can flow over the= PW in both directions. " Also, making the change to the definition of the Standby state would yield = this: " o Standby State A PW is considered to be in Standby state when the PW labels are exchanged = between its two endpoints, but the status bits exchanged indicate the PW pr= eferential forwarding status is Standby at one or both endpoints. In this s= tate the endpoints MUST NOT forward data traffic over the PW but MAY allow = PW OAM packets, e.g., VCCV, to be sent and received in order to test the li= veliness of standby PWs. If the PW is a spoke in H-VPLS, any MAC addresses = learned via the PW SHOULD be flushed when it transitions to Standby state a= ccording to the procedures in RFC4762 [3] and [9]. " Finally, here are the changes to the introduction and the state definitions= for the Master/Slave mode: " 5.2. Master/Slave Mode: One endpoint node of the redundant set of PWs is designated the Master and = is responsible for selecting which PW both endpoints must use to forward us= er traffic. The Master indicates the forwarding state in the Active/Standby status bit.= The other endpoint node, the Slave, MUST follow the decision of the Master= node based on the received status bits. In other words, the preferential f= orwarding status bit sent by the Master node indicates the actual forwardin= g state of the PW at the Master node. " " o Active State A PW is considered to be in Active state when the PW labels are exchanged b= etween its two endpoints, and the status bits exchanged between the endpoin= ts indicate the PW is UP at both endpoints, and the preferential forwarding= status at the Master endpoint is Active. In this state user traffic can fl= ow over the PW in both directions. o Standby State A PW is considered to be in Standby state when the PW labels are exchanged = between its two endpoints, and the status bits exchanged between the endpoi= nts indicate the preferential forwarding status at the Master endpoint is S= tandby. In this state the endpoints MUST NOT forward data traffic over the = PW but MAY allow PW OAM packets, e.g., VCCV, to be sent and received. If th= e PW is a spoke in H-VPLS, any MAC addresses learned via the PW SHOULD be f= lushed when it transitions to Standby state according to the procedures in = RFC4762 [3] and [9]. " --------------------------------------------------------- Section 5.2 Master/Slave mode is much clearer about what is being signaled= . Section 6 ---------- In Section 6 PW State Transition Signalling Procedures first paragraph " 6. PW State Transition Signaling Procedures This section describes the extensions to PW status signaling and the pr= ocessing rules for these extensions. It defines a new "PW preferential forwarding" bit Status Code that is to be used with the P= W Status TLV specified in RFC 4447 [2]. The PW preferential forwarding bit, when set, is used to signal the Standby state of the P= W by one PE to the far end PE. " The last sentence is inaccurate since this statement is not mode specific, = it's true for the Master end of Master/Slave but not in general. Perhaps change to The PW preferential forwarding bit, when set, is used to signal either the = Preferred or Actual Active/Standby state of the PW by one PE to the far end PE. The actual semantics of the Value being s= ignaled vary according to whether the PW is acting in a Master/Slave or ind= ependent mode. MA> Good suggestion. I included this change. ----------------------------------------------- Section 6.2.1 State Machine ----------------------------- It may be clearer to have two separate state machines one for Active/Standb= y and one for Independent mode. Regarding the existing single state machine it's not clear what the state t= ransition is for a PW endpoint in independent mode. MA> The state machine is exclusively for the Master/Slave mode as indicated= by its sub-section numbering. Is it to be assumed that all of these event block apply to an endpoint in i= ndependent mode ? MA> One can attempt to write a similar state machine for the independent mo= de. But it will be fairly simple since the behavior is symmetric. The Maste= r/Slave is asymmetric. Under The active State 2nd event, "Receive preferential forwarding bit se= t (slave) Action: Stop forwarding over PW" If we were in independent mode there would be additional work to determine = if there were any alternative PWs with PW signaled at both ends, i.e. run t= he algorithm for picking a new Active PW. This is not called out. MA> In fact, that algorithm will also exist in the Master/Slave mode. The s= lave can see more than one PW with Active state and it must handle it prope= rly. It is not shown for simplicity. Editorial/ Nits ---------------- The name "preferential forwarding status bit" is misleading since in the M= aster mode It's not indicating the preferred PW to forward on, It's an or= der, this is the one to use. While in Independent mode it is indicating a p= reference. Perhaps dropping the word preferential and calling it the "forwarding stat= us bit" maybe clearer. MA> As explained earlier, I would like to keep it. Consider consistent use of Active vs. active. MA> Will do, thanks. Cheers Rob Rennison > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of Andrew G. Malis > Sent: Tuesday, October 19, 2010 2:31 PM > To: pwe3@ietf.org > Subject: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt > > This email starts a two week working group last call on > draft-ietf-pwe3-redundancy-bit-03.txt. > > Note that changes may be required to this draft as a result of the > comments received on draft-ietf-pwe3-redundancy-03.txt. If so, I would > like to ask the authors to post these changes to the pwe3 list as last > call comments on draft-ietf-pwe3-redundancy-bit-03.txt, and the actual > changes will be made following the end of the last call. > > The draft can be found at > http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-bit-03 > > Please post any comments to the PWE3 list. > > This WG last call closes on Tuesday, November 2. > > Note that since Matthew is a co-author of this document, Andy will act > as document shepherd. > > Regards, > Matthew and Andy > _______________________________________________ > 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 Robert.Rennison@ecitele.com Wed Feb 2 07:50:53 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80B5D3A6D1C for ; Wed, 2 Feb 2011 07:50:53 -0800 (PST) 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 317t1Dfbugq7 for ; Wed, 2 Feb 2011 07:50:51 -0800 (PST) Received: from uspitbmg01.ecitele.com (uspitbmg01-out.ecitele.com [63.94.127.136]) by core3.amsl.com (Postfix) with ESMTP id 1102C3A6D0B for ; Wed, 2 Feb 2011 07:50:50 -0800 (PST) X-AuditID: 3f5e7f87-b7b42ae000002f5c-32-4d49a64cea44 Received: from uspitexch01.ecitele.com ( [10.0.0.71]) by uspitbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 28.30.12124.C46A94D4; Wed, 2 Feb 2011 13:45:32 -0500 (EST) Received: from USPITMAIL01.ecitele.com ([10.0.0.82]) by uspitexch01.ecitele.com ([10.0.0.71]) with mapi; Wed, 2 Feb 2011 10:55:42 -0500 From: Robert Rennison To: "pwe3@ietf.org" Date: Wed, 2 Feb 2011 10:55:41 -0500 Thread-Topic: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt Thread-Index: Act6rtHV8qWlypdjRSyGPTWm7kuiSgAATeAgDyUlWVAAAHeLAAGWdAtAASK1X2AAMYbUUA== Message-ID: <786AD2EC3D80A1428B921CDC9BE9EE54603DDB45A4@USPITMAIL01.ecitele.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Aissaoui, Mustapha \(Mustapha\)" , "Muley, Praveen V \(Praveen\)" Subject: [PWE3] FW: WG last call for draft-ietf-pwe3-redundancy-bit-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: Wed, 02 Feb 2011 15:50:53 -0000 My Comments on Mustapha's comments. Looks like we are in sync. Cheers Rob -----Original Message----- From: Robert Rennison=20 Sent: Tuesday, February 01, 2011 12:05 PM To: 'Aissaoui, Mustapha (Mustapha)' Cc: Muley, Praveen V (Praveen); Bocci, Matthew (Matthew) Subject: RE: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt Mustapha, Thank you for understanding and addressing my comments, my comments on your= comments below preceded by [RobR] Cheers Rob Rennison On Tue, Oct 19, 2010 at 2:31 PM, Andrew G. Malis wrote: > This email starts a two week working group last call on=20 > draft-ietf-pwe3-redundancy-bit-03.txt. > > Note that changes may be required to this draft as a result of the=20 > comments received on draft-ietf-pwe3-redundancy-03.txt. If so, I would=20 > like to ask the authors to post these changes to the pwe3 list as last=20 > call comments on draft-ietf-pwe3-redundancy-bit-03.txt, and the actual=20 > changes will be made following the end of the last call. > > The draft can be found at > http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-bit-03 > > Please post any comments to the PWE3 list. > > This WG last call closes on Tuesday, November 2. > > Note that since Matthew is a co-author of this document, Andy will act=20 > as document shepherd. > > Regards, > Matthew and Andy > _______________________________________________ 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 ----------------------- Praveen, Mustapha, =20 Lots of very useful functionality can be added with the use of this additio= nal bit, and its companion switchover bit.=20 Overall a nicely written document, I appreciated the examples in the append= ix to illustrate how this could be used. My main comments regard the descriptions of what the active/standby bit rep= resents.=20 For a given PW there are actually two states. The configured/ desired state= and the actual operational state. In some cases the draft could be perhaps= more explicit in pointing this out or pointing out whether we are signalli= ng and actual vs. a desired state, since the usage varies depending on the = mode. MA> Yes, we should clarify that. I would however like to keep referring to = the new bit as the "preferential forwarding status bit" because it has been= there for years and in implementations. I know that in Master/Slave mode i= t is not exactly a preference as you mentioned further below but I think th= is is further explained in that section. See below for the proposed changes= to the state definitions. [RobR] I've grown used to the term preferential forwarding status bit, it's= also how I tend to think of it, since the majority of use-cases are in the= independent mode, so I agree, let's live with the slight inconsistency whe= n in Master/Slave mode. --------------------------------------------------------- Section 5.1 ----------- For example the draft states " 5.1. Independent Mode:=20 PW endpoint nodes independently select which PW they intend to make=20 active and which PWs they intend to make standby. They advertise the=20 corresponding Active/Standby forwarding state for each PW. Each PW=20 endpoint compares local and remote status and uses the PW that is=20 operationally UP at both endpoints and that shows Active states at=20 both the local and remote endpoint. " I'd suggest changing this to .... They advertizes the corresponding _desir= ed_ Active/Standby Forwarding states.... Upon first reading the wording of corresponding had me thinking they advert= ized the states corresponding to their actual operations states not to thei= r desired states. One quickly figures out thing would not work in this case= and hence the meaning must be of the corresponding desired states but I'd= like to save this headache for future readers. MA> Here is my proposal for this paragraph: " 5.1. Independent Mode: PW endpoint nodes independently select which PW they intend to make active = and which PWs they intend to make standby. They advertise the corresponding= Active/Standby preferential forwarding status for each PW. Each PW endpoin= t compares local and remote status bits and uses the PW that is operational= ly UP at both endpoints and that advertised Active preferential forwarding = status at both the local and remote endpoints.=20 In this mode of operation, the preferential forwarding status indicates the= prefered forwarding state of each endpoint and the actual forwarding state= of the PW is the result of the comparison of the local and remote forwardi= ng status bits. " [RobR] This looks good, much clearer (fix typo in preferred =3D=3D> preferr= ed). One subtle related point that is brought out in one of the examples, = PE-2 in Fig 15-1, but could perhaps be clarified here is that a given endpo= int _may_ choose to indicate active on all of its PWs and effectively let t= he far end pick which PW to make active. Just an observation/food for thoug= ht, could be left alone. --------------------------------------------------------- The definition following is in the same section 5.1 and is somewhat uncle= ar/inaccurate ,=20 The draft states " o Active State =20 A PW is considered to be in Active state when the PW labels are=20 exchanged between its two endpoints, and the status bits exchanged=20 between the endpoints indicate the PW is UP and Active at both=20 endpoints. In this state user traffic can flow over the PW in both=20 directions.=20 " 1. It's self referential/recursive, stating that Active state (of the PW) = depends on both ends indicating Active state (of the PW) 2. This is inaccurate since the status bits are not indicating that the PW = is UP and Active at both ends they are really indicating that the PW is UP = and each end has a desire or preference for the PW to be active. If the wording is changed to reflect the point made in #2 then the objecti= on raised in #1 is retracted since the definition is no longer recursive. MA> Making the same change here would give this: " o Active State =20 A PW is considered to be in Active state when the PW labels are exchanged b= etween its two endpoints and the status bits exchanged between the endpoint= s indicate the PW is operationally UP and its preferential forwarding statu= s is Active at both endpoints. In this state user traffic can flow over the= PW in both directions. " [RobR] Looks good. Also, making the change to the definition of the Standby state would yield = this: " o Standby State A PW is considered to be in Standby state when the PW labels are exchanged = between its two endpoints, but the status bits exchanged indicate the PW pr= eferential forwarding status is Standby at one or both endpoints. In this s= tate the endpoints MUST NOT forward data traffic over the PW but MAY allow = PW OAM packets, e.g., VCCV, to be sent and received in order to test the li= veliness of standby PWs. If the PW is a spoke in H-VPLS, any MAC addresses = learned via the PW SHOULD be flushed when it transitions to Standby state a= ccording to the procedures in RFC4762 [3] and [9]. " [RobR] Looks good. Finally, here are the changes to the introduction and the state definitions= for the Master/Slave mode: " 5.2. Master/Slave Mode: One endpoint node of the redundant set of PWs is designated the Master and = is responsible for selecting which PW both endpoints must use to forward us= er traffic. The Master indicates the forwarding state in the Active/Standby status bit.= The other endpoint node, the Slave, MUST follow the decision of the Master= node based on the received status bits. In other words, the preferential f= orwarding status bit sent by the Master node indicates the actual forwardin= g state of the PW at the Master node.=20 " [RobR] Looks good. " o Active State =20 A PW is considered to be in Active state when the PW labels are exchanged b= etween its two endpoints, and the status bits exchanged between the endpoin= ts indicate the PW is UP at both endpoints, and the preferential forwarding= status at the Master endpoint is Active. In this state user traffic can fl= ow over the PW in both directions. [RobR] Looks good. o Standby State A PW is considered to be in Standby state when the PW labels are exchanged = between its two endpoints, and the status bits exchanged between the endpoi= nts indicate the preferential forwarding status at the Master endpoint is S= tandby. In this state the endpoints MUST NOT forward data traffic over the = PW but MAY allow PW OAM packets, e.g., VCCV, to be sent and received. If th= e PW is a spoke in H-VPLS, any MAC addresses learned via the PW SHOULD be f= lushed when it transitions to Standby state according to the procedures in = RFC4762 [3] and [9]. " [RobR] Looks good. --------------------------------------------------------- Section 5.2 Master/Slave mode is much clearer about what is being signaled= . Section 6 ---------- In Section 6 PW State Transition Signalling Procedures first paragraph " 6. PW State Transition Signaling Procedures =20 This section describes the extensions to PW status signaling and the pr= ocessing rules for these extensions. It defines a new "PW =20 preferential forwarding" bit Status Code that is to be used with the P= W Status TLV specified in RFC 4447 [2]. The PW preferential=20 forwarding bit, when set, is used to signal the Standby state of the P= W by one PE to the far end PE. " The last sentence is inaccurate since this statement is not mode specific, = it's true for the Master end of Master/Slave but not in general. Perhaps change to =20 The PW preferential forwarding bit, when set, is used to signal either the = Preferred or Actual Active/Standby state of the PW by one PE to the far end PE. The actual semantics of the Value being s= ignaled vary according to whether the PW is acting in a Master/Slave or ind= ependent mode. MA> Good suggestion. I included this change. [RobR] Thanks ----------------------------------------------- Section 6.2.1 State Machine ----------------------------- It may be clearer to have two separate state machines one for Active/Standb= y and one for Independent mode. Regarding the existing single state machine it's not clear what the state t= ransition is for a PW endpoint in independent mode. MA> The state machine is exclusively for the Master/Slave mode as indicated= by its sub-section numbering. [RobR] I had not caught that subtlety, maybe make the title "Master/Slave = Mode State machine" One other minor point, within the description of the state machine the desc= ription uses the specific bit values i.e "Transmit PW preferential forwardi= ng bit set", whereas throughout the rest of the text the use of an enumerat= ed means of description is used i.e. Active/Standby, perhaps better to stay= consistent to this than to talk about whether the bit is set or not, saves= the reader reverting to doing inversion in his her head. Minor point only. Is it to be assumed that all of these event block apply to an endpoint in i= ndependent mode ? MA> One can attempt to write a similar state machine for the independent mo= de. But it will be fairly simple since the behavior is symmetric. The Maste= r/Slave is asymmetric. Under The active State 2nd event, "Receive preferential forwarding bit se= t (slave) Action: Stop forwarding over PW" If we were in independent mode there would be additional work to determine = if there were any alternative PWs with PW signaled at both ends, i.e. run t= he algorithm for picking a new Active PW. This is not called out. MA> In fact, that algorithm will also exist in the Master/Slave mode. The s= lave can see more than one PW with Active state and it must handle it prope= rly. It is not shown for simplicity.=20 [RobR] Ok, point conceded, the state machine is not meant to be a full desc= ription but merely a starting point. Editorial/ Nits ---------------- The name "preferential forwarding status bit" is misleading since in the M= aster mode It's not indicating the preferred PW to forward on, It's an or= der, this is the one to use. While in Independent mode it is indicating a p= reference. Perhaps dropping the word preferential and calling it the "forwarding stat= us bit" maybe clearer. MA> As explained earlier, I would like to keep it. Consider consistent use of Active vs. active. MA> Will do, thanks. Cheers Rob Rennison > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf=20 > Of Andrew G. Malis > Sent: Tuesday, October 19, 2010 2:31 PM > To: pwe3@ietf.org > Subject: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt >=20 > This email starts a two week working group last call on=20 > draft-ietf-pwe3-redundancy-bit-03.txt. >=20 > Note that changes may be required to this draft as a result of the=20 > comments received on draft-ietf-pwe3-redundancy-03.txt. If so, I would=20 > like to ask the authors to post these changes to the pwe3 list as last=20 > call comments on draft-ietf-pwe3-redundancy-bit-03.txt, and the actual=20 > changes will be made following the end of the last call. >=20 > The draft can be found at > http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-bit-03 >=20 > Please post any comments to the PWE3 list. >=20 > This WG last call closes on Tuesday, November 2. >=20 > Note that since Matthew is a co-author of this document, Andy will act=20 > as document shepherd. >=20 > Regards, > Matthew and Andy > _______________________________________________ > 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 javi@trajano.us.es Wed Feb 2 16:08:14 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E873A635F for ; Wed, 2 Feb 2011 16:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_34=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 O1YzbvRp3q3F for ; Wed, 2 Feb 2011 16:08:12 -0800 (PST) Received: from mail.us.es (mail.us.es [193.147.175.20]) by core3.amsl.com (Postfix) with ESMTP id 97FA73A6359 for ; Wed, 2 Feb 2011 16:08:11 -0800 (PST) Received: (qmail 16450 invoked from network); 3 Feb 2011 01:11:30 +0100 Received: from unknown (HELO us.es) (192.168.2.12) by us.es with SMTP; 3 Feb 2011 01:11:30 +0100 Received: (qmail 8079 invoked by uid 507); 3 Feb 2011 00:11:27 -0000 Received: from 127.0.0.1 by antivirus2 (envelope-from , uid 501) with qmail-scanner-2.08 (clamdscan: 0.96.5/12616. Clear:RC:1(127.0.0.1):. Processed in 0.044023 secs); 03 Feb 2011 00:11:27 -0000 Received: from unknown (HELO antivirus2) (127.0.0.1) by us.es with SMTP; 3 Feb 2011 00:11:27 -0000 Received: from 192.168.1.13 (192.168.1.13) by antivirus2 (F-Secure/fsigk_smtp/403/antivirus2); Thu, 03 Feb 2011 01:11:27 +0100 (CET) X-Virus-Status: clean(F-Secure/fsigk_smtp/403/antivirus2) Received: (qmail 4151 invoked from network); 3 Feb 2011 01:11:27 +0100 Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 3 Feb 2011 01:11:27 +0100 Received: from [192.168.1.40] (70.Red-83-36-250.dynamicIP.rima-tde.net [83.36.250.70]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p130BPcN027608; Thu, 3 Feb 2011 01:11:26 +0100 Message-ID: <4D49F29D.1090703@trajano.us.es> Date: Thu, 03 Feb 2011 01:11:09 +0100 From: Javi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "pwe3@ietf.org" References: <4D4369B5.9010102@trajano.us.es> <4D43DE5C.4090008@cisco.com> <4D440389.9040405@trajano.us.es> <07F7D7DED63154409F13298786A2ADC903CDC087@EXRAD5.ad.rad.co.il> <4D483F19.9010708@trajano.us.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PWE3] TDMPW terminated at terminal equipment 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, 03 Feb 2011 00:08:14 -0000 Sahsa, Yaakov and all, El 20:59, Alexander Vainshtein escribió: > Javi, and all, > > To the best of my recollection, ITU-T has not ever asked PWE3 to review this proposal (whether this was necessary is a different issue). That is the intention of my e-mail. ITU-T proposes TDMoIP[Y.1453], but the TDMoIP is equivalent to UDP/IP-based pseudo-wires [IETF RFC 5087]. So, I would like to know the opinion of the PWE3 group. May UDP/IP TDMPWs help to support ISDN multirate bearer services (N x 64-kbit/s)?: a) In a communication between two ISDN terminals, each one connected to the IP network via an access gateway (AGW). The UDP/IP TDMPW is establish between the AGWs (each AGW is a PE). ISDN TE [NxB channels] ---> AGW<----[TDMPW]----> AGW<--- ISDN TE [NxB channels] b) In a communication between an ISDN terminal and an IP terminal. The ISDN terminal is connected to the IP network via an access gateway (AGW). The UDP/IP TDMPW is establish between the AGW and the IP terminal. Here, AGW and NGN TE would be PEs ISDN TE [NxB channels] ---> AGW<----[TDMPW]----> IP TE > So I'd say that your questions should be addressed to the ITU-T Question/Study Group that has created the ITU standard in question. I think Yaakov had helped in drafting the ITU-T Y.1453 Recomendation. Yaakov, Can you give us your opinion? Regards, Javi > Regards, > Sasha > > > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Javi > Sent: Tuesday, February 01, 2011 7:13 PM > To: pwe3@ietf.org > Subject: [PWE3] TDMPW terminated at terminal equipment > > Assuming the next edge to edge comunication > > ISDN TE<--- [D/B channels] ---> AGW<----[NGN (IP) network ]----> NGN TE > > * TE: Terminal equipment > * AGW: Access Gateway > > > [ITU-T Y.2262/Appendix IV] propose: > > a) ISDN Monorate bearer services (1 × 64-kbit/s): may be emulated by a > single RTP session. > > > ISDN TE<--- [1xB channel] ---> AGW<----[RTP session]----> NGN TE > > > b) ISDN Multirate bearer services (N x 64-kbit/s): may be emulated by > TDMoIP[Y.1453] (=UDP/IP TDMPWs). > We may suppose the next scheme: > > > ISDN TE<--- [NxB channels] ---> AGW<----[TDMPW]----> NGN TE > > If it was so, "NGN TE" would be implement the PW stack protocol: > > TDMPW Payload Type > CW > RTP > UDP > IP > > Here, AGW and NGN TE would be PEs (at L2TPv3 notation: AGW=LCCE LAC; NGN > TE=LCCE LNS). > > Is it right that a terminal equipment (TE NGN) is a PW edge?. I think it > is not good choice. Then, which would be the right scheme for "b)"? > > Javier Muñoz > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From javi@trajano.us.es Wed Feb 2 16:30:23 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3BE3A63CA for ; Wed, 2 Feb 2011 16:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 EjfgbMY+Q3pk for ; Wed, 2 Feb 2011 16:30:22 -0800 (PST) Received: from mail.us.es (mail.us.es [193.147.175.20]) by core3.amsl.com (Postfix) with ESMTP id 6A7133A6359 for ; Wed, 2 Feb 2011 16:30:20 -0800 (PST) Received: (qmail 22684 invoked from network); 3 Feb 2011 01:33:41 +0100 Received: from unknown (HELO us.es) (192.168.2.11) by us.es with SMTP; 3 Feb 2011 01:33:41 +0100 Received: (qmail 13123 invoked by uid 507); 3 Feb 2011 00:33:38 -0000 Received: from 127.0.0.1 by antivirus1 (envelope-from , uid 501) with qmail-scanner-2.08 (clamdscan: 0.96.5/12616. Clear:RC:1(127.0.0.1):. Processed in 0.055727 secs); 03 Feb 2011 00:33:38 -0000 Received: from unknown (HELO antivirus1) (127.0.0.1) by us.es with SMTP; 3 Feb 2011 00:33:38 -0000 Received: from 192.168.1.13 (192.168.1.13) by antivirus1 (F-Secure/fsigk_smtp/403/antivirus1); Thu, 03 Feb 2011 01:33:38 +0100 (CET) X-Virus-Status: clean(F-Secure/fsigk_smtp/403/antivirus1) Received: (qmail 8093 invoked from network); 3 Feb 2011 01:33:38 +0100 Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 3 Feb 2011 01:33:38 +0100 Received: from [192.168.1.40] (70.Red-83-36-250.dynamicIP.rima-tde.net [83.36.250.70]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p130Xbug027865; Thu, 3 Feb 2011 01:33:38 +0100 Message-ID: <4D49F7D1.7020502@trajano.us.es> Date: Thu, 03 Feb 2011 01:33:21 +0100 From: Javi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "pwe3@ietf.org" References: <4D4369B5.9010102@trajano.us.es> <4D43DE5C.4090008@cisco.com> <4D440389.9040405@trajano.us.es> <07F7D7DED63154409F13298786A2ADC903CDC087@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC903CDC087@EXRAD5.ad.rad.co.il> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PWE3] TDMPW and MeGaCo/SDP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 00:30:23 -0000 Yaakov, Sahsa, and all, El 20:59, Yaakov Stein escribió: > Can you explain what you think needs defining via SDP here ? I will try to justify why the SDP description is needed. My scenario is that of an ISDN terminal connected to the IP network via an access gateway, communicating with a another ISDN terminal. The AGW relays the ISDN signalling to an MGC, which controls the AGW media by using Megaco. I'm interested in supporting multichannel services. I'm exploring TDMPWs to convey the data flows over the IP network. The TDMPW is establish between both access gateways (then, each one is an PE): |ISDN TE| [1xD channel ] --> |AGW| <--> MGC (Q.931/SIP)<--> |AGW| <-- [1xD channel ] |ISDN TE| |_______| [NxB channels] --> |___| <--------[TDMPW]-------->|___| <-- [NxB channels] |_______| * TE: Terminal equipment * AGW: Access Gateway and PE * MGC: Media Gateway Controller 1º An ISDN TE sends and Q.931 SETUP message to establish an ISDN multichannel call. 2º Upon receiving that ISDN signaling message, the MGC must tell the AGW (using MeGaCo/SDP) that it has to set up a TDMoIP PW, with the proper parameters (for instance, the IP address of the other end/AGW). This is a similar case to the Megaco messages indicating the IP address and UDP ports for RTP-based monocanal flows. 3º AGW sets up the TDMPW with the other AGW. NxB channels from one ISDN terminals are convey to the other ISDN TE through this TDMPW. Without the MeGaCo/SDP indication (step "2º"), the AGW will not know what to do with the incoming ISDN B channels. So far, there are three different groups that may normalize this SDP/MeGaCo dialogue: - The IETF Megaco work group, as a H.248 profile - The IETF PWE3, as a SDP description of each PW payload type proposal. - The ITU-T, as H.248.x Recomendation or an Annex to Y.1453 Javi > The PW between your MGs is completely transparent to the MGs > (logically, your MGs are connected via a TDM interface) > and the MGC should not be meddling with its parameters at all. > > You examples of carrying tones or VBD over RTP are not analogous, > as here the PW is providing the transport BELOW the logical flow, > not a feature being carried OVER the RTP transport. > > Y(J)S > > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Javi > Sent: Saturday, January 29, 2011 14:10 > To: pwe3@ietf.org > Subject: Re: [PWE3] TDMPW and MeGaCo/SDP > > Possible, but it is necessary to define it. > > No working group, as mmusic, plans to define it in collaboration with PWE3? > > > Normally, each transport proposal includes SDP extensions it needs. For > instance: > > + IETF RFC4733 (RTP Payload for tones): codecs "telephone-event" > (a=rtpmap:100 telephone-event/8000) and "tone" (a=rtpmap:101 tone/8000) > + IETF RFC4734 (Events for Modem signals): codes (a=fmtp:101 > 0-15,32-41,43,46,48-49,52-68) > + ITU-T V.152 (VBDoIP): clausule 7.1 (attribute "a=gpmd") > + ITU-T T.38: Annex D and E (protocol "udptl" and "tcptl") > + ITU-T V.150.1: Annex E (attribute and codec "a=sprtmap: > v150mr/8000") > + ITU-T V.151: Annex C (codec T.140: "a=rtpmap: t140c/8000") > .. > > So, I think it would be logical that the SDP extensions needed to > describe PWs weredone by a PW document. > > Thanks > > Javier Muñoz > > > El 29/01/2011 10:31, Stewart Bryant escribió: >> That is outside the scope of the PW. >> >> The NSP (specifically excluded from the domain of the PW) would need >> to handle that. >> >> Stewart >> >> On 29/01/2011 01:13, Javi wrote: >>> Assuming the next situation: >>> >>> ISDN Terminal 1 - MG1 - [IP network] - MG2 - ISDN Terminal 2 >>> >>> where the MGs (Media Gateway) are controlled by a MGC (Media Gateway >>> Controller) via MeGaCo[H.248.1]. >>> >>> [ITU-T Y.2262 / Annex IV] proposses that MGs may transport ISDN >>> B-channels over the IP network: >>> >>> + By a single RTP session (when monochannels ISDN services) >>> >>> + Or by TDMoIP (= UDP TDMPWs), when multichannels ISDN services. >>> >>> >>> How may MGC indicate to the MG that it uses PWs at the IP termination? >>> >>> It may be done by MeGaCo, using SDP[RFC4566] at Local/Remote >>> descriptors. However, how may be that SDP description of TDMPWs? >>> >>> Thanks, >>> >>> Javier Muñoz >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> >> > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From yaakov_s@rad.com Sun Feb 6 05:00:10 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15963A68E0 for ; Sun, 6 Feb 2011 05:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.799 X-Spam-Level: X-Spam-Status: No, score=-98.799 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_34=0.6, 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 QdcjRpWyKt3y for ; Sun, 6 Feb 2011 05:00:08 -0800 (PST) Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id C47003A6896 for ; Sun, 6 Feb 2011 05:00:06 -0800 (PST) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir1.rad.co.il with ESMTP; 06 Feb 2011 15:00:05 +0200 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Sun, 6 Feb 2011 15:00:03 +0200 Received: from EXRAD5.ad.rad.co.il ([fe80::ec3e:feb5:8bef:e3ba]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Sun, 6 Feb 2011 15:00:03 +0200 From: Yaakov Stein To: Javi Thread-Topic: [PWE3] TDMPW terminated at terminal equipment Thread-Index: AQHLwjNVrA+2rgNufEqF1DGRSR0Hl5Psy3AAgAH8WYCABa2VIA== Date: Sun, 6 Feb 2011 13:00:03 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903CDD913@EXRAD5.ad.rad.co.il> References: <4D4369B5.9010102@trajano.us.es> <4D43DE5C.4090008@cisco.com> <4D440389.9040405@trajano.us.es> <07F7D7DED63154409F13298786A2ADC903CDC087@EXRAD5.ad.rad.co.il> <4D483F19.9010708@trajano.us.es> <4D49F29D.1090703@trajano.us.es> In-Reply-To: <4D49F29D.1090703@trajano.us.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.37] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] TDMPW terminated at terminal equipment 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: Sun, 06 Feb 2011 13:00:11 -0000 Javi, I was indeed the editor of Y.1413, Y.1418, Y.1452, and Y.1453. These were pure "network interworking" documents (or as the IETF would call them "encaps") and did not deal with any signaling issues, assuming that any control plane used for the native service=20 would work equally well when the native service was transported across an I= P or MPLS network. In ITU terms, these Recommendations were part of a migration scenario, where IP or MPLS networks could be used to transport existing services. In parallel the ITU developed the "Next Generation" services, that run over IP and MPLS but use new control planes. Y(J)S -----Original Message----- From: Javi [mailto:javi@trajano.us.es]=20 Sent: Thursday, February 03, 2011 02:11 To: pwe3@ietf.org Subject: RE: [PWE3] TDMPW terminated at terminal equipment Sahsa, Yaakov and all, El 20:59, Alexander Vainshtein escribi=F3: > Javi, and all, > > To the best of my recollection, ITU-T has not ever asked PWE3 to review t= his proposal (whether this was necessary is a different issue). That is the intention of my e-mail. ITU-T proposes TDMoIP[Y.1453], but =20 the TDMoIP is equivalent to UDP/IP-based pseudo-wires [IETF RFC 5087]. So, I would like to know the opinion of the PWE3 group. May UDP/IP=20 TDMPWs help to support ISDN multirate bearer services (N x 64-kbit/s)?: a) In a communication between two ISDN terminals, each one connected to=20 the IP network via an access gateway (AGW). The UDP/IP TDMPW is=20 establish between the AGWs (each AGW is a PE). ISDN TE [NxB channels] ---> AGW<----[TDMPW]----> AGW<--- ISDN TE [NxB c= hannels] b) In a communication between an ISDN terminal and an IP terminal. The=20 ISDN terminal is connected to the IP network via an access gateway=20 (AGW). The UDP/IP TDMPW is establish between the AGW and the IP=20 terminal. Here, AGW and NGN TE would be PEs ISDN TE [NxB channels] ---> AGW<----[TDMPW]----> IP TE > So I'd say that your questions should be addressed to the ITU-T Question/= Study Group that has created the ITU standard in question. I think Yaakov had helped in drafting the ITU-T Y.1453 Recomendation. Yaakov, Can you give us your opinion? Regards, Javi > Regards, > Sasha > > > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of J= avi > Sent: Tuesday, February 01, 2011 7:13 PM > To: pwe3@ietf.org > Subject: [PWE3] TDMPW terminated at terminal equipment > > Assuming the next edge to edge comunication > > ISDN TE<--- [D/B channels] ---> AGW<----[NGN (IP) network ]----> NGN = TE > > * TE: Terminal equipment > * AGW: Access Gateway > > > [ITU-T Y.2262/Appendix IV] propose: > > a) ISDN Monorate bearer services (1 =D7 64-kbit/s): may be emulated by a > single RTP session. > > > ISDN TE<--- [1xB channel] ---> AGW<----[RTP session]----> NGN TE > > > b) ISDN Multirate bearer services (N x 64-kbit/s): may be emulated by > TDMoIP[Y.1453] (=3DUDP/IP TDMPWs). > We may suppose the next scheme: > > > ISDN TE<--- [NxB channels] ---> AGW<----[TDMPW]----> NGN TE > > If it was so, "NGN TE" would be implement the PW stack protocol: > > TDMPW Payload Type > CW > RTP > UDP > IP > > Here, AGW and NGN TE would be PEs (at L2TPv3 notation: AGW=3DLCCE LAC; NG= N > TE=3DLCCE LNS). > > Is it right that a terminal equipment (TE NGN) is a PW edge?. I think it > is not good choice. Then, which would be the right scheme for "b)"? > > Javier Mu=F1oz > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From yaakov_s@rad.com Sun Feb 6 05:09:01 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6EF3A6B06 for ; Sun, 6 Feb 2011 05:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.399 X-Spam-Level: X-Spam-Status: No, score=-99.399 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CBL1tJqCAxE for ; Sun, 6 Feb 2011 05:09:00 -0800 (PST) Received: from antivir1.rad.co.il (antivir1.rad.co.il [62.0.23.193]) by core3.amsl.com (Postfix) with ESMTP id 79CBD3A68CB for ; Sun, 6 Feb 2011 05:08:57 -0800 (PST) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir1.rad.co.il with ESMTP; 06 Feb 2011 15:08:58 +0200 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Sun, 6 Feb 2011 15:08:57 +0200 Received: from EXRAD5.ad.rad.co.il ([fe80::ec3e:feb5:8bef:e3ba]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Sun, 6 Feb 2011 15:08:57 +0200 From: Yaakov Stein To: Javi Thread-Topic: [PWE3] TDMPW and MeGaCo/SDP Thread-Index: AQHLv1HJ/2+hqZZkjUml4mRXd7ggj5PnjlkAgAAsUYCABRWpoIACA22AgAWpitA= Date: Sun, 6 Feb 2011 13:08:56 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903CDD930@EXRAD5.ad.rad.co.il> References: <4D4369B5.9010102@trajano.us.es> <4D43DE5C.4090008@cisco.com> <4D440389.9040405@trajano.us.es> <07F7D7DED63154409F13298786A2ADC903CDC087@EXRAD5.ad.rad.co.il> <4D49F7D1.7020502@trajano.us.es> In-Reply-To: <4D49F7D1.7020502@trajano.us.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {C4150A12-8CB7-46C7-8C4D-E94848C87B5E} x-cr-hashedpuzzle: /m0= A1CM BmhV EF0W EUo2 Fbrg IEzt KmO/ NuxA PJq8 PTmi PaXV Qj4d UzFo VATd VHyw; 2; agBhAHYAaQBAAHQAcgBhAGoAYQBuAG8ALgB1AHMALgBlAHMAOwBwAHcAZQAzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {C4150A12-8CB7-46C7-8C4D-E94848C87B5E}; eQBhAGEAawBvAHYAXwBzAEAAcgBhAGQALgBjAG8AbQA=; Sun, 06 Feb 2011 13:08:51 GMT; UgBFADoAIABbAFAAVwBFADMAXQAgAFQARABNAFAAVwAgAGEAbgBkACAATQBlAEcAYQBDAG8ALwBTAEQAUAA= x-originating-ip: [172.17.170.37] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] TDMPW and MeGaCo/SDP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 13:09:01 -0000 Javi SAToP, CESoPSN, and TDMoIP-AAL1 TDM PWs are usually set up before they are = needed,=20 and remain up as long as they may be needed. The individual channels are then set up using native signaling. The scenario you mention (setting up bandwidth as needed) is handled in Y.1= 414 and Y.1452,=20 and is not in the spirit of Y.1413 or Y.1453. There are mechanisms in RFC 5287 for the TDMoIP AAL2 mode, that help map individual voice channels. Once an AAL2 mode PW is set up, you needn't signal for every channel up/dow= n event, since the BW is not consumed if not used. Y(J)S -----Original Message----- From: Javi [mailto:javi@trajano.us.es]=20 Sent: Thursday, February 03, 2011 02:33 To: pwe3@ietf.org Subject: RE: [PWE3] TDMPW and MeGaCo/SDP Yaakov, Sahsa, and all, El 20:59, Yaakov Stein escribi=F3: > Can you explain what you think needs defining via SDP here ? I will try to justify why the SDP description is needed. My scenario is that of an ISDN terminal connected to the IP network via an access gateway, communicating with a another ISDN terminal. The AGW=20 relays the ISDN signalling to an MGC, which controls the AGW media by using Megaco. I'm interested in supporting multichannel services. I'm exploring TDMPWs=20 to convey the data flows over the IP network. The TDMPW is establish=20 between both access gateways (then, each one is an PE): |ISDN TE| [1xD channel ] --> |AGW| <--> MGC (Q.931/SIP)<--> |AGW| <--=20 [1xD channel ] |ISDN TE| |_______| [NxB channels] --> |___| <--------[TDMPW]-------->|___| <--=20 [NxB channels] |_______| * TE: Terminal equipment * AGW: Access Gateway and PE * MGC: Media Gateway Controller 1=BA An ISDN TE sends and Q.931 SETUP message to establish an ISDN=20 multichannel call. 2=BA Upon receiving that ISDN signaling message, the MGC must tell the AGW= =20 (using MeGaCo/SDP) that it has to set up a TDMoIP PW, with the proper parameters (for instance, the IP address of the other end/AGW).=20 This is a similar case to the Megaco messages indicating the IP address=20 and UDP ports for RTP-based monocanal flows. 3=BA AGW sets up the TDMPW with the other AGW. NxB channels from one ISDN=20 terminals are convey to the other ISDN TE through this TDMPW. Without the MeGaCo/SDP indication (step "2=BA"), the AGW will not know=20 what to do with the incoming ISDN B channels. So far, there are three different groups that may normalize this=20 SDP/MeGaCo dialogue: - The IETF Megaco work group, as a H.248 profile - The IETF PWE3, as a SDP description of each PW payload type proposal. - The ITU-T, as H.248.x Recomendation or an Annex to Y.1453 Javi > The PW between your MGs is completely transparent to the MGs > (logically, your MGs are connected via a TDM interface) > and the MGC should not be meddling with its parameters at all. > > You examples of carrying tones or VBD over RTP are not analogous, > as here the PW is providing the transport BELOW the logical flow, > not a feature being carried OVER the RTP transport. > > Y(J)S > > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of J= avi > Sent: Saturday, January 29, 2011 14:10 > To: pwe3@ietf.org > Subject: Re: [PWE3] TDMPW and MeGaCo/SDP > > Possible, but it is necessary to define it. > > No working group, as mmusic, plans to define it in collaboration with PWE= 3? > > > Normally, each transport proposal includes SDP extensions it needs. For > instance: > > + IETF RFC4733 (RTP Payload for tones): codecs "telephone-event" > (a=3Drtpmap:100 telephone-event/8000) and "tone" (a=3Drtpmap:101 tone/800= 0) > + IETF RFC4734 (Events for Modem signals): codes (a=3Dfmtp:101 > 0-15,32-41,43,46,48-49,52-68) > + ITU-T V.152 (VBDoIP): clausule 7.1 (attribute "a=3Dgpmd") > + ITU-T T.38: Annex D and E (protocol "udptl" and "tcptl") > + ITU-T V.150.1: Annex E (attribute and codec "a=3Dsprtmap: > v150mr/8000") > + ITU-T V.151: Annex C (codec T.140: "a=3Drtpmap: t140c/8= 000") > .. > > So, I think it would be logical that the SDP extensions needed to > describe PWs weredone by a PW document. > > Thanks > > Javier Mu=F1oz > > > El 29/01/2011 10:31, Stewart Bryant escribi=F3: >> That is outside the scope of the PW. >> >> The NSP (specifically excluded from the domain of the PW) would need >> to handle that. >> >> Stewart >> >> On 29/01/2011 01:13, Javi wrote: >>> Assuming the next situation: >>> >>> ISDN Terminal 1 - MG1 - [IP network] - MG2 - ISDN Terminal 2 >>> >>> where the MGs (Media Gateway) are controlled by a MGC (Media Gateway >>> Controller) via MeGaCo[H.248.1]. >>> >>> [ITU-T Y.2262 / Annex IV] proposses that MGs may transport ISDN >>> B-channels over the IP network: >>> >>> + By a single RTP session (when monochannels ISDN services) >>> >>> + Or by TDMoIP (=3D UDP TDMPWs), when multichannels ISDN services. >>> >>> >>> How may MGC indicate to the MG that it uses PWs at the IP termination? >>> >>> It may be done by MeGaCo, using SDP[RFC4566] at Local/Remote >>> descriptors. However, how may be that SDP description of TDMPWs? >>> >>> Thanks, >>> >>> Javier Mu=F1oz >>> _______________________________________________ >>> 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 iesg-secretary@ietf.org Mon Feb 7 08:13:13 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794753A6D03; Mon, 7 Feb 2011 08:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DqTv+JKgTBG; Mon, 7 Feb 2011 08:13:12 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479D43A6E22; Mon, 7 Feb 2011 08:13:10 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110207161310.20916.56573.idtracker@localhost> Date: Mon, 07 Feb 2011 08:13:10 -0800 Cc: pwe3@ietf.org Subject: [PWE3] Last Call: (Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 16:13:13 -0000 The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-fc-encap/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-fc-encap/ No IPR declarations have been submitted directly on this I-D. From david.black@emc.com Mon Feb 7 09:49:32 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01AB43A6E3E; Mon, 7 Feb 2011 09:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGmwc3G6lEcx; Mon, 7 Feb 2011 09:49:30 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 6F1923A6E22; Mon, 7 Feb 2011 09:49:30 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p17HnVfX015672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Feb 2011 12:49:33 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 7 Feb 2011 12:49:23 -0500 Received: from mxhub17.corp.emc.com (mxhub17.corp.emc.com [10.254.93.46]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p17HnKNo003521; Mon, 7 Feb 2011 12:49:20 -0500 Received: from mx14a.corp.emc.com ([169.254.1.70]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Mon, 7 Feb 2011 12:49:20 -0500 From: To: Date: Mon, 7 Feb 2011 12:49:19 -0500 Thread-Topic: Last Call: (Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks) to Proposed Standard Thread-Index: AcvG4hjxH/z3UzYqSGukU9j68wK4OgAC9FSQ Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03E1FB28B4@MX14A.corp.emc.com> References: <20110207161310.20916.56573.idtracker@localhost> In-Reply-To: <20110207161310.20916.56573.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: pwe3@ietf.org, iesg@ietf.org Subject: Re: [PWE3] Last Call: (Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 17:49:32 -0000 This IETF draft contains normative references to three Fibre Channel standa= rds that are developed by INCITS Technical Committee T11 (www.t11.org) - FC= -BB-6, FC-FS-2 and FC-SP. FC-BB-6 is under active development at T11, and = hence its latest working draft (revision 1.02) is publicly available from T= 11's web site. As the other two references are to published standards, the= ir availability is restricted. In both cases, the material relied upon by = this IETF draft has not been changed by follow-on standards work, so the la= test drafts of T11's follow-on standards efforts (FC-FS-3 and FC-SP-2) can = be used for reference. If anyone needs a copy of FC-FS-2 and/or FC-SP in order to review this IETF= draft, please send me an email - I have been authorized by T11 to provide = copies of these standards for the personal use of IETF participants in IETF= activity related to this draft. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.o= rg] On Behalf Of The IESG > Sent: Monday, February 07, 2011 11:13 AM > To: IETF-Announce > Cc: pwe3@ietf.org > Subject: Last Call: (Encapsulation Meth= ods for Transport of Fibre > Channel Traffic over MPLS Networks) to Proposed Standard >=20 >=20 > The IESG has received a request from the Pseudowire Emulation Edge to > Edge WG (pwe3) to consider the following document: > - 'Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS > Networks' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-02-21. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-pwe3-fc-encap/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-pwe3-fc-encap/ >=20 >=20 >=20 > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From Internet-Drafts@ietf.org Tue Feb 8 17:00:03 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EC9D3A6836; Tue, 8 Feb 2011 17:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id To2zOXQVAwQN; Tue, 8 Feb 2011 17:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6932C3A6824; Tue, 8 Feb 2011 17:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110209010002.25400.89306.idtracker@localhost> Date: Tue, 08 Feb 2011 17:00:02 -0800 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-p2mp-pw-01.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, 09 Feb 2011 01:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Signaling Root-Initiated Point-to-Multipoint Pseudowires using LDP Author(s) : L. Martini, et al. Filename : draft-ietf-pwe3-p2mp-pw-01.txt Pages : 18 Date : 2011-02-08 This document specifies a mechanism to signal Point-to-Multipoint (P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP or MPLS-enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-p2mp-pw-01.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-p2mp-pw-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-08164919.I-D@ietf.org> --NextPart-- From david.sinicrope@ericsson.com Tue Feb 8 21:35:47 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CD213A68F0 for ; Tue, 8 Feb 2011 21:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CMTpglgvszg for ; Tue, 8 Feb 2011 21:35:46 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 72A4B3A68ED for ; Tue, 8 Feb 2011 21:35:45 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p196JhU4030927 for ; Wed, 9 Feb 2011 00:19:44 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 9 Feb 2011 00:35:47 -0500 From: David Sinicrope To: "IETF.PWE3" Date: Wed, 9 Feb 2011 00:35:39 -0500 Thread-Topic: PWE3 Agenda Slot Call for IETF 80 - Prague Thread-Index: AcvIGzOO5bToDcYqSsaWIAxDXfS04g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [PWE3] PWE3 Agenda Slot Call for IETF 80 - Prague 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, 09 Feb 2011 05:35:47 -0000 Hi All, Please let me know if you would like a time slot for the IETF 80 PWE3 sessi= on by replying to this email with the desired duration, topic/draft title, = and presenter for each slot requested. Thanks, Dave From javi@trajano.us.es Wed Feb 9 11:08:52 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90C53A67AE for ; Wed, 9 Feb 2011 11:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.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 zZlAZp1PRjEn for ; Wed, 9 Feb 2011 11:08:51 -0800 (PST) Received: from mail.us.es (mail.us.es [193.147.175.20]) by core3.amsl.com (Postfix) with ESMTP id B68A83A672F for ; Wed, 9 Feb 2011 11:08:50 -0800 (PST) Received: (qmail 27601 invoked from network); 9 Feb 2011 20:08:59 +0100 Received: from unknown (HELO us.es) (192.168.2.13) by us.es with SMTP; 9 Feb 2011 20:08:59 +0100 Received: (qmail 9667 invoked by uid 507); 9 Feb 2011 19:08:57 -0000 Received: from 127.0.0.1 by antivirus3 (envelope-from , uid 501) with qmail-scanner-2.08 (clamdscan: 0.96.5/12653. Clear:RC:1(127.0.0.1):. Processed in 0.039826 secs); 09 Feb 2011 19:08:57 -0000 Received: from unknown (HELO antivirus3) (127.0.0.1) by us.es with SMTP; 9 Feb 2011 19:08:57 -0000 Received: from 192.168.1.13 (192.168.1.13) by antivirus3 (F-Secure/fsigk_smtp/403/antivirus3); Wed, 09 Feb 2011 20:08:57 +0100 (CET) X-Virus-Status: clean(F-Secure/fsigk_smtp/403/antivirus3) Received: (qmail 20763 invoked from network); 9 Feb 2011 20:08:57 +0100 Received: from trajano.us.es (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 9 Feb 2011 20:08:57 +0100 Received: from [193.147.162.138] (adriano.us.es [193.147.162.138]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id p19J8vXo003886; Wed, 9 Feb 2011 20:08:57 +0100 Message-ID: <4D52E669.1010600@trajano.us.es> Date: Wed, 09 Feb 2011 20:09:29 +0100 From: =?windows-1252?Q?Javi_Mu=F1oz?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "pwe3@ietf.org" References: <4D4369B5.9010102@trajano.us.es> <4D43DE5C.4090008@cisco.com> <4D440389.9040405@trajano.us.es> <07F7D7DED63154409F13298786A2ADC903CDC087@EXRAD5.ad.rad.co.il> <4D49F7D1.7020502@trajano.us.es> <07F7D7DED63154409F13298786A2ADC903CDD930@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC903CDD930@EXRAD5.ad.rad.co.il> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PWE3] TDMPW and MeGaCo/SDP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 19:08:52 -0000 Yaakov, setting-up a full mesh of PW does not scale well in this scenario (in fact, we have also faced this problem in L2VPN services). It is not a matter of BW, but of number of PW at every Access Gateway (AGW). It will require the establishment of a PW to every potential destination AGW (which may be in the numbers of tens of thousands for a single PNO). Native signalling is OK for individual channels inside the PW, and the PW control plane is OK for negotiating PW features end-to-end, but we (the MGC) still need to tell the AGW to trigger the PW establishment to a given destination AGW. The IP address of the destination AGW (and perhaps other parameters) should be communicated to the source AGW (by the MGC), so that the former can start the PW establishment procedure. And, even in the case you mention (pre-established PW), we (the MGC) still need to tell the AGW wich PW to use. It is not the AGW who knows the final destination, but the MGC (where the high-level signaling terminates). In fact I believe that the VPN example mentioned above has some similarities with the AGW scenario: in the BGP-based L3VPN (rfc 4364, was 2547bis) you do use an extra control plane (iBGP) to tell the VRF (access node) which PW to use, using an iBGP attribute (the "label") that may be thought as an "SDP description" May be I'm wrong, but, if I were right and you finally agree with my point, I would like to know your opinion on which standard body should specify the SDP description of the PW parameters: - will it be the IETF?. Some examples of similar cases where the IETF defines an SDP description to be used by a third signalling protocol may be IETF RFC4733 (SDP description for codec "telephone-event") or RFC4733 (event codes). - will if be the ITU? Some examples of similar cases where the ITU-T defines SDP atributes to be used by other protocols are V.152 (attribute "a=gpmd"), T.38 (SDP description for the protocol "udptl" and "tcptl"), V.150.1 ("a=sprtmap: v150mr/8000") and V.151 (codec "a=rtpmap: t140c/8000"). - will it be any other? Javi 06/02/2011 14:08, Yaakov Stein wrote: > Javi > > SAToP, CESoPSN, and TDMoIP-AAL1 TDM PWs are usually set up before they are needed, > and remain up as long as they may be needed. > The individual channels are then set up using native signaling. > > The scenario you mention (setting up bandwidth as needed) is handled in Y.1414 and Y.1452, > and is not in the spirit of Y.1413 or Y.1453. > There are mechanisms in RFC 5287 for the TDMoIP AAL2 mode, > that help map individual voice channels. > Once an AAL2 mode PW is set up, you needn't signal for every channel up/down event, > since the BW is not consumed if not used. > > Y(J)S From giles.heron@gmail.com Wed Feb 9 16:25:04 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274D13A67AD for ; Wed, 9 Feb 2011 16:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 NiuptkCKonZJ for ; Wed, 9 Feb 2011 16:25:02 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 2A6193A65A6 for ; Wed, 9 Feb 2011 16:25:02 -0800 (PST) Received: by pzk5 with SMTP id 5so159283pzk.31 for ; Wed, 09 Feb 2011 16:25:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=JPZqV+KHgAn1RG0WFhw0yZpYDO9lbWA81gV+lqX0P48=; b=F3BIXxxUKF/hU10d3k00ULhZn23l4xNDAOYhD8EWd4EQEaSYS4ZrXTSpoZmjnLcqFw kRQcg772y9rvudp/q9X1CA9fEfEOrvqzEoitrVJ1Igs5/uwa84ru+qQKRGNYACqPIj33 EtTXe2sEuNPNq8vLSB5HyFcBxg/EN+CNj1R48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=YTEKfL7h82NaFA4wSwqmGcH1tLgXuUiPRYCxM933qnh9rDMylK69VHKAl94vWfUkLN UgmjxlnQZcp3NNdJ5QrMWIfG/zhlsMJPnJeWH5jhoHERSZmjjVl33FE2VVc3ko/UFVLj fSjSjMOWdw5j1+8BpjqGvHKf0BV6iaglPtCwI= Received: by 10.142.48.17 with SMTP id v17mr302556wfv.262.1297297512915; Wed, 09 Feb 2011 16:25:12 -0800 (PST) Received: from [171.70.245.149] (dhcp-171-70-245-149.cisco.com [171.70.245.149]) by mx.google.com with ESMTPS id x18sm1090879wfa.11.2011.02.09.16.25.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 16:25:10 -0800 (PST) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 10 Feb 2011 00:26:10 +0000 From: Giles Heron To: Alexander Vainshtein , "Luca Martini (lmartini)" , "Bocci, Matthew (Matthew)" , "swallow@cisco.com" Message-ID: Thread-Topic: Usage of ACH TLV header in draft-ietf-pwe3-static-pw-status-01 Thread-Index: AcuycWu+nLJskZLnSF2hRm+aMw8w6AWR7HFB In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Andrew Sergeev , Sunil Malali , "pwe3@ietf.org" , Robert Rennison , Rotem Cohen Subject: Re: [PWE3] Usage of ACH TLV header in draft-ietf-pwe3-static-pw-status-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 00:25:04 -0000 Hi Sasha, Sorry for the late reply on this one. I have to hold my hand up here and admit to this one being my mistake. I misread RFC 5586 in my hurry to get the edits done (I followed RFC5586 section 3.2 without reading the whole of section 3). So yes, there are no ACH TLVs and there ought to be no ACH TLV Header. We'll fix that in the next revision of the draft. Giles On 12/01/2011 15:57, "Alexander Vainshtein" wrote: > Luca, Matthew, George, Giles and all, > > I would highly appreciate a clarification regarding the following point in the > static PW status draft. > > The draft shows format of the static status PW message as following: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1|Version| Reserved | 0xZZ PW OAM Message | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ACH TLV Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Refresh Timer | TLV Length |A| Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ TLVs ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The draft defines a new ACH type - PW OAM Message - and suggests a value of > 0x0022 for this type > (in its IANA Considerations section). > > The draft further explains that ACH TLV header is defined in RFC 5586, and > that it must be set to 0 > since there are no ACH TLVs in this message. > > However, looking up RFC 5586, I've found the following text dealing with the > ACH TLVs vs. ACH Type: > > > If the G-ACh message MAY be preceded by one or more ACH TLVs, then > this MUST be explicitly specified in the definition of an ACH Channel > Type. If the ACH Channel Type definition does state that one or more > ACH TLVs MAY precede the G-ACh message, an ACH TLV Header MUST follow > the ACH. If no ACH TLVs are required in a specific associated > channel packet, but the Channel Type nevertheless defines that ACH > TLVs MAY be used, an ACH TLV Header MUST be present but with a length > field set to zero to indicate that no ACH TLV follow this header. > > If an ACH Channel Type specification does not explicitly specify that > ACH TLVs MAY be used, then the ACH TLV Header MUST NOT be used. > > > Hence my question: Why is the ACH TLV header present in the static PW status > message? > > To the best of my understanding, the draft, in its present form, does not > *explicitly* specify that ACH TLVs > MAY be used with the new ACH Type defined for these messages: If anything, its > text suggests that they are not used. > Hence the last para of the quoted text from RFC 5586 seems to apply, i.e., the > ACH TLV Header MUST NOT be used. > > Alternatively, if ACH TLVs MAY be used (in future) with the new ACH Type, this > MUST at least be explicitly > specified in the draft. (Personally I think that some explanation regarding > potential usage of ACH TLVs would be helpful, but this is not mandatory.) > > Regards, and lots of thanks in advance, > Sasha > > From Alexander.Vainshtein@ecitele.com Wed Feb 9 21:31:55 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FB033A6896 for ; Wed, 9 Feb 2011 21:31:55 -0800 (PST) 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 NSFdLc8POL7z for ; Wed, 9 Feb 2011 21:31:53 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 8622F3A6895 for ; Wed, 9 Feb 2011 21:31:52 -0800 (PST) X-AuditID: 93eaf2e7-b7b47ae000005f02-2b-4d53785489b1 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id BF.62.24322.458735D4; Thu, 10 Feb 2011 07:32:04 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Thu, 10 Feb 2011 07:32:01 +0200 From: Alexander Vainshtein To: Giles Heron , "Luca Martini (lmartini)" , "Bocci, Matthew (Matthew)" , "swallow@cisco.com" Date: Thu, 10 Feb 2011 07:31:37 +0200 Thread-Topic: Usage of ACH TLV header in draft-ietf-pwe3-static-pw-status-01 Thread-Index: AcuycWu+nLJskZLnSF2hRm+aMw8w6AWR7HFBAAqq9ZY= Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAA== Cc: Andrew Sergeev , Sunil Malali , "pwe3@ietf.org" , Robert Rennison , Rotem Cohen Subject: Re: [PWE3] Usage of ACH TLV header in draft-ietf-pwe3-static-pw-status-01 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 05:31:56 -0000 Lots of thanks for an encouraging response. Regards, Sasha ________________________________________ From: Giles Heron [giles.heron@gmail.com] Sent: Thursday, February 10, 2011 2:26 AM To: Alexander Vainshtein; Luca Martini (lmartini); Bocci, Matthew (Matthew)= ; swallow@cisco.com Cc: pwe3@ietf.org; Rotem Cohen; Andrew Sergeev; Sunil Malali; Robert Rennis= on Subject: Re: Usage of ACH TLV header in draft-ietf-pwe3-static-pw-status-0= 1 Hi Sasha, Sorry for the late reply on this one. I have to hold my hand up here and admit to this one being my mistake. I misread RFC 5586 in my hurry to get the edits done (I followed RFC5586 section 3.2 without reading the whole of section 3). So yes, there are no ACH TLVs and there ought to be no ACH TLV Header. We'll fix that in the next revision of the draft. Giles On 12/01/2011 15:57, "Alexander Vainshtein" wrote: > Luca, Matthew, George, Giles and all, > > I would highly appreciate a clarification regarding the following point i= n the > static PW status draft. > > The draft shows format of the static status PW message as following: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1|Version| Reserved | 0xZZ PW OAM Message | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ACH TLV Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Refresh Timer | TLV Length |A| Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ TLVs ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The draft defines a new ACH type - PW OAM Message - and suggests a value = of > 0x0022 for this type > (in its IANA Considerations section). > > The draft further explains that ACH TLV header is defined in RFC 5586, a= nd > that it must be set to 0 > since there are no ACH TLVs in this message. > > However, looking up RFC 5586, I've found the following text dealing with = the > ACH TLVs vs. ACH Type: > > > If the G-ACh message MAY be preceded by one or more ACH TLVs, then > this MUST be explicitly specified in the definition of an ACH Channel > Type. If the ACH Channel Type definition does state that one or more > ACH TLVs MAY precede the G-ACh message, an ACH TLV Header MUST follow > the ACH. If no ACH TLVs are required in a specific associated > channel packet, but the Channel Type nevertheless defines that ACH > TLVs MAY be used, an ACH TLV Header MUST be present but with a length > field set to zero to indicate that no ACH TLV follow this header. > > If an ACH Channel Type specification does not explicitly specify that > ACH TLVs MAY be used, then the ACH TLV Header MUST NOT be used. > > > Hence my question: Why is the ACH TLV header present in the static PW sta= tus > message? > > To the best of my understanding, the draft, in its present form, does not > *explicitly* specify that ACH TLVs > MAY be used with the new ACH Type defined for these messages: If anything= , its > text suggests that they are not used. > Hence the last para of the quoted text from RFC 5586 seems to apply, i.e.= , the > ACH TLV Header MUST NOT be used. > > Alternatively, if ACH TLVs MAY be used (in future) with the new ACH Type,= this > MUST at least be explicitly > specified in the draft. (Personally I think that some explanation regardi= ng > potential usage of ACH TLVs would be helpful, but this is not mandatory.) > > Regards, and lots of thanks in advance, > Sasha > >= From lberger@labn.net Thu Feb 10 10:33:31 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32C63A6A65 for ; Thu, 10 Feb 2011 10:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XZuB9VLVjxd for ; Thu, 10 Feb 2011 10:33:30 -0800 (PST) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id E850D3A6A64 for ; Thu, 10 Feb 2011 10:33:29 -0800 (PST) Received: (qmail 5403 invoked by uid 0); 10 Feb 2011 18:33:42 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy2.bluehost.com with SMTP; 10 Feb 2011 18:33:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=NgKhyUWP4jG8OspW4zGvhcimu8oplkNUPgHOzpnjLOY5Kx9XuaX0ViCq/4cKZQIEzjejlZdqTEHdxJc8H6IeF8dM4EVBGRVWPOPe0iuUoWLIrEBL/We7glV4kkpMiWaE; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PnbKo-0006op-Cd; Thu, 10 Feb 2011 11:33:42 -0700 Message-ID: <4D542F85.6050607@labn.net> Date: Thu, 10 Feb 2011 13:33:41 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: ccamp@ietf.org, "mpls-tp@ietf.org" , "pwe3@ietf.org" , IESG References: <20110210141501.4357.50359.idtracker@localhost> In-Reply-To: <20110210141501.4357.50359.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} X-Mailman-Approved-At: Fri, 11 Feb 2011 08:03:24 -0800 Subject: Re: [PWE3] [CCAMP] I-D Action:draft-ietf-ccamp-mpls-tp-cp-framework-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: Thu, 10 Feb 2011 18:33:31 -0000 FYI - this update was made to address IESG comments. Changes include: 1) Update references 2) Minor editorial changes, including: - acronym expansion, - wordsmithing, - clarification of terms 3) Removal (and consequential reordering) of requirement 38 (was "Requirement removed.") 4) Added additional references 5) Added (PW) section 5.1.1. to parallel (LSP) section 4.2.1 6) Removed some out-of-scope text Lou On 2/10/2011 9:15 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > > Title : MPLS-TP Control Plane Framework > Author(s) : L. Andersson, et al. > Filename : draft-ietf-ccamp-mpls-tp-cp-framework-06.txt > Pages : 55 > Date : 2011-02-10 > > The MPLS Transport Profile (MPLS-TP) supports static provisioning > of transport paths via a Network Management System (NMS), and > dynamic provisioning of transport paths via a control plane. This > document provides the framework for MPLS-TP dynamic provisioning, > and covers control plane addressing, routing, path computation, > signaling, traffic engineering, and path recovery. MPLS-TP uses > GMPLS as the control plane for MPLS-TP Label Switched Paths > (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for > Pseudowires (PWs). Management plane functions are out of scope of > this document. > > This document is a product of a joint Internet Engineering Task Force > (IETF) / International Telecommunication Union Telecommunication > Standardization Sector (ITU-T) effort to include an MPLS Transport > Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge > (PWE3) architectures to support the capabilities and functionalities > of a packet transport network as defined by the ITU-T. > > This Informational Internet-Draft is aimed at achieving IETF > Consensus before publication as an RFC and will be subject to an IETF > Last Call. > > [RFC Editor, please remove this note before publication as an RFC and > insert the correct Streams Boilerplate to indicate that the published > RFC has IETF consensus.] > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-cp-framework-06.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. > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From nick.delregno@verizon.com Mon Feb 14 07:40:11 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 474653A6D6E; Mon, 14 Feb 2011 07:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 tNCgWhrVkdRd; Mon, 14 Feb 2011 07:40:06 -0800 (PST) Received: from ashesmtp03.verizonbusiness.com (ashesmtp03.verizonbusiness.com [198.4.8.167]) by core3.amsl.com (Postfix) with ESMTP id EB0483A6D45; Mon, 14 Feb 2011 07:40:05 -0800 (PST) Received: from pdcismtp03.vzbi.com ([unknown] [166.40.77.73]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LGM003LU67G7A70@firewall.verizonbusiness.com>; Mon, 14 Feb 2011 15:40:28 +0000 (GMT) Received: from pdcismtp03.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LGM00BA067GEC00@pdcismtp03.vzbi.com>; Mon, 14 Feb 2011 15:40:28 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([unknown] [153.39.68.168]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LGM00B0L67GGO00@pdcismtp03.vzbi.com>; Mon, 14 Feb 2011 15:40:28 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 15:40:28 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01CBCC5D.80927EF2" Date: Mon, 14 Feb 2011 15:40:25 +0000 Message-id: <14584D6EE26B314187A4F68BA2060600069340AD@ASHEVS008.mcilink.com> In-reply-to: <14584D6EE26B314187A4F68BA2060600067709F5@ASHEVS008.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: PW/VCCV Survey Ending Soon! Thread-index: Act8YpSEMMoOD4/+SCeRBwpsUYLmAgTfklMQDL9wpzACX6Nw8A== X-Priority: 1 Priority: Urgent Importance: high References: <14584D6EE26B314187A4F68BA206060005AE91E1@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA206060005DB543A@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA2060600067709F5@ASHEVS008.mcilink.com> From: "Delregno, Christopher N (Nick DelRegno)" To: pwe3 , mpls@ietf.org, l2vpn@ietf.org X-OriginalArrivalTime: 14 Feb 2011 15:40:28.0007 (UTC) FILETIME=[81184F70:01CBCC5D] Subject: [PWE3] PW/VCCV Survey Ending Soon! 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, 14 Feb 2011 15:40:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBCC5D.80927EF2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We now have 9 valid responses to the VCCV User Survey. Time is running out. The deadline for submissions is February 25th. So we have 11 days and counting. =20 It is important that we get as many participants as possible to ensure fair representation in any future PW Control Word and VCCV related work in the PWE3 working group. =20 I will be presenting the results of the PW/VCCV survey in the form of a draft for IETF 80 in Prague. =20 Thanks, Nick =20 =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=3D=3D=3D=3D=3D=3D =20 All: =20 Per the direction of the PWE3 working group, beginning in IETF77 and reinforced in IETF78, the PWE3 working group is conducting a Service Provider implementation survey related to: =20 - Pseudowire Encapsulations - Control Word Support - Control Word Use - VCCV Control Channel Support - VCCV Control Channel Use =20 http://www.surveymonkey.com/s/pwe3 =20 This is a short survey directed toward Service Providers who currently operate networks using any of the defined PWE3 encapsulations. The results of this survey will be used to determine the direction of the Control Word support in current and future encapsulations as well as solutions to VCCV interoperability challenges. =20 We sincerely urge all service providers to participate. We ask that all equipment providers encourage participation by their Service Provider customers. The more feedback we receive, the better view of the existing network we can have on which to base going-forward direction. =20 If you have any questions, regarding the survey, especially of a technical nature, please contact me. If you have non-technical questions, feel free to reach out to the PWE3 WG chairs and myself. =20 The results of the survey will be aggregated and shared at a high level. No low-level details of network implementations will be shared. All participant's responses will remain private, if not anonymous. =20 All responses will require a valid email address to help ensure the survey's validity. =20 Thanks, Nick =20 Christopher N. "Nick" DelRegno, PMTS CNT, Ethernet Network Architecture & Design 400 International Pkwy Richardson, TX 75081 Tel: 972-729-3411 Email: Nick.DelRegno@verizon.com =20 ------_=_NextPart_001_01CBCC5D.80927EF2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We now have 9 valid responses to the VCCV = User Survey.  Time is running out.  The deadline for = submissions is February 25th.  So we have 11 days and = counting.

 

It is = important that we get as many participants as possible to ensure fair = representation in any future PW Control Word and VCCV related work in = the PWE3 working group.

 

I will be presenting the = results of the PW/VCCV survey in the form of a draft for IETF 80 in = Prague.

 

Thanks,

Nick

 

=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=3D=3D=3D=3D=3D=3D

 

All:

 

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

 

-          = Pseudowire Encapsulations

-          = Control Word Support

-          = Control Word Use

-          = VCCV Control Channel Support

-          = VCCV Control Channel Use

 

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

 

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

 

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

 

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

 

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

 

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

 

Thanks,

Nick

 

Christopher N. “Nick” DelRegno, = PMTS

CNT, Ethernet Network Architecture & = Design

400 International Pkwy

Richardson, TX  = 75081

Tel:  972-729-3411

Email:  = Nick.DelRegno@verizon.com

 

------_=_NextPart_001_01CBCC5D.80927EF2-- From matthew.bocci@alcatel-lucent.com Wed Feb 16 04:45:57 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CA623A6CB3 for ; Wed, 16 Feb 2011 04:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.248 X-Spam-Level: X-Spam-Status: No, score=-102.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cg4wcXcmnMl for ; Wed, 16 Feb 2011 04:45:56 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id 385BA3A6CA6 for ; Wed, 16 Feb 2011 04:45:55 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p1GCkLYC002186 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 16 Feb 2011 13:46:22 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 16 Feb 2011 13:46:22 +0100 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Wed, 16 Feb 2011 13:46:19 +0100 Thread-Topic: WG Poll on draft-jin-pwe3-cbit-negotiation-03.txt Thread-Index: AcvN14N/U4dKgzs0QU+tIbqk21be5g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C981779B9722matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-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: Wed, 16 Feb 2011 12:45:57 -0000 --_000_C981779B9722matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG, The authors of draft-jin-pwe3-cbit-negotiation-03 have asked that the WG ad= opt this as a PWE3 working group draft. This email begins a two week poll to help us judge if there is consensus to= move forward with the draft. Please post any comments to the PWE3 list by Wednesday 2nd March. Regards, Matthew & Andy --_000_C981779B9722matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
WG,

The authors of draft-jin-pwe3-cbit-negot= iation-03 have asked that the WG adopt this as a PWE3 working group draft.<= /span>

<= span class=3D"Apple-style-span" style=3D"font-size: 12px;">This email begin= s a two week poll to help us judge if there is consensus to move forward wi= th the draft.

Please post any comments to the PWE3 list by Wednesda= y 2nd March.

Regards,

Matthew & Andy<= /div> --_000_C981779B9722matthewboccialcatellucentcom_-- From raymond.key@hotmail.com Wed Feb 16 16:30:12 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87E1E3A6C3E for ; Wed, 16 Feb 2011 16:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCG-o8eu0Lhi for ; Wed, 16 Feb 2011 16:30:11 -0800 (PST) Received: from snt0-omc1-s48.snt0.hotmail.com (snt0-omc1-s48.snt0.hotmail.com [65.54.61.85]) by core3.amsl.com (Postfix) with ESMTP id B09F83A6C31 for ; Wed, 16 Feb 2011 16:30:11 -0800 (PST) Received: from SNT123-W51 ([65.55.90.9]) by snt0-omc1-s48.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Feb 2011 16:30:41 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_90adb439-30f9-4491-aafe-456e76815ad1_" X-Originating-IP: [203.35.135.136] From: Raymond Key Sender: To: , Date: Thu, 17 Feb 2011 11:30:41 +1100 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 17 Feb 2011 00:30:41.0143 (UTC) FILETIME=[E8072070:01CBCE39] Subject: Re: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-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: Thu, 17 Feb 2011 00:30:12 -0000 --_90adb439-30f9-4491-aafe-456e76815ad1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Support =20 Raymond Key =20 From: matthew.bocci@alcatel-lucent.com To: pwe3@ietf.org Date: Wed=2C 16 Feb 2011 13:46:19 +0100 Subject: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-03.txt WG=2C The authors of draft-jin-pwe3-cbit-negotiation-03 have asked that the WG ad= opt this as a PWE3 working group draft. This email begins a two week poll to help us judge if there is consensus to= move forward with the draft. Please post any comments to the PWE3 list by Wednesday 2nd March. Regards=2C Matthew & Andy _______________________________________________ pwe3 mailing list pwe3@ietf= .org https://www.ietf.org/mailman/listinfo/pwe3 = --_90adb439-30f9-4491-aafe-456e76815ad1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Support
 =3B
Raymond Key
 =3B
From: matthew.bocci@alcatel-lucent.com
To: pwe3@ietf.org
Date: Wed=2C= 16 Feb 2011 13:46:19 +0100
Subject: [PWE3] WG Poll on draft-jin-pwe3-cb= it-negotiation-03.txt

WG=2C

The authors of =3Bdraft-jin-pwe3-cbit-negotiation-03 have= asked that the WG adopt this as a PWE3 working group draft.<= /FONT>

<= /SPAN>
This email begins a two week poll to help us judge if there is co= nsensus to move forward with the draft.

Please post any comments to the PWE3 list by Wednesday 2nd March.=

Regards=2C

Matthew &=3B Andy

______________= _________________________________ pwe3 mailing list pwe3@ietf.org https://w= ww.ietf.org/mailman/listinfo/pwe3 = --_90adb439-30f9-4491-aafe-456e76815ad1_-- From vishwas.ietf@gmail.com Wed Feb 16 22:06:26 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34FE3A6D41 for ; Wed, 16 Feb 2011 22:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 jnjj8cCZKwu9 for ; Wed, 16 Feb 2011 22:06:23 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3B9333A6D31 for ; Wed, 16 Feb 2011 22:06:21 -0800 (PST) Received: by wyf23 with SMTP id 23so2291838wyf.31 for ; Wed, 16 Feb 2011 22:06:50 -0800 (PST) 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 :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1yzYgySaz1ZSavDrsjQ/KOw55Q3KBRGt42RqW9BkB/A=; b=e6hB/sSPBlgbjwHk+PpjaQetjwMvXe5uc62FDzwzRBFGvaJc+3/dO99tpNVuta3yaB zbYGz7BOaxcSItZOqgsODz83aAnSeGtpRPsIFVU43LRZ/yVEVHLOO7b7AxXC+6hYF7kf 6wSOTQWLMI82y9rosWbg1JMEmkv/jXbmOMnhI= 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=mWvusOtK48noNPl6D7+/V5aYUjQJMFy2SkLKAC9cdB87HIaYbFxNw5ewI1fJVWKnMQ wkr+JmNDCXhUwO7tf6P4YhtYOSOblusQIB9HTFdtNCWsqxes35giyC701rda40YSK88T +IRbz8QeRuFP/EqvxizVfwfT3gmmA2LWUoY0A= MIME-Version: 1.0 Received: by 10.216.164.69 with SMTP id b47mr1138736wel.79.1297922809237; Wed, 16 Feb 2011 22:06:49 -0800 (PST) Received: by 10.216.47.81 with HTTP; Wed, 16 Feb 2011 22:06:49 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Feb 2011 22:06:49 -0800 Message-ID: From: Vishwas Manral To: "Bocci, Matthew (Matthew)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pwe3@ietf.org" Subject: Re: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-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: Thu, 17 Feb 2011 06:06:26 -0000 Support the draft. -Vishwas On Wed, Feb 16, 2011 at 4:46 AM, Bocci, Matthew (Matthew) wrote: > WG, > The authors of=A0draft-jin-pwe3-cbit-negotiation-03 have asked that the W= G > adopt this as a PWE3 working group draft. > This email begins a two week poll to help us judge if there is consensus = to > move forward with the draft. > Please post any comments to the PWE3 list by Wednesday 2nd March. > Regards, > Matthew & Andy > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > From frederic.jounay@orange-ftgroup.com Thu Feb 17 00:07:06 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8897A3A6CAD for ; Thu, 17 Feb 2011 00:07:06 -0800 (PST) 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 bXeb+8U+Q8ae for ; Thu, 17 Feb 2011 00:07:05 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id C55373A6C68 for ; Thu, 17 Feb 2011 00:07:04 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5F0A8FC400E; Thu, 17 Feb 2011 09:07:39 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 50C6EFC400B; Thu, 17 Feb 2011 09:07:39 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Feb 2011 09:07:34 +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_01CBCE79.BABE3B6D" Date: Thu, 17 Feb 2011 09:07:32 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-03.txt Thread-Index: AcvOOf2LDNt2BwpPTBKY5CjtdH24KQAP6dgg References: From: To: , X-OriginalArrivalTime: 17 Feb 2011 08:07:34.0366 (UTC) FILETIME=[BB94FFE0:01CBCE79] Subject: Re: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-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: Thu, 17 Feb 2011 08:07:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBCE79.BABE3B6D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. =20 Frederic=20 ________________________________ From: matthew.bocci@alcatel-lucent.com To: pwe3@ietf.org Date: Wed, 16 Feb 2011 13:46:19 +0100 Subject: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-03.txt WG, The authors of draft-jin-pwe3-cbit-negotiation-03 have asked that the WG adopt this as a PWE3 working group draft. This email begins a two week poll to help us judge if there is consensus to move forward with the draft. Please post any comments to the PWE3 list by Wednesday 2nd March. Regards, Matthew & Andy _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3=20 ------_=_NextPart_001_01CBCE79.BABE3B6D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support.
 
Frederic 
From: matthew.bocci@alcatel-lucent.com
To: = pwe3@ietf.org
Date: Wed,=20 16 Feb 2011 13:46:19 +0100
Subject: [PWE3] WG Poll on=20 draft-jin-pwe3-cbit-negotiation-03.txt

WG,

The authors of draft-jin-pwe3-cbit-negotiation-03 have asked = that the=20 WG adopt this as a PWE3 working group = draft.

This email begins a two week poll to help us = judge if=20 there is consensus to move forward with the = draft.

Please post any comments to the PWE3 list by = Wednesday=20 2nd March.

Regards,

Matthew &=20 Andy

______________________________________= _________=20 pwe3 mailing list pwe3@ietf.org = https://www.ietf.org/mailman/listinfo/pwe3=20 ------_=_NextPart_001_01CBCE79.BABE3B6D-- From chen.ran@zte.com.cn Thu Feb 17 01:41:32 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324E93A6DB6 for ; Thu, 17 Feb 2011 01:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.146 X-Spam-Level: X-Spam-Status: No, score=-96.146 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 gc3JKmxGNiDK for ; Thu, 17 Feb 2011 01:41:31 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 0BBAE3A6D69 for ; Thu, 17 Feb 2011 01:41:30 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205951397396305; Thu, 17 Feb 2011 17:36:49 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.2368962204; Thu, 17 Feb 2011 17:35:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1H9ZMxd004642; Thu, 17 Feb 2011 17:35:22 +0800 (GMT-8) (envelope-from chen.ran@zte.com.cn) In-Reply-To: To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: chen.ran@zte.com.cn Date: Thu, 17 Feb 2011 17:35:03 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-17 17:35:23, Serialize complete at 2011-02-17 17:35:23 Content-Type: multipart/alternative; boundary="=_alternative 0034BE4F4825783A_=" X-MAIL: mse01.zte.com.cn p1H9ZMxd004642 Subject: Re: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-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: Thu, 17 Feb 2011 09:41:32 -0000 This is a multipart message in MIME format. --=_alternative 0034BE4F4825783A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KVGhhbmtzDQpDaGVuDQoNCg0KDQoNCiJCb2NjaSwgTWF0dGhldyAoTWF0dGhl dykiIDxtYXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbT4gDQq3orz+yMs6ICBwd2UzLWJv dW5jZXNAaWV0Zi5vcmcNCjIwMTEtMDItMTYgMjA6NDYNCg0KytW8/sjLDQoicHdlM0BpZXRmLm9y ZyIgPHB3ZTNAaWV0Zi5vcmc+DQqzrcvNDQoNCtb3zOINCltQV0UzXSBXRyBQb2xsIG9uIGRyYWZ0 LWppbi1wd2UzLWNiaXQtbmVnb3RpYXRpb24tMDMudHh0DQoNCg0KDQoNCg0KDQpXRywNCg0KVGhl IGF1dGhvcnMgb2YgZHJhZnQtamluLXB3ZTMtY2JpdC1uZWdvdGlhdGlvbi0wMyBoYXZlIGFza2Vk IHRoYXQgdGhlIFdHIA0KYWRvcHQgdGhpcyBhcyBhIFBXRTMgd29ya2luZyBncm91cCBkcmFmdC4N Cg0KVGhpcyBlbWFpbCBiZWdpbnMgYSB0d28gd2VlayBwb2xsIHRvIGhlbHAgdXMganVkZ2UgaWYg dGhlcmUgaXMgY29uc2Vuc3VzIA0KdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhlIGRyYWZ0Lg0KDQpQ bGVhc2UgcG9zdCBhbnkgY29tbWVudHMgdG8gdGhlIFBXRTMgbGlzdCBieSBXZWRuZXNkYXkgMm5k IE1hcmNoLg0KDQpSZWdhcmRzLA0KDQpNYXR0aGV3ICYgQW5keV9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwd2UzIG1haWxpbmcgbGlzdA0KcHdlM0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQoNCg0K --=_alternative 0034BE4F4825783A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlN1cHBvcnQuPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3M8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNoZW48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRo PTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7Qm9jY2ksIE1hdHRo ZXcgKE1hdHRoZXcpJnF1b3Q7DQombHQ7bWF0dGhldy5ib2NjaUBhbGNhdGVsLWx1Y2VudC5jb20m Z3Q7PC9iPiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7I yzogJm5ic3A7cHdlMy1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjIwMTEtMDItMTYgMjA6NDY8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7cHdlM0BpZXRmLm9yZyZxdW90 OyAmbHQ7cHdlM0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+ PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltQV0UzXSBXRyBQb2xsIG9uIGRyYWZ0LWppbi1wd2Uz LWNiaXQtbmVnb3RpYXRpb24tMDMudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9IkNhbGlicmkiPldHLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTEgZmFjZT0iQ2FsaWJyaSI+VGhlIGF1dGhvcnMgb2YgPC9mb250Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5kcmFmdC1qaW4tcHdlMy1jYml0LW5lZ290aWF0aW9u LTAzDQpoYXZlIGFza2VkIHRoYXQgdGhlIFdHIGFkb3B0IHRoaXMgYXMgYSBQV0UzIHdvcmtpbmcg Z3JvdXAgZHJhZnQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5UaGlzIGVtYWlsIGJlZ2lucyBhIHR3byB3ZWVrIHBvbGwgdG8NCmhlbHAgdXMganVkZ2Ug aWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHRoZSBkcmFmdC48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlBsZWFzZSBwb3N0 IGFueSBjb21tZW50cyB0byB0aGUgUFdFMw0KbGlzdCBieSBXZWRuZXNkYXkgMm5kIE1hcmNoLjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmVnYXJkcyw8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPk1hdHRoZXcg JmFtcDsgQW5keTwvZm9udD48Zm9udCBzaXplPTI+PHR0Pl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcHdlMyBtYWlsaW5nIGxpc3Q8YnI+DQpwd2Uz QGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2Uz PGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo= --=_alternative 0034BE4F4825783A_=-- From fu.xihua@zte.com.cn Thu Feb 17 02:02:38 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3CE3A6DB8 for ; Thu, 17 Feb 2011 02:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.146 X-Spam-Level: X-Spam-Status: No, score=-96.146 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 dKeTmjceIxqd for ; Thu, 17 Feb 2011 02:02:37 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id F3BA43A6ABB for ; Thu, 17 Feb 2011 02:02:36 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101397396305; Thu, 17 Feb 2011 18:00:56 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 84746.2368962204; Thu, 17 Feb 2011 17:57:01 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p1H9uuk9045198; Thu, 17 Feb 2011 17:56:56 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn) To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Thu, 17 Feb 2011 17:56:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-17 17:56:58, Serialize complete at 2011-02-17 17:56:58 Content-Type: multipart/alternative; boundary="=_alternative 0036A7E14825783A_=" X-MAIL: mse02.zte.com.cn p1H9uuk9045198 Subject: Re: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-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: Thu, 17 Feb 2011 10:02:38 -0000 This is a multipart message in MIME format. --=_alternative 0036A7E14825783A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KDQoiQm9jY2ksIE1hdHRoZXcgKE1hdHRoZXcpIiA8bWF0dGhldy5ib2NjaUBh bGNhdGVsLWx1Y2VudC5jb20+IA0Kt6K8/sjLOiAgcHdlMy1ib3VuY2VzQGlldGYub3JnIA0KMjAx MS0wMi0xNiAyMDo0NiANCg0KDQrK1bz+yMsNCiJwd2UzQGlldGYub3JnIiA8cHdlM0BpZXRmLm9y Zz4gDQqzrcvNDQoNCg0KW1BXRTNdIFdHIFBvbGwgb24gZHJhZnQtamluLXB3ZTMtY2JpdC1uZWdv dGlhdGlvbi0wMy50eHQNCg0KDQoNCg0KDQpXRywgDQoNClRoZSBhdXRob3JzIG9mIGRyYWZ0LWpp bi1wd2UzLWNiaXQtbmVnb3RpYXRpb24tMDMgaGF2ZSBhc2tlZCB0aGF0IHRoZSBXRyANCmFkb3B0 IHRoaXMgYXMgYSBQV0UzIHdvcmtpbmcgZ3JvdXAgZHJhZnQuIA0KDQpUaGlzIGVtYWlsIGJlZ2lu cyBhIHR3byB3ZWVrIHBvbGwgdG8gaGVscCB1cyBqdWRnZSBpZiB0aGVyZSBpcyBjb25zZW5zdXMg DQp0byBtb3ZlIGZvcndhcmQgd2l0aCB0aGUgZHJhZnQuIA0KDQpQbGVhc2UgcG9zdCBhbnkgY29t bWVudHMgdG8gdGhlIFBXRTMgbGlzdCBieSBXZWRuZXNkYXkgMm5kIE1hcmNoLiANCg0KUmVnYXJk cywgDQoNCk1hdHRoZXcgJiBBbmR5X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnB3ZTMgbWFpbGluZyBsaXN0DQpwd2UzQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTMNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpwd2UzIG1haWxpbmcgbGlzdA0KcHdlM0BpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQo= --=_alternative 0036A7E14825783A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlN1cHBvcnQuPC9mb250Pg0KPGJy Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01 MCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O0JvY2NpLCBNYXR0aGV3 IChNYXR0aGV3KSZxdW90Ow0KJmx0O21hdHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tJmd0 OzwvYj4gPGJyPg0Kt6K8/sjLOiAmbmJzcDtwd2UzLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjIwMTEtMDItMTYgMjA6NDY8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTQ5JT4NCjxicj4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MTIlPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRk IHdpZHRoPTg3JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7cHdlM0BpZXRm Lm9yZyZxdW90Ow0KJmx0O3B3ZTNAaWV0Zi5vcmcmZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4gPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0K PHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bUFdFM10gV0cgUG9sbCBvbiBkcmFmdC1q aW4tcHdlMy1jYml0LW5lZ290aWF0aW9uLTAzLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPGJy Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD00OSU+DQo8 dGQgd2lkdGg9NTAlPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTEgZmFj ZT0iQ2FsaWJyaSI+V0csPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxi cj4NCjwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KVGhlIGF1dGhvcnMg b2YgPC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5kcmFmdC1qaW4tcHdlMy1j Yml0LW5lZ290aWF0aW9uLTAzDQpoYXZlIGFza2VkIHRoYXQgdGhlIFdHIGFkb3B0IHRoaXMgYXMg YSBQV0UzIHdvcmtpbmcgZ3JvdXAgZHJhZnQuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGJy Pg0KVGhpcyBlbWFpbCBiZWdpbnMgYSB0d28gd2VlayBwb2xsIHRvIGhlbHAgdXMganVkZ2UgaWYg dGhlcmUgaXMgY29uc2Vuc3VzDQp0byBtb3ZlIGZvcndhcmQgd2l0aCB0aGUgZHJhZnQuPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpQbGVhc2UgcG9zdCBhbnkgY29tbWVudHMgdG8gdGhl IFBXRTMgbGlzdCBieSBXZWRuZXNkYXkgMm5kIE1hcmNoLjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NClJlZ2FyZHMsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4g PGJyPg0KPC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpNYXR0aGV3 ICZhbXA7IEFuZHk8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnB3ZTMgbWFpbGluZyBsaXN0PGJyPg0KcHdl M0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHdl MzwvdHQ+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yPjx0dD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnB3ZTMgbWFpbGluZyBsaXN0PGJyPg0KcHdlM0BpZXRmLm9yZzxicj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHdlMzwvdHQ+PC9mb250Pg0K --=_alternative 0036A7E14825783A_=-- From rrahman@cisco.com Thu Feb 17 04:10:23 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D5D3A6DC6 for ; Thu, 17 Feb 2011 04:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8jfntgB3+Lcy for ; Thu, 17 Feb 2011 04:10:22 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 250013A6DA9 for ; Thu, 17 Feb 2011 04:10:22 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQBAKueXE2tJV2Z/2dsb2JhbACCSZUFjktzoCabS4VeBIUKikY X-IronPort-AV: E=Sophos;i="4.60,485,1291593600"; d="scan'208,217";a="216727773" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 17 Feb 2011 12:10:52 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p1HCAqVe031532; Thu, 17 Feb 2011 12:10:52 GMT Received: from xmb-rcd-204.cisco.com ([72.163.62.211]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Feb 2011 06:10:52 -0600 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_01CBCE9B.B87A02D2" Date: Thu, 17 Feb 2011 06:10:47 -0600 Message-ID: <654701C60BCC7C4EBD533B89D72BDFEA03A84157@XMB-RCD-204.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-03.txt Thread-Index: AcvN14N/U4dKgzs0QU+tIbqk21be5gAxCV5Q References: From: "Reshad Rahman (rrahman)" To: "Bocci, Matthew (Matthew)" , X-OriginalArrivalTime: 17 Feb 2011 12:10:52.0388 (UTC) FILETIME=[B8AE6240:01CBCE9B] Subject: Re: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-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: Thu, 17 Feb 2011 12:10:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBCE9B.B87A02D2 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 (Matthew) Sent: Wednesday, February 16, 2011 7:46 AM To: pwe3@ietf.org Subject: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-03.txt =20 WG, =20 The authors of draft-jin-pwe3-cbit-negotiation-03 have asked that the WG adopt this as a PWE3 working group draft. =20 This email begins a two week poll to help us judge if there is consensus to move forward with the draft. =20 Please post any comments to the PWE3 list by Wednesday 2nd March. =20 Regards, =20 Matthew & Andy ------_=_NextPart_001_01CBCE9B.B87A02D2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

From:= pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = Bocci, Matthew (Matthew)
Sent: Wednesday, February 16, 2011 7:46 AM
To: pwe3@ietf.org
Subject: [PWE3] WG Poll on = draft-jin-pwe3-cbit-negotiation-03.txt

 

WG,

 

The authors = of draft-jin-pwe3-cbit-negotiation-03 have asked that the WG = adopt this as a PWE3 working group draft.

 

This email begins a two = week poll to help us judge if there is consensus to move forward with the = draft.

 

Please post any comments = to the PWE3 list by Wednesday 2nd March.

 

Regards,

 

Matthew & = Andy

------_=_NextPart_001_01CBCE9B.B87A02D2-- From prvs=9029960ae5=edwin.mallette@bhnis.com Thu Feb 17 04:20:37 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417C23A6D92 for ; Thu, 17 Feb 2011 04:20:37 -0800 (PST) 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 RdubvnsrhHG3 for ; Thu, 17 Feb 2011 04:20:36 -0800 (PST) Received: from mx2.mybrighthouse.com (MX3.mybrighthouse.com [209.16.122.105]) by core3.amsl.com (Postfix) with ESMTP id 364B03A6C9B for ; Thu, 17 Feb 2011 04:20:36 -0800 (PST) Received: from pps.filterd (mx3 [127.0.0.1]) by mx3.mybrighthouse.com (8.14.3/8.14.3) with SMTP id p1HCJxMk014005; Thu, 17 Feb 2011 07:21:05 -0500 Received: from cntpaowa2.corp.local ([10.225.4.6]) by mx3.mybrighthouse.com with ESMTP id ugyncs06s-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Feb 2011 07:21:05 -0500 Received: from CNEMAIL.corp.local ([10.225.1.130]) by cntpaowa2.corp.local ([10.225.4.6]) with mapi; Thu, 17 Feb 2011 07:21:04 -0500 From: "Mallette, Edwin" To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Date: Thu, 17 Feb 2011 07:21:04 -0500 Thread-Topic: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-03.txt Thread-Index: AcvOnSVU/o456OrkS/CVUxFi2wk3fA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9827CD366B4edwinmallettebhniscom_" MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1102170061 Subject: Re: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-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: Thu, 17 Feb 2011 12:20:37 -0000 --_000_C9827CD366B4edwinmallettebhniscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. From: "Bocci, Matthew (Matthew)" > Date: Wed, 16 Feb 2011 07:46:19 -0500 To: "pwe3@ietf.org" > Subject: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-03.txt WG, The authors of draft-jin-pwe3-cbit-negotiation-03 have asked that the WG ad= opt this as a PWE3 working group draft. This email begins a two week poll to help us judge if there is consensus to= move forward with the draft. Please post any comments to the PWE3 list by Wednesday 2nd March. Regards, Matthew & Andy ________________________________ 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. --_000_C9827CD366B4edwinmallettebhniscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support.

From: "Bocci, Matthew (Matthew= )" <matthew.boc= ci@alcatel-lucent.com>
Date: Wed, 16 Feb 2011 07:46:19 -05= 00
To: "pwe3@ietf.org" <pwe3@i= etf.org>
Subject: [PWE3] WG Poll on draft-ji= n-pwe3-cbit-negotiation-03.txt

WG,

The authors of draft-jin-pwe3-cbit-negotiation-03 have asked that the WG adopt this as a PWE3 working group draft.

This email begins a two week poll to help us judge if there is = consensus to move forward with the draft.

Please post any comments to the PWE3 list by Wednesday 2nd Marc= h.

Regards,

Matthew & Andy

CONFIDENTIALITY NOTICE: This= e-mail may contain information that is privileged, confidential or otherwi= se protected from disclosure. If you are not the intended recipient of this= e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.
 --_000_C9827CD366B4edwinmallettebhniscom_-- From matthew.bocci@alcatel-lucent.com Thu Feb 17 05:34:11 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29ED63A6CCA; Thu, 17 Feb 2011 05:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.249 X-Spam-Level: X-Spam-Status: No, score=-104.249 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UWl1YKipeAQ; Thu, 17 Feb 2011 05:34:09 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 292023A6CAE; Thu, 17 Feb 2011 05:34:08 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p1HDXfjc008936 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Feb 2011 14:34:38 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 17 Feb 2011 14:34:35 +0100 From: "Bocci, Matthew (Matthew)" To: "pwe3@ietf.org" Date: Thu, 17 Feb 2011 14:34:34 +0100 Thread-Topic: PWE3 WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-00 Thread-Index: AcvOp2qo3CL3sSTlSLeLd/7Gd8zznQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: [PWE3] PWE3 WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-00 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, 17 Feb 2011 13:34:11 -0000 This email begins a working group last call for draft-ietf-pwe3-mpls-tp-gal-in-pw-00.txt. This is a very short draft but since there are other MPLS-TP-related last calls going on concurrently, this will be a three-week last call. This WG LC will end of 11th March 2011. Please respond with any comments to the PWE3 mailing list. Regards, Matthew and Andy =20 From matthew.bocci@alcatel-lucent.com Thu Feb 17 06:47:38 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B303E3A6E58; Thu, 17 Feb 2011 06:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.582 X-Spam-Level: X-Spam-Status: No, score=-105.582 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMt2TdPGGAGN; Thu, 17 Feb 2011 06:47:37 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 2C8633A6E49; Thu, 17 Feb 2011 06:47:36 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p1HEkPQC010389 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Feb 2011 15:46:49 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 17 Feb 2011 15:46:29 +0100 From: "Bocci, Matthew (Matthew)" To: "greg.jones@itu.int" Date: Thu, 17 Feb 2011 15:46:26 +0100 Thread-Topic: IETF PWE3 Working Group Last Call on draft-ietf-pwe3-mpls-tp-gal-in-pw-00 Thread-Index: AcvOsXXjHjesPGdNSf2nivDjEEvehQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C982E542995Ematthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "mpls-tp@ietf.org" , "stbryant@cisco.com" , "ahmpls-tp@lists.itu.int" , "malcolm.betts@zte.com.cn" , "yoichi.maeda@ttc.or.jp" , "Lam, Hing-Kam \(Kam\)" , "pwe3@ietf.org" , "adrian.farrel@huawei.com" , "tsbsg15@itu.int" , "hhelvoort@huawei.com" , "Andrew. Malis" , "ghani.abbas@ericsson.com" Subject: [PWE3] IETF PWE3 Working Group Last Call on draft-ietf-pwe3-mpls-tp-gal-in-pw-00 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, 17 Feb 2011 14:47:38 -0000 --_000_C982E542995Ematthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Title: IETF PWE3 Working Group Last Call on draft-ietf-pwe3-mpls-tp-gal-in-= pw-00 Submission Date: 2011-02-17 From: IETF PWE3 WG (Matthew Bocci) To: SG15, Q9, Q10, Q12 and Q14 (greg.jones@itu.int) Cc: yoichi.maeda@ttc.or.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int adrian.farrel@huawei.com stbryant@cisco.com pwe3@ietf.org mpls-tp@ietf.org mpls@ietf.org Response Contact: matthew.bocci@alcatel-lucent.com andrew.g.malis@verizon.com Technical Contact: andrew.malis@verizon.com Purpose: For action Deadline: 2011-03-11 Action Needed Attachments: (none) Body: The PWE3 working group would like to inform you that we have started a work= ing group last call on "Using the Generic Associated Channel Label for Pseu= dowire in MPLS-TP" (draft-ietf-pwe3-mpls-tp-gal-in-pw-00). This is a very short draft but since there are other MPLS-TP-related last c= alls going on concurrently, this will be a three-week last call. Since we intend to work the comments received through this working group l= ast call into the documents that will be discussed at the IETF meeting in P= rague, we would like to receive comments from the ITU-T by March 11, 2011. Matthew Bocci Andrew Malis IETF PWE3 Working Group Chairs --_000_C982E542995Ematthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Title: IETF PWE3 Working Group Last Call on draft-ietf-pwe3-mpls-tp-g= al-in-pw-00

Submission Date:   &nbs= p;2011-02-17

From:    IETF PWE= 3 WG (Matthew Bocci)
To:     SG15, Q9, Q10, Q= 12 and Q14 (greg.jones@itu.int)
mpls@ietf.org
Response = Contact:    matthew.bocci@alcatel-lucent.com
Technical= Contact:    andrew.malis@verizon.com
Purpose:    Fo= r action
Deadline:    2011-03-11 Action Neede= d
Attachments:     (none)
Body:&nbs= p;   


The PWE3 worki= ng group would like to inform you that we have started a working group last= call on "Using the Generic Associated Channel Label for Pseudowire in MPLS= -TP" (draft-ietf-pwe3-mpls-tp-gal-in-pw-00).

This = is a very short draft but since there are other MPLS-TP-related last calls = going on concurrently, this will be a three-week last call.

<= /div>
Since we intend to work the comments received through this workin= g  group last call into the documents that will be discussed at t= he IETF meeting in Prague, we would like to receive comments from the ITU-T= by March 11, 2011.


Matthew Bocci
Andrew Malis

IETF PWE3 Working Group Chai= rs
--_000_C982E542995Ematthewboccialcatellucentcom_-- From wwwrun@core3.amsl.com Thu Feb 17 14:04:47 2011 Return-Path: X-Original-To: pwe3@ietf.org Delivered-To: pwe3@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 468723A6D31; Thu, 17 Feb 2011 14:04:47 -0800 (PST) From: Stephanie McCammon(IETF PWE3 WG) To: Greg Jones Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110217220447.468723A6D31@core3.amsl.com> Date: Thu, 17 Feb 2011 14:04:47 -0800 (PST) Cc: mpls@ietf.org, stbryant@cisco.com, greg.jones@itu.int, mpls-tp@ietf.or, malcolm.betts@zte.com.cn, yoichi.maeda@ttc.or.jp, kam.lam@alcatel-lucent.com, ahmpls-tp@lists.itu.int, pwe3@ietf.org, adrian.farrel@huawei.com, tsbsg15@itu.int, hhelvoort@huawei.com, andrew.g.malis@verizon.com, ghani.abbas@ericsson.com Subject: [PWE3] New Liaison Statement, "IETF PWE3 Working Group Last Call on draft-ietf-pwe3-mpls-tp-gal-in-pw-00" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Matthew Bocci List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 22:04:47 -0000 Title: IETF PWE3 Working Group Last Call on draft-ietf-pwe3-mpls-tp-gal-in-pw-00 Submission Date: 2011-02-17 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=1017 Please reply by 2011-03-11 From: Stephanie McCammon(IETF PWE3 WG) To: ITU-T SG15, Q9, Q10, Q12 and Q14(Greg Jones ) Cc: yoichi.maeda@ttc.or.jp greg.jones@itu.int ghani.abbas@ericsson.com hhelvoort@huawei.com malcolm.betts@zte.com.cn kam.lam@alcatel-lucent.com tsbsg15@itu.int ahmpls-tp@lists.itu.int adrian.farrel@huawei.com stbryant@cisco.com pwe3@ietf.org mpls@ietf.org mpls-tp@ietf.or Reponse Contact: matthew.bocci@alcatel-lucent.com andrew.g.malis@verizon.com Technical Contact: andrew.g.malis@verizon.com Purpose: For action Body: The PWE3 working group would like to inform you that we have started a working group last call on "Using the Generic Associated Channel Label for Pseudowire in MPLS-TP" (draft-ietf-pwe3-mpls-tp-gal-in-pw-00). This is a very short draft but since there are other MPLS-TP-related last calls going on concurrently, this will be a three-week last call. Since we intend to work the comments received through this working group last call into the documents that will be discussed at the IETF meeting in Prague, we would like to receive comments from the ITU-T by March 11, 2011. Matthew Bocci Andrew Malis IETF PWE3 Working Group Chairs Attachment(s): No document has been attached From simon.delord@gmail.com Thu Feb 17 17:36:48 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C153A6C72 for ; Thu, 17 Feb 2011 17:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 q+1eUiatXdfN for ; Thu, 17 Feb 2011 17:36:48 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B20D13A6C3E for ; Thu, 17 Feb 2011 17:36:47 -0800 (PST) Received: by fxm9 with SMTP id 9so3414999fxm.31 for ; Thu, 17 Feb 2011 17:37:19 -0800 (PST) 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 :message-id:subject:from:to:cc:content-type; bh=bilQxLroGgNsOrtdtRzyqbVpll19H+BaWOnG/KVxoZc=; b=XlvyMRpxiFClkIl9+xt2C5MUVx5Za/bkGlwC5tHGoqxvWq82WC1jbxx+LwT43+L8xQ 2R6/bWe12mpN0uZesJFAYFZwp2G7XECigEj8EGv3GB6FZiWAO89lH8KdbWURHfAfDSfn gEkrzeZET0cXsGZVWCkNZ8Qk+NGDCtw9iPKUE= 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; b=CH3CayrzhcqY0nNhyIxZ5WvqSaOZVtgHffb1UsOqNhSUhEQncxxBhTIF4P7W4JcmKD S3QOXqkLk8po+LJ5TK1Xu9fdDGyNQRkYVqmfvJszsTEdCWTqgTxeZrA2bO9Ny/vjE4BI v3n3fID9kvzxq7SyUfrMUnFOQ4SnSdFwijFGs= MIME-Version: 1.0 Received: by 10.223.83.194 with SMTP id g2mr166936fal.75.1297992999059; Thu, 17 Feb 2011 17:36:39 -0800 (PST) Received: by 10.223.144.137 with HTTP; Thu, 17 Feb 2011 17:36:38 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Feb 2011 09:36:38 +0800 Message-ID: From: Simon Delord To: pwe3 Content-Type: multipart/alternative; boundary=20cf30433e4ca1400a049c848b04 Subject: Re: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-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, 18 Feb 2011 01:36:49 -0000 --20cf30433e4ca1400a049c848b04 Content-Type: text/plain; charset=ISO-8859-1 support. regards, Simon 2011/2/16 Bocci, Matthew (Matthew) > WG, > > The authors of draft-jin-pwe3-cbit-negotiation-03 have asked that the WG > adopt this as a PWE3 working group draft. > > This email begins a two week poll to help us judge if there is consensus to > move forward with the draft. > > Please post any comments to the PWE3 list by Wednesday 2nd March. > > Regards, > > Matthew & Andy > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --20cf30433e4ca1400a049c848b04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
support.
regards,
Simon

2011/2/16 Bocci, Matthew (Matthew) <matthew.bocci@= alcatel-lucent.com>
WG,

The authors of=A0draft-jin-pwe3-cbit-negotiat= ion-03 have asked that the WG adopt this as a PWE3 working group draft.

<= /div>
This email begins a two week poll to help us judge if there is consens= us to move forward with the draft.

Please post any comments to the PWE3 list by Wednesday 2nd March.

Regards,

Matthew & Andy

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


--20cf30433e4ca1400a049c848b04-- From gregimirsky@gmail.com Thu Feb 17 22:46:36 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11863A6D72; Thu, 17 Feb 2011 22:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, 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 SvZvAAJlzCXY; Thu, 17 Feb 2011 22:46:34 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 137123A6D6D; Thu, 17 Feb 2011 22:46:32 -0800 (PST) Received: by vws7 with SMTP id 7so1857315vws.31 for ; Thu, 17 Feb 2011 22:47:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=xYg5vczfCME4GJsR8FblCbXMVCVcfzDurewQ8UrgMaE=; b=xExpT6gzSVSLXwmnCoukrkVsTDHI/sWu6W3TYtXC12AFj3QAUVBw/j2idBOPuHjmly b4gh6VAKhetN/a9aXP7CVaVXNvXy2JU3yJrRHFcQ7PygxRacnDyt/O/+fS6pM2cX7XkS +jEQtm73fjaWyn+cC6W5WqYwsf0RYzgVypVyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=PpRD0yF7OSDzdI3kcYo9ItTIKzLUxbBqpkq+Q+v2F4iQHo5Bl91HDzBF9XBm8Q9mHd EqP9RKHiA7Fe53hXyAIGKlqJd7L6QC682vu7LXr8kmlbQ6xskmq9sK3iP2e3FvizIONI e/3YcjViVxfdhLmCpqPvwka1P+9M0pvtuxktw= MIME-Version: 1.0 Received: by 10.52.157.65 with SMTP id wk1mr556497vdb.125.1298011624253; Thu, 17 Feb 2011 22:47:04 -0800 (PST) Received: by 10.52.165.9 with HTTP; Thu, 17 Feb 2011 22:47:04 -0800 (PST) Date: Thu, 17 Feb 2011 22:47:04 -0800 Message-ID: From: Greg Mirsky To: Luca Martini Content-Type: multipart/alternative; boundary=bcaec53f931fc72a77049c88e1ce Cc: mpls@ietf.org, mpls-tp@ietf.org, lihan@chinamobile.com, pwe3 , HUANG Feng F Subject: [PWE3] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 06:46:36 -0000 --bcaec53f931fc72a77049c88e1ce Content-Type: text/plain; charset=ISO-8859-1 Dear Authors and All, prior to the meeting in Bejing and acceptance of this proposal as WG document Luca and I agreed that use of GAL with PW VCCV presents a problem. I was not attending the IETF-79, nor I found discussion of this issue in the minutes. I think that this issue should be specified, explained. In my view, this document updates not only RFC 5586 but RFC 5085 too. Regards, Greg Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini wrote: > Greg, > > You are correct , the proposed update does not propose any changes to VCCV. > However the problem with vccv is not as simple as to ask for a new code > point from IANA. > Given the good amount of discussion on this point, we should probably have > a discussion in Beijing. > > Luca > > > > On 10/29/2010 05:07 PM, Greg Mirsky wrote: > > Dear Authors, > I think that proposed update of the Section 4.2. RFC 5586 makes it possible > to use GAL on MPLS-TP PW that uses Control Word. I consider it to be > conflict between PW VCCV CC types because use of GAL is not negotiated > through PW VCCV negotiation. To avoid such situation I propose: > > - in Section 5 request IANA to assign new CC Type "MPLS Generic > Associated Channel Label" > - assign precedence to new CC Type that affects Section 7 RFC 5085 > > Regards, > Greg > > > > _______________________________________________ > mpls mailing listmpls@ietf.orghttps://www.ietf.org/mailman/listinfo/mpls > > > --bcaec53f931fc72a77049c88e1ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors and All,
prior to the meeting in Bejing and acceptance of t= his proposal as WG document Luca and I agreed that use of GAL with PW VCCV = presents a problem.
I was not attending the IETF-79, nor I found discuss= ion of this issue in the minutes. I think that this issue should be specifi= ed, explained. In my view, this document updates not only RFC 5586
but RFC 5085 too.

Regards,
Greg

Comment to draft-lm-pwe3-m= pls-tp-gal-in-pw-00.txt

On Sat, Oct 30, 2= 010 at 10:14 AM, Luca Martini <lmartini@cisco.com> wrote:
=20 =20 =20 =20
Greg,

You are correct , the proposed update does not propose any changes to VCCV.
However the problem with vccv is not as simple as to ask for a new code point from IANA.
Given the good amount of discussion on this point, we should probably have a discussion in Beijing.

Luca



On 10/29/2010 05:07 PM, Greg Mirsky wrote: 
Dear Authors,
I think that proposed update of the Section 4.2. RFC 5586 makes it possible
to use GAL on MPLS-TP PW that uses Control Word. I consider it to be
conflict between PW VCCV CC types because use of GAL is not negotiated
through PW VCCV negotiation. To avoid such situation I propose:

   - in Section 5 request IANA to assign new CC Type "MPLS Generic
   Associated Channel Label"
   - assign precedence to new CC Type that affects Section 7 RFC 5085

Regards,
Greg



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


--bcaec53f931fc72a77049c88e1ce-- From Alexander.Vainshtein@ecitele.com Thu Feb 17 23:07:36 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03EB3A68DD; Thu, 17 Feb 2011 23:07:36 -0800 (PST) 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 GdrWklM+u8kJ; Thu, 17 Feb 2011 23:07:34 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 247803A6A84; Thu, 17 Feb 2011 23:07:32 -0800 (PST) X-AuditID: 93eaf2e7-b7b9cae000002a0e-67-4d5e1ad78877 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 58.04.10766.7DA1E5D4; Fri, 18 Feb 2011 09:08:07 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Fri, 18 Feb 2011 09:08:04 +0200 From: Alexander Vainshtein To: Greg Mirsky Date: Fri, 18 Feb 2011 09:05:19 +0200 Thread-Topic: [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Thread-Index: AcvPN6zTJGq/0XxDTGy6v16DWGU3fgAAocFM Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEA8BILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAARci5Uo= Cc: Robert Rennison , "mpls@ietf.org" , Luca Martini , "mpls-tp@ietf.org" , Mishael Wexler , "lihan@chinamobile.com" , pwe3 , Rotem, HUANG, Feng F , Cohen Subject: Re: [PWE3] [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 07:07:36 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEA8BILPTMAIL02eci_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greg, and all, I concur with Greg. Using GAL with PWs is highly problematic, and all the related issues (raise= d during the poll on accepting this draft as a WG item) have not, AFAIK, be= en resolved. Regards, Sasha ________________________________ From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Greg= Mirsky [gregimirsky@gmail.com] Sent: Friday, February 18, 2011 8:47 AM To: Luca Martini Cc: mpls@ietf.org; mpls-tp@ietf.org; lihan@chinamobile.com; pwe3; HUANG Fen= g F Subject: [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Dear Authors and All, prior to the meeting in Bejing and acceptance of this proposal as WG docume= nt Luca and I agreed that use of GAL with PW VCCV presents a problem. I was not attending the IETF-79, nor I found discussion of this issue in th= e minutes. I think that this issue should be specified, explained. In my vi= ew, this document updates not only RFC 5586 but RFC 5085 too. Regards, Greg Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > wrote: Greg, You are correct , the proposed update does not propose any changes to VCCV. However the problem with vccv is not as simple as to ask for a new code poi= nt from IANA. Given the good amount of discussion on this point, we should probably have = a discussion in Beijing. Luca On 10/29/2010 05:07 PM, Greg Mirsky wrote: Dear Authors, I think that proposed update of the Section 4.2. RFC 5586 makes it possible to use GAL on MPLS-TP PW that uses Control Word. I consider it to be conflict between PW VCCV CC types because use of GAL is not negotiated through PW VCCV negotiation. To avoid such situation I propose: - in Section 5 request IANA to assign new CC Type "MPLS Generic Associated Channel Label" - assign precedence to new CC Type that affects Section 7 RFC 5085 Regards, Greg _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEA8BILPTMAIL02eci_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Greg, and all,
I concur with Greg.
Using GAL with PWs is highly problemati= c, and all the related issues (raised during the poll on accepting this dra= ft as a WG item) have not, AFAIK, been resolved.
 
Regards,
     Sasha
 
From: mpls-tp-bou= nces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky [gregimir= sky@gmail.com]
Sent: Friday, February 18, 2011 8:47 AM
To: Luca Martini
Cc: mpls@ietf.org; mpls-tp@ietf.org; lihan@chinamobile.com; pwe3; HU= ANG Feng F
Subject: [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

Dear Authors and All,
prior to the meeting in Bejing and acceptance of this proposal as WG docume= nt Luca and I agreed that use of GAL with PW VCCV presents a problem.
I was not attending the IETF-79, nor I found discussion of this issue in th= e minutes. I think that this issue should be specified, explained. In my vi= ew, this document updates not only RFC 5586
but RFC 5085 too.

Regards,
Greg

Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini <= span dir=3D"ltr"> <lmartini@cisco.com>= wrote:
Greg,

You are correct , the proposed update does not propose any changes to VCCV.=
However the problem with vccv is not as simple as to ask for a new code poi= nt from IANA.
Given the good amount of discussion on this point, we should probably have = a discussion in Beijing.

Luca



On 10/29/2010 05:07 PM, Greg Mirsky wrote: 
Dear Authors,
I think that proposed update of the Section 4.2. RFC 5586 makes it possible
to use GAL on MPLS-TP PW that uses Control Word. I consider it to be
conflict between PW VCCV CC types because use of GAL is not negotiated
through PW VCCV negotiation. To avoid such situation I propose:

   - in Section 5 request IANA to assign new CC Type "MPLS Generic
   Associated Channel Label"
   - assign precedence to new CC Type that affects Section 7 RFC 5085

Regards,
Greg



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


--_000_A3C5DF08D38B6049839A6F553B331C76D6FB8BEA8BILPTMAIL02eci_-- From neil.2.harrison@bt.com Fri Feb 18 01:17:28 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA853A6E81; Fri, 18 Feb 2011 01:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 eMwjF7K2DcqV; Fri, 18 Feb 2011 01:17:27 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by core3.amsl.com (Postfix) with ESMTP id B9C183A6E0C; Fri, 18 Feb 2011 01:17:26 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 18 Feb 2011 09:17:58 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.15]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Fri, 18 Feb 2011 09:17:58 +0000 From: To: , Date: Fri, 18 Feb 2011 09:17:54 +0000 Thread-Topic: [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Thread-Index: AcvPN6zTJGq/0XxDTGy6v16DWGU3fgAAocFMAAQ7z9A= Message-ID: <6D3D47CB84BDE349BC23BF1C94E316E440145CA70F@EMV62-UKRD.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_6D3D47CB84BDE349BC23BF1C94E316E440145CA70FEMV62UKRDdoma_" MIME-Version: 1.0 Cc: mpls@ietf.org, HUANG@core3.amsl.com, Rotem@core3.amsl.com, lmartini@cisco.com, mpls-tp@ietf.org, Mishael.Wexler@ecitele.com, lihan@chinamobile.com, pwe3@ietf.org, Feng.f.Huang@alcatel-sbell.com.cn, Robert.Rennison@ecitele.com, Rotem.Cohen@ecitele.com Subject: Re: [PWE3] [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 09:17:29 -0000 --_000_6D3D47CB84BDE349BC23BF1C94E316E440145CA70FEMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha/Greg, I would certainly agree that the use of the GAL with PWs is wrong....but th= e reason for that is simply that PWs per se violate the whole purpose of MP= LS-TP as a *transparent* transport network, noting that a true transport ne= twork must treat all client symbols equally...that is just a fact. However, given PWs are being carried forward into MPLS-TP then we also have= to deal with the issue that CP/MP of a transport network needs to logicall= y OOB wrt to the DP traffic. The GAL provides this function for the MPLS-T= P layer network itself (though it also gets this a wee bit wrong by asking = it to play a DP OAM role too,) but what about the PW layer network? MS PWs for sure are their own/different layer network....so they will need = their own access point addressing, OAM, routing, signalling, etc. I asked = some time ago why we were not using RSVP signalling here but T-LDP instead.= ..and I was told that RSVP cannot handle the PW signalling messages (nor th= e access addressing formats I assume...and we will of course need a new ins= tance of routing that will). So how is T-LDP being taken OOB wrt to the PW DP? regards, Neil Neil Harrison BT Design Tel: +44 (0) 1 803 812 545 Email: neil.2.harrison@bt.com Web: www.bt.com This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're not = the intended recipient, note that disclosing, copying, distributing or using this inform= ation is prohibited. If you've received this email in error, please let me know i= mmediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: 18 February 2011 07:05 To: Greg Mirsky Cc: Robert Rennison; mpls@ietf.org; Luca Martini; mpls-tp@ietf.org; Mishael= Wexler; lihan@chinamobile.com; pwe3; Rotem@core3.amsl.com; HUANG@core3.ams= l.com; Feng F; Cohen Subject: Re: [PWE3] [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Greg, and all, I concur with Greg. Using GAL with PWs is highly problematic, and all the related issues (raise= d during the poll on accepting this draft as a WG item) have not, AFAIK, be= en resolved. Regards, Sasha ________________________________ From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Greg= Mirsky [gregimirsky@gmail.com] Sent: Friday, February 18, 2011 8:47 AM To: Luca Martini Cc: mpls@ietf.org; mpls-tp@ietf.org; lihan@chinamobile.com; pwe3; HUANG Fen= g F Subject: [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Dear Authors and All, prior to the meeting in Bejing and acceptance of this proposal as WG docume= nt Luca and I agreed that use of GAL with PW VCCV presents a problem. I was not attending the IETF-79, nor I found discussion of this issue in th= e minutes. I think that this issue should be specified, explained. In my vi= ew, this document updates not only RFC 5586 but RFC 5085 too. Regards, Greg Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > wrote: Greg, You are correct , the proposed update does not propose any changes to VCCV. However the problem with vccv is not as simple as to ask for a new code poi= nt from IANA. Given the good amount of discussion on this point, we should probably have = a discussion in Beijing. Luca On 10/29/2010 05:07 PM, Greg Mirsky wrote: Dear Authors, I think that proposed update of the Section 4.2. RFC 5586 makes it possible to use GAL on MPLS-TP PW that uses Control Word. I consider it to be conflict between PW VCCV CC types because use of GAL is not negotiated through PW VCCV negotiation. To avoid such situation I propose: - in Section 5 request IANA to assign new CC Type "MPLS Generic Associated Channel Label" - assign precedence to new CC Type that affects Section 7 RFC 5085 Regards, Greg _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_6D3D47CB84BDE349BC23BF1C94E316E440145CA70FEMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sasha/Greg,

 

I would certainly agree that the use of the GAL wit= h PWs is wrong....but the reason for that is simply that PWs per se violate the w= hole purpose of MPLS-TP as a *transparent* transport network, noting that a true transport network must treat all client symbols equally...that is just a fact. 

 

However, given PWs are being carried forward into M= PLS-TP then we also have to deal with the issue that CP/MP of a transport network needs to logically OOB wrt to the DP traffic.  The GAL provides this function for the MPLS-TP layer network itself (though it also gets this a w= ee bit wrong by asking it to play a DP OAM role too,) but what about the PW la= yer network?

 

MS PWs for sure are their own/different layer network....so they will need their own access point addressing, OAM, routin= g, signalling, etc.  I asked some time ago why we were not using RSVP signalling here but T-LDP instead...and I was told that RSVP cannot handle = the PW signalling messages (nor the access addressing formats I assume...and we will of course need a new instance of routing that will).

 

So how is T-LDP being taken OOB wrt to the PW DP?

 

regards, Neil

 

Neil Harrison
BT Design

Tel: +44 (0) 1 803 812 545
Email: neil.2.harrison@bt.com
Web: www.bt.com

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not = the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.<= /p>

British Telecommunications p= lc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

 

 

 

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: 18 February 2011 07:05
To: Greg Mirsky
Cc: Robert Rennison; mpls@ietf.org; Luca Martini; mpls-tp@ietf.org; Mishael Wexler; lihan@chinamobile.com; pwe3; Rotem@core3.amsl.com; HUANG@core3.amsl.com; Feng F; Cohen
Subject: Re: [PWE3] [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

 

Greg, and all,<= /span>

I concur with Greg.

Using GAL with PWs is high= ly problematic, and all the related issues (raised during the poll on acceptin= g this draft as a WG item) have not, AFAIK, been resolved.<= /p>

 

Regards,=

     S= asha

 

From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsk= y [gregimirsky@gmail.com]
Sent: Friday, February 18, 2011 8:47 AM
To: Luca Martini
Cc: mpls@ietf.org; mpls-tp@ietf.org; lihan@chinamobile.com; pwe3; HU= ANG Feng F
Subject: [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

Dear Authors and All,
prior to the meeting in Bejing and acceptance of this proposal as WG docume= nt Luca and I agreed that use of GAL with PW VCCV presents a problem.
I was not attending the IETF-79, nor I found discussion of this issue in th= e minutes. I think that this issue should be specified, explained. In my view= , this document updates not only RFC 5586
but RFC 5085 too.

Regards,
Greg

Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

On Sat, Oct 30, 2010 at 10= :14 AM, Luca Martini <lmartini@cisco.com> wrote:

Greg,

You are correct , the proposed update does not propose any changes to VCCV.=
However the problem with vccv is not as simple as to ask for a new code poi= nt from IANA.
Given the good amount of discussion on this point, we should probably have = a discussion in Beijing.

Luca




On 10/29/2010 05:07 PM, Greg Mirsky wrote: 

Dear Authors,
= 
I think that proposed update of the Section 4.2. RFC =
5586 makes it possible
to use GAL on MPLS-TP PW that uses Control Word. I co=
nsider it to be
conflict between PW VCCV CC types because use of GAL =
is not negotiated
through PW VCCV negotiation. To avoid such situation =
I propose:
 
   - in Section 5 request IANA to assign new CC Type &q=
uot;MPLS Generic
   Associated Channel Label"
   - assign precedence to new CC Type that =
affects Section 7 RFC 5085
 
Regards,
Greg
 
 
_______________________________________________<=
/o:p>
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls=

 

 

--_000_6D3D47CB84BDE349BC23BF1C94E316E440145CA70FEMV62UKRDdoma_-- From lmartini@cisco.com Fri Feb 18 07:45:50 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20B93A6F0A; Fri, 18 Feb 2011 07:45:50 -0800 (PST) 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] 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 8nEUV7B-PuYx; Fri, 18 Feb 2011 07:45:49 -0800 (PST) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by core3.amsl.com (Postfix) with ESMTP id 96D6A3A6D47; Fri, 18 Feb 2011 07:45:49 -0800 (PST) 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 p1IFkAcH000113 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 18 Feb 2011 08:46:11 -0700 (MST) Message-ID: <4D5E9442.3030101@cisco.com> Date: Fri, 18 Feb 2011 08:46:10 -0700 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 ThunderBrowse/3.3.4 MIME-Version: 1.0 To: Greg Mirsky References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lihan@chinamobile.com, mpls@ietf.org, pwe3 , HUANG Feng F , mpls-tp@ietf.org Subject: Re: [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 15:45:50 -0000 Greg, Sorry, but I do not remember the point you mention. Can you explain again here ? Thanks. Luca On 02/17/11 23:47, Greg Mirsky wrote: > Dear Authors and All, > prior to the meeting in Bejing and acceptance of this proposal as WG > document Luca and I agreed that use of GAL with PW VCCV presents a > problem. > I was not attending the IETF-79, nor I found discussion of this issue > in the minutes. I think that this issue should be specified, > explained. In my view, this document updates not only RFC 5586 > but RFC 5085 too. > > Regards, > Greg > > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > wrote: > > Greg, > > You are correct , the proposed update does not propose any changes > to VCCV. > However the problem with vccv is not as simple as to ask for a new > code point from IANA. > Given the good amount of discussion on this point, we should > probably have a discussion in Beijing. > > Luca > > > > On 10/29/2010 05:07 PM, Greg Mirsky wrote: >> Dear Authors, >> I think that proposed update of the Section 4.2. RFC 5586 makes it possible >> to use GAL on MPLS-TP PW that uses Control Word. I consider it to be >> conflict between PW VCCV CC types because use of GAL is not negotiated >> through PW VCCV negotiation. To avoid such situation I propose: >> >> - in Section 5 request IANA to assign new CC Type "MPLS Generic >> Associated Channel Label" >> - assign precedence to new CC Type that affects Section 7 RFC 5085 >> >> Regards, >> Greg >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Fri Feb 18 09:15:40 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8AF83A6D56; Fri, 18 Feb 2011 09:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5] 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 yWTUe9upzuNI; Fri, 18 Feb 2011 09:15:39 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 56EE03A6CC7; Fri, 18 Feb 2011 09:15:39 -0800 (PST) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 18 Feb 2011 09:17:34 -0800 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Fri, 18 Feb 2011 09:15:37 -0800 From: "Shahram Davari" To: "'Alexander.Vainshtein@ecitele.com'" , "'gregimirsky@gmail.com'" Date: Fri, 18 Feb 2011 09:15:36 -0800 Thread-Topic: [PWE3] [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt Thread-Index: AcvPN6zTJGq/0XxDTGy6v16DWGU3fgAAocFMABVQVLE= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD69419A002F9@SJEXCHCCR02.corp.ad.broadcom.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: 614076275OK8247826-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD69419A002F9SJEXCHCCR02co_ Cc: "'mpls@ietf.org'" , "'HUANG@core3.amsl.com'" , "'Rotem@core3.amsl.com'" , "'lmartini@cisco.com'" , "'mpls-tp@ietf.org'" , "'Mishael.Wexler@ecitele.com'" , "'lihan@chinamobile.com'" , "'pwe3@ietf.org'" , "'Feng.f.Huang@alcatel-sbell.com.cn'" , "'Robert.Rennison@ecitele.com'" , "'Rotem.Cohen@ecitele.com'" Subject: Re: [PWE3] [mpls-tp] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 17:15:40 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD69419A002F9SJEXCHCCR02co_ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBhbHNvIGFncmVlIHdpdGggU2FzaGEuIENyZWF0aW5nIGEgVkNDViB0eXBlIDQgaXMgcHJvYmxl bWF0aWMsIGFsbW9zdCBubyBoYXJkd2FyZSBleGlzdCBmb3IgaXQgYW5kIGNhdXNlcyBpbnRlcndv cmtpbmcgaXNzdWVzLiBTaWduYWxpbmcgVkNDViBuZWVkcyB0byBjaGFuZ2UgYXMgd2VsbC4NCg0K VGh4DQpTaGFocmFtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBw d2UzLWJvdW5jZXNAaWV0Zi5vcmcgPHB3ZTMtYm91bmNlc0BpZXRmLm9yZz4NClRvOiBHcmVnIE1p cnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPg0KQ2M6IFJvYmVydCBSZW5uaXNvbiA8Um9iZXJ0 LlJlbm5pc29uQGVjaXRlbGUuY29tPjsgbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9yZz47IEx1 Y2EgTWFydGluaSA8bG1hcnRpbmlAY2lzY28uY29tPjsgbXBscy10cEBpZXRmLm9yZyA8bXBscy10 cEBpZXRmLm9yZz47IE1pc2hhZWwgV2V4bGVyIDxNaXNoYWVsLldleGxlckBlY2l0ZWxlLmNvbT47 IGxpaGFuQGNoaW5hbW9iaWxlLmNvbSA8bGloYW5AY2hpbmFtb2JpbGUuY29tPjsgcHdlMyA8cHdl M0BpZXRmLm9yZz47IFJvdGVtQGNvcmUzLmFtc2wuY29tIDxSb3RlbUBjb3JlMy5hbXNsLmNvbT47 IEhVQU5HQGNvcmUzLmFtc2wuY29tIDxIVUFOR0Bjb3JlMy5hbXNsLmNvbT47IEZlbmcgRiA8RmVu Zy5mLkh1YW5nQGFsY2F0ZWwtc2JlbGwuY29tLmNuPjsgQ29oZW4gPFJvdGVtLkNvaGVuQGVjaXRl bGUuY29tPg0KU2VudDogVGh1IEZlYiAxNyAyMzowNToxOSAyMDExDQpTdWJqZWN0OiBSZTogW1BX RTNdIFttcGxzLXRwXSBXRyBMQyBkcmFmdC1sbS1wd2UzLW1wbHMtdHAtZ2FsLWluLXB3LTAwLnR4 dA0KDQpHcmVnLCBhbmQgYWxsLA0KSSBjb25jdXIgd2l0aCBHcmVnLg0KVXNpbmcgR0FMIHdpdGgg UFdzIGlzIGhpZ2hseSBwcm9ibGVtYXRpYywgYW5kIGFsbCB0aGUgcmVsYXRlZCBpc3N1ZXMgKHJh aXNlZCBkdXJpbmcgdGhlIHBvbGwgb24gYWNjZXB0aW5nIHRoaXMgZHJhZnQgYXMgYSBXRyBpdGVt KSBoYXZlIG5vdCwgQUZBSUssIGJlZW4gcmVzb2x2ZWQuDQoNClJlZ2FyZHMsDQogICAgIFNhc2hh DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBtcGxzLXRwLWJvdW5j ZXNAaWV0Zi5vcmcgW21wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyZWcg TWlyc2t5IFtncmVnaW1pcnNreUBnbWFpbC5jb21dDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDE4 LCAyMDExIDg6NDcgQU0NClRvOiBMdWNhIE1hcnRpbmkNCkNjOiBtcGxzQGlldGYub3JnOyBtcGxz LXRwQGlldGYub3JnOyBsaWhhbkBjaGluYW1vYmlsZS5jb207IHB3ZTM7IEhVQU5HIEZlbmcgRg0K U3ViamVjdDogW21wbHMtdHBdIFdHIExDIGRyYWZ0LWxtLXB3ZTMtbXBscy10cC1nYWwtaW4tcHct MDAudHh0DQoNCkRlYXIgQXV0aG9ycyBhbmQgQWxsLA0KcHJpb3IgdG8gdGhlIG1lZXRpbmcgaW4g QmVqaW5nIGFuZCBhY2NlcHRhbmNlIG9mIHRoaXMgcHJvcG9zYWwgYXMgV0cgZG9jdW1lbnQgTHVj YSBhbmQgSSBhZ3JlZWQgdGhhdCB1c2Ugb2YgR0FMIHdpdGggUFcgVkNDViBwcmVzZW50cyBhIHBy b2JsZW0uDQpJIHdhcyBub3QgYXR0ZW5kaW5nIHRoZSBJRVRGLTc5LCBub3IgSSBmb3VuZCBkaXNj dXNzaW9uIG9mIHRoaXMgaXNzdWUgaW4gdGhlIG1pbnV0ZXMuIEkgdGhpbmsgdGhhdCB0aGlzIGlz c3VlIHNob3VsZCBiZSBzcGVjaWZpZWQsIGV4cGxhaW5lZC4gSW4gbXkgdmlldywgdGhpcyBkb2N1 bWVudCB1cGRhdGVzIG5vdCBvbmx5IFJGQyA1NTg2DQpidXQgUkZDIDUwODUgdG9vLg0KDQpSZWdh cmRzLA0KR3JlZw0KDQpDb21tZW50IHRvIGRyYWZ0LWxtLXB3ZTMtbXBscy10cC1nYWwtaW4tcHct MDAudHh0DQoNCk9uIFNhdCwgT2N0IDMwLCAyMDEwIGF0IDEwOjE0IEFNLCBMdWNhIE1hcnRpbmkg PGxtYXJ0aW5pQGNpc2NvLmNvbTxtYWlsdG86bG1hcnRpbmlAY2lzY28uY29tPj4gd3JvdGU6DQpH cmVnLA0KDQpZb3UgYXJlIGNvcnJlY3QgLCB0aGUgcHJvcG9zZWQgdXBkYXRlIGRvZXMgbm90IHBy b3Bvc2UgYW55IGNoYW5nZXMgdG8gVkNDVi4NCkhvd2V2ZXIgdGhlIHByb2JsZW0gd2l0aCB2Y2N2 IGlzIG5vdCBhcyBzaW1wbGUgYXMgdG8gYXNrIGZvciBhIG5ldyBjb2RlIHBvaW50IGZyb20gSUFO QS4NCkdpdmVuIHRoZSBnb29kIGFtb3VudCBvZiBkaXNjdXNzaW9uIG9uIHRoaXMgcG9pbnQsIHdl IHNob3VsZCBwcm9iYWJseSBoYXZlIGEgZGlzY3Vzc2lvbiBpbiBCZWlqaW5nLg0KDQpMdWNhDQoN Cg0KDQpPbiAxMC8yOS8yMDEwIDA1OjA3IFBNLCBHcmVnIE1pcnNreSB3cm90ZToNCg0KRGVhciBB dXRob3JzLA0KSSB0aGluayB0aGF0IHByb3Bvc2VkIHVwZGF0ZSBvZiB0aGUgU2VjdGlvbiA0LjIu IFJGQyA1NTg2IG1ha2VzIGl0IHBvc3NpYmxlDQp0byB1c2UgR0FMIG9uIE1QTFMtVFAgUFcgdGhh dCB1c2VzIENvbnRyb2wgV29yZC4gSSBjb25zaWRlciBpdCB0byBiZQ0KY29uZmxpY3QgYmV0d2Vl biBQVyBWQ0NWIENDIHR5cGVzIGJlY2F1c2UgdXNlIG9mIEdBTCBpcyBub3QgbmVnb3RpYXRlZA0K dGhyb3VnaCBQVyBWQ0NWIG5lZ290aWF0aW9uLiBUbyBhdm9pZCBzdWNoIHNpdHVhdGlvbiBJIHBy b3Bvc2U6DQoNCiAgIC0gaW4gU2VjdGlvbiA1IHJlcXVlc3QgSUFOQSB0byBhc3NpZ24gbmV3IEND IFR5cGUgIk1QTFMgR2VuZXJpYw0KICAgQXNzb2NpYXRlZCBDaGFubmVsIExhYmVsIg0KICAgLSBh c3NpZ24gcHJlY2VkZW5jZSB0byBuZXcgQ0MgVHlwZSB0aGF0IGFmZmVjdHMgU2VjdGlvbiA3IFJG QyA1MDg1DQoNClJlZ2FyZHMsDQpHcmVnDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9y ZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KDQoNCg0K --_000_2C2F1EBA8050E74EA81502D5740B4BD69419A002F9SJEXCHCCR02co_ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBj b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+DQo8bWV0YSBjb250ZW50PSJN U0hUTUwgNi4wMC42MDAwLjE3MDYzIiBuYW1lPSJHRU5FUkFUT1IiPg0KPHN0eWxlIGlkPSJvd2FU ZW1wRWRpdFN0eWxlIj48L3N0eWxlPjxzdHlsZSB0aXRsZT0ib3dhUGFyYVN0eWxlIj48IS0tUCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBvY3NpPSJ4Ij48ZGl2Pjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9 QXJpYWw+DQpJIGFsc28gYWdyZWUgd2l0aCBTYXNoYS4gQ3JlYXRpbmcgYSBWQ0NWIHR5cGUgNCBp cyBwcm9ibGVtYXRpYywgYWxtb3N0IG5vIGhhcmR3YXJlIGV4aXN0IGZvciBpdCBhbmQgY2F1c2Vz IGludGVyd29ya2luZyBpc3N1ZXMuIFNpZ25hbGluZyBWQ0NWIG5lZWRzIHRvIGNoYW5nZSBhcyB3 ZWxsLjxicj48YnI+VGh4PGJyPlNoYWhyYW0gPC9mb250PjwvZGl2Pg0KPGJyPjxkaXY+PGhyIHNp emU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0KPGZvbnQgZmFjZT1U YWhvbWEgc2l6ZT0yPg0KPGI+RnJvbTwvYj46IHB3ZTMtYm91bmNlc0BpZXRmLm9yZyAmbHQ7cHdl My1ib3VuY2VzQGlldGYub3JnJmd0Ow08YnI+PGI+VG88L2I+OiBHcmVnIE1pcnNreSAmbHQ7Z3Jl Z2ltaXJza3lAZ21haWwuY29tJmd0Ow08YnI+PGI+Q2M8L2I+OiBSb2JlcnQgUmVubmlzb24gJmx0 O1JvYmVydC5SZW5uaXNvbkBlY2l0ZWxlLmNvbSZndDs7IG1wbHNAaWV0Zi5vcmcgJmx0O21wbHNA aWV0Zi5vcmcmZ3Q7OyBMdWNhIE1hcnRpbmkgJmx0O2xtYXJ0aW5pQGNpc2NvLmNvbSZndDs7IG1w bHMtdHBAaWV0Zi5vcmcgJmx0O21wbHMtdHBAaWV0Zi5vcmcmZ3Q7OyBNaXNoYWVsIFdleGxlciAm bHQ7TWlzaGFlbC5XZXhsZXJAZWNpdGVsZS5jb20mZ3Q7OyBsaWhhbkBjaGluYW1vYmlsZS5jb20g Jmx0O2xpaGFuQGNoaW5hbW9iaWxlLmNvbSZndDs7IHB3ZTMgJmx0O3B3ZTNAaWV0Zi5vcmcmZ3Q7 OyBSb3RlbUBjb3JlMy5hbXNsLmNvbSAmbHQ7Um90ZW1AY29yZTMuYW1zbC5jb20mZ3Q7OyBIVUFO R0Bjb3JlMy5hbXNsLmNvbSAmbHQ7SFVBTkdAY29yZTMuYW1zbC5jb20mZ3Q7OyBGZW5nIEYgJmx0 O0ZlbmcuZi5IdWFuZ0BhbGNhdGVsLXNiZWxsLmNvbS5jbiZndDs7IENvaGVuICZsdDtSb3RlbS5D b2hlbkBlY2l0ZWxlLmNvbSZndDsNPGJyPjxiPlNlbnQ8L2I+OiBUaHUgRmViIDE3IDIzOjA1OjE5 IDIwMTE8YnI+PGI+U3ViamVjdDwvYj46IFJlOiBbUFdFM10gW21wbHMtdHBdIFdHIExDIGRyYWZ0 LWxtLXB3ZTMtbXBscy10cC1nYWwtaW4tcHctMDAudHh0DTxicj48L2ZvbnQ+PGJyPjwvZGl2Pg0K DQo8ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDE2cHg7IENPTE9SOiAjMDAwMDAwOyBESVJFQ1RJT046 IGx0cjsgRk9OVC1GQU1JTFk6IFRpbWVzIE5ldyBSb21hbiI+DQo8ZGl2PkdyZWcsIGFuZCBhbGws PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9InRpbWVzIG5ldyByb21hbiI+SSBjb25jdXIgd2l0aCBH cmVnLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0idGltZXMgbmV3IHJvbWFuIj5Vc2lu ZyBHQUwgd2l0aCBQV3MgaXMgaGlnaGx5IHByb2JsZW1hdGljLCBhbmQgYWxsIHRoZSByZWxhdGVk IGlzc3VlcyAocmFpc2VkIGR1cmluZyB0aGUgcG9sbCBvbiBhY2NlcHRpbmcgdGhpcyBkcmFmdCBh cyBhIFdHIGl0ZW0pIGhhdmUgbm90LCBBRkFJSywgYmVlbiByZXNvbHZlZC48L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9InRpbWVzIG5ldyByb21hbiI+PC9mb250PiZuYnNwOzwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJ0aW1lcyBuZXcgcm9tYW4iPlJlZ2FyZHMsPC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJ0aW1lcyBuZXcgcm9tYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBTYXNoYTwvZm9udD48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxmb250IGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgY29sb3I9IiMwMDAwMDAiIHNpemU9IjMiPjwvZm9udD4mbmJzcDs8L2Rpdj4NCjxk aXYgaWQ9ImRpdlJwRjYyODA5NSIgc3R5bGU9IkRJUkVDVElPTjogbHRyIj4NCjxociB0YWJpbmRl eD0iLTEiPg0KPGZvbnQgZmFjZT0iVGFob21hIiBjb2xvcj0iIzAwMDAwMCIgc2l6ZT0iMiI+PGI+ RnJvbTo8L2I+IG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZyBbbXBscy10cC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgR3JlZyBNaXJza3kgW2dyZWdpbWlyc2t5QGdtYWlsLmNvbV08YnI+ DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAxOCwgMjAxMSA4OjQ3IEFNPGJyPg0KPGI+ VG86PC9iPiBMdWNhIE1hcnRpbmk8YnI+DQo8Yj5DYzo8L2I+IG1wbHNAaWV0Zi5vcmc7IG1wbHMt dHBAaWV0Zi5vcmc7IGxpaGFuQGNoaW5hbW9iaWxlLmNvbTsgcHdlMzsgSFVBTkcgRmVuZyBGPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFttcGxzLXRwXSBXRyBMQyBkcmFmdC1sbS1wd2UzLW1wbHMtdHAt Z2FsLWluLXB3LTAwLnR4dDxicj4NCjwvZm9udD48YnI+DQo8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8 ZGl2PkRlYXIgQXV0aG9ycyBhbmQgQWxsLDxicj4NCnByaW9yIHRvIHRoZSBtZWV0aW5nIGluIEJl amluZyBhbmQgYWNjZXB0YW5jZSBvZiB0aGlzIHByb3Bvc2FsIGFzIFdHIGRvY3VtZW50IEx1Y2Eg YW5kIEkgYWdyZWVkIHRoYXQgdXNlIG9mIEdBTCB3aXRoIFBXIFZDQ1YgcHJlc2VudHMgYSBwcm9i bGVtLjxicj4NCkkgd2FzIG5vdCBhdHRlbmRpbmcgdGhlIElFVEYtNzksIG5vciBJIGZvdW5kIGRp c2N1c3Npb24gb2YgdGhpcyBpc3N1ZSBpbiB0aGUgbWludXRlcy4gSSB0aGluayB0aGF0IHRoaXMg aXNzdWUgc2hvdWxkIGJlIHNwZWNpZmllZCwgZXhwbGFpbmVkLiBJbiBteSB2aWV3LCB0aGlzIGRv Y3VtZW50IHVwZGF0ZXMgbm90IG9ubHkgUkZDIDU1ODY8YnI+DQpidXQgUkZDIDUwODUgdG9vLjxi cj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KR3JlZzxicj4NCjxicj4NCkNvbW1lbnQgdG8gZHJhZnQt bG0tcHdlMy1tcGxzLXRwLWdhbC1pbi1wdy0wMC50eHQ8YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+T24gU2F0LCBPY3QgMzAsIDIwMTAgYXQgMTA6MTQgQU0sIEx1Y2EgTWFydGlu aSA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmxtYXJ0aW5pQGNpc2NvLmNv bSI+bG1hcnRpbmlAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9IlBBRERJTkctTEVGVDogMWV4OyBNQVJHSU46 IDBwdCAwcHQgMHB0IDAuOGV4OyBCT1JERVItTEVGVDogcmdiKDIwNCwyMDQsMjA0KSAxcHggc29s aWQiPg0KPGRpdiBiZ2NvbG9yPSIjZmZmZmZmIj5HcmVnLDxicj4NCjxicj4NCllvdSBhcmUgY29y cmVjdCAsIHRoZSBwcm9wb3NlZCB1cGRhdGUgZG9lcyBub3QgcHJvcG9zZSBhbnkgY2hhbmdlcyB0 byBWQ0NWLjxicj4NCkhvd2V2ZXIgdGhlIHByb2JsZW0gd2l0aCB2Y2N2IGlzIG5vdCBhcyBzaW1w bGUgYXMgdG8gYXNrIGZvciBhIG5ldyBjb2RlIHBvaW50IGZyb20gSUFOQS48YnI+DQpHaXZlbiB0 aGUgZ29vZCBhbW91bnQgb2YgZGlzY3Vzc2lvbiBvbiB0aGlzIHBvaW50LCB3ZSBzaG91bGQgcHJv YmFibHkgaGF2ZSBhIGRpc2N1c3Npb24gaW4gQmVpamluZy48YnI+DQo8YnI+DQpMdWNhDQo8ZGl2 Pg0KPGRpdj48L2Rpdj4NCjxkaXYgY2xhc3M9Img1Ij48YnI+DQo8YnI+DQo8YnI+DQpPbiAxMC8y OS8yMDEwIDA1OjA3IFBNLCBHcmVnIE1pcnNreSB3cm90ZTogPC9kaXY+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2IGNsYXNzPSJoNSI+ DQo8cHJlPkRlYXIgQXV0aG9ycywNCkkgdGhpbmsgdGhhdCBwcm9wb3NlZCB1cGRhdGUgb2YgdGhl IFNlY3Rpb24gNC4yLiBSRkMgNTU4NiBtYWtlcyBpdCBwb3NzaWJsZQ0KdG8gdXNlIEdBTCBvbiBN UExTLVRQIFBXIHRoYXQgdXNlcyBDb250cm9sIFdvcmQuIEkgY29uc2lkZXIgaXQgdG8gYmUNCmNv bmZsaWN0IGJldHdlZW4gUFcgVkNDViBDQyB0eXBlcyBiZWNhdXNlIHVzZSBvZiBHQUwgaXMgbm90 IG5lZ290aWF0ZWQNCnRocm91Z2ggUFcgVkNDViBuZWdvdGlhdGlvbi4gVG8gYXZvaWQgc3VjaCBz aXR1YXRpb24gSSBwcm9wb3NlOg0KDQogICAtIGluIFNlY3Rpb24gNSByZXF1ZXN0IElBTkEgdG8g YXNzaWduIG5ldyBDQyBUeXBlICZxdW90O01QTFMgR2VuZXJpYw0KICAgQXNzb2NpYXRlZCBDaGFu bmVsIExhYmVsJnF1b3Q7DQogICAtIGFzc2lnbiBwcmVjZWRlbmNlIHRvIG5ldyBDQyBUeXBlIHRo YXQgYWZmZWN0cyBTZWN0aW9uIDcgUkZDIDUwODUNCg0KUmVnYXJkcywNCkdyZWcNCg0KPC9wcmU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZT48ZmllbGRzZXQ+PC9maWVsZHNldD4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0K PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L2E+DQo8L3By ZT4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2C2F1EBA8050E74EA81502D5740B4BD69419A002F9SJEXCHCCR02co_-- From gregimirsky@gmail.com Fri Feb 18 10:14:55 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 247FB3A6D6A; Fri, 18 Feb 2011 10:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 Jk3U5VHbczmr; Fri, 18 Feb 2011 10:14:54 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 9D8E33A6D48; Fri, 18 Feb 2011 10:14:53 -0800 (PST) Received: by vxi40 with SMTP id 40so2334276vxi.31 for ; Fri, 18 Feb 2011 10:15:27 -0800 (PST) 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 :message-id:subject:from:to:cc:content-type; bh=eFhbxbVkVd9RRDxruN1eHxWuzfkY9LqBZ17udURWnxI=; b=Eyw3njNi9WkoxdXq6rv6DfBqfhylFf3/LoS1KEOtAqtvDV3cdcJgDr78E5VlUpM2P1 Ylbd7TKcDv9u49VmyNRq3zkMppKwXJMvuDcdzEdE5foR04unDz+8uOzPCgWTGZAS0Hqq 1Km/WT6PytuY2a1FiaKrBTZrp2ugj2QmeOniM= 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; b=C8KfCMqjLbrj7/7LT+ldM0AolurQ3cZ8lRDVT08f8H962E9+r3oXco5QaMOeU+QzDr HMsTbIy+Nw/96Lz8lElBzultAuw9qltnHYe8oyzo+N31KBtGH4+OT6cKJl2lBPgrReMK FMZdb8V/POafL1EFBx6cwms/89yqOSaVHgecI= MIME-Version: 1.0 Received: by 10.52.164.166 with SMTP id yr6mr1831510vdb.245.1298052926692; Fri, 18 Feb 2011 10:15:26 -0800 (PST) Received: by 10.52.165.9 with HTTP; Fri, 18 Feb 2011 10:15:26 -0800 (PST) In-Reply-To: <4D5E9442.3030101@cisco.com> References: <4D5E9442.3030101@cisco.com> Date: Fri, 18 Feb 2011 10:15:26 -0800 Message-ID: From: Greg Mirsky To: Luca Martini Content-Type: multipart/alternative; boundary=bcaec53f9359985e7f049c927f19 Cc: lihan@chinamobile.com, mpls@ietf.org, pwe3 , HUANG Feng F , mpls-tp@ietf.org Subject: Re: [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 18:14:55 -0000 --bcaec53f9359985e7f049c927f19 Content-Type: text/plain; charset=ISO-8859-1 Dear Luca, I see at least two issues: - use of GAL for PW, in my view, is another VCCV CC type that has to be negotiated as described in RFC 5085. - use of GAL creates ambiguous situation when PW CW is used. The benefit from extending GAL in PW, as I see, is for PWs that are not required to use PW CW. That might be a good enough reason to update RFC 5586 as proposed in the document but we must address use cases of GAL in PWs that require presence PW CW. If we prohibit or even discourage use of GAL for these PWs that have PW VCCV as native Associated Channel, then architecture of ACh for MPLS-TP PW not simplified as result of adopting the proposal. Regards, Greg On Fri, Feb 18, 2011 at 7:46 AM, Luca Martini wrote: > Greg, > > Sorry, but I do not remember the point you mention. > Can you explain again here ? > Thanks. > Luca > > > On 02/17/11 23:47, Greg Mirsky wrote: > > Dear Authors and All, > > prior to the meeting in Bejing and acceptance of this proposal as WG > > document Luca and I agreed that use of GAL with PW VCCV presents a > > problem. > > I was not attending the IETF-79, nor I found discussion of this issue > > in the minutes. I think that this issue should be specified, > > explained. In my view, this document updates not only RFC 5586 > > but RFC 5085 too. > > > > Regards, > > Greg > > > > Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt > > > > On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini > > wrote: > > > > Greg, > > > > You are correct , the proposed update does not propose any changes > > to VCCV. > > However the problem with vccv is not as simple as to ask for a new > > code point from IANA. > > Given the good amount of discussion on this point, we should > > probably have a discussion in Beijing. > > > > Luca > > > > > > > > On 10/29/2010 05:07 PM, Greg Mirsky wrote: > >> Dear Authors, > >> I think that proposed update of the Section 4.2. RFC 5586 makes it > possible > >> to use GAL on MPLS-TP PW that uses Control Word. I consider it to be > >> conflict between PW VCCV CC types because use of GAL is not > negotiated > >> through PW VCCV negotiation. To avoid such situation I propose: > >> > >> - in Section 5 request IANA to assign new CC Type "MPLS Generic > >> Associated Channel Label" > >> - assign precedence to new CC Type that affects Section 7 RFC > 5085 > >> > >> Regards, > >> Greg > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > --bcaec53f9359985e7f049c927f19 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Luca,
I see at least two issues:
  • use of GAL for PW, in m= y view, is another VCCV CC type that has to be negotiated as described in R= FC 5085.
  • use of GAL creates ambiguous situation when PW CW is used.= The benefit from extending GAL in PW, as I see, is for PWs that are not re= quired to use PW CW. That might be a good enough reason to update RFC 5586 = as proposed in the document but we must address use cases of GAL in PWs tha= t require presence PW CW. If we prohibit or even discourage use of GAL for = these PWs that have PW VCCV as native Associated Channel, then architecture= of ACh for MPLS-TP PW not simplified as result of adopting the proposal.
Regards,
Greg

On Fri, Feb 18, 201= 1 at 7:46 AM, Luca Martini <lmartini@cisco.com> wrote:
Greg,

Sorry, but I do not remember the point you mention.
Can you explain again here ?
Thanks.
Luca


On 02/17/11 23:47, Greg Mirsky wrote:
> Dear Authors and All,
> prior to the meeting in Bejing and acceptance of this proposal as WG > document Luca and I agreed that use of GAL with PW VCCV presents a
> problem.
> I was not attending the IETF-79, nor I found discussion of this issue<= br> > in the minutes. I think that this issue should be specified,
> explained. In my view, this document updates not only RFC 5586
> but RFC 5085 too.
>
> Regards,
> Greg
>
> Comment to draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt
>
> On Sat, Oct 30, 2010 at 10:14 AM, Luca Martini <lmartini@cisco.com
> <mailto:lmartini@cisco.com>> wrote:
>
> =A0 =A0 Greg,
>
> =A0 =A0 You are correct , the proposed update does not propose any cha= nges
> =A0 =A0 to VCCV.
> =A0 =A0 However the problem with vccv is not as simple as to ask for a= new
> =A0 =A0 code point from IANA.
> =A0 =A0 Given the good amount of discussion on this point, we should > =A0 =A0 probably have a discussion in Beijing.
>
> =A0 =A0 Luca
>
>
>
> =A0 =A0 On 10/29/2010 05:07 PM, Greg Mirsky wrote:
>> =A0 =A0 Dear Authors,
>> =A0 =A0 I think that proposed update of the Section 4.2. RFC 5586 = makes it possible
>> =A0 =A0 to use GAL on MPLS-TP PW that uses Control Word. I conside= r it to be
>> =A0 =A0 conflict between PW VCCV CC types because use of GAL is no= t negotiated
>> =A0 =A0 through PW VCCV negotiation. To avoid such situation I pro= pose:
>>
>> =A0 =A0 =A0 =A0- in Section 5 request IANA to assign new CC Type &= quot;MPLS Generic
>> =A0 =A0 =A0 =A0Associated Channel Label"
>> =A0 =A0 =A0 =A0- assign precedence to new CC Type that affects Sec= tion 7 RFC 5085
>>
>> =A0 =A0 Regards,
>> =A0 =A0 Greg
>>
>>
>>
>> =A0 =A0 _______________________________________________
>> =A0 =A0 mpls mailing list
>> =A0 =A0 mpls@ietf.org &= lt;mailto:mpls@ietf.org>
>> =A0 =A0 https://www.ietf.org/mailm= an/listinfo/mpls
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls


--bcaec53f9359985e7f049c927f19-- From yaakov_s@rad.com Sun Feb 20 06:24:10 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA5F3A6CCA; Sun, 20 Feb 2011 06:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.007 X-Spam-Level: X-Spam-Status: No, score=-101.007 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_TOWRITE=1.05, 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 mtHIk-STbAI2; Sun, 20 Feb 2011 06:23:59 -0800 (PST) Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id 52C013A6D69; Sun, 20 Feb 2011 06:23:55 -0800 (PST) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir1.rad.co.il with ESMTP; 20 Feb 2011 16:24:04 +0200 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.218.12; Sun, 20 Feb 2011 16:23:33 +0200 Received: from EXRAD5.ad.rad.co.il ([fe80::ec3e:feb5:8bef:e3ba]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%16]) with mapi id 14.01.0270.001; Sun, 20 Feb 2011 16:22:39 +0200 From: Yaakov Stein To: "rtg-ads@tools.ietf.org" , "draft-ietf-pwer-fc-encap-14.all@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-pwer-fc-encap-14.txt Thread-Index: AQHL0QnAgbrWgjrJ7EGVdx4tUkTaHQ== Date: Sun, 20 Feb 2011 14:23:32 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903D0D7F1@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC903D0BA3F@EXRAD5.ad.rad.co.il> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {DCC56578-D1B0-4F0D-8B6E-A3ECD46923F5} x-cr-hashedpuzzle: Css= I7If MMLn R2mq T9Gi UEnN Ux9F VkSD WBo1 XFAh coYL dfcg lCdR l9G8 z3cx 0aHM; 5; YQBsAGUAeABhAG4AZABlAHIALgB2AGEAaQBuAHMAaAB0AGUAaQBuAEAAZQBjAGkAdABlAGwAZQAuAGMAbwBtADsAZAByAGEAZgB0AC0AaQBlAHQAZgAtAHAAdwBlAHIALQBmAGMALQBlAG4AYwBhAHAALQAxADQALgBhAGwAbABAAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIAZwA7AHAAdwBlADMAQABpAGUAdABmAC4AbwByAGcAOwByAHQAZwAtAGEAZABzAEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnADsAcgB0AGcALQBkAGkAcgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {DCC56578-D1B0-4F0D-8B6E-A3ECD46923F5}; eQBhAGEAawBvAHYAXwBzAEAAcgBhAGQALgBjAG8AbQA=; Sun, 20 Feb 2011 14:23:22 GMT; UgB0AGcARABpAHIAIAByAGUAdgBpAGUAdwA6ACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAHAAdwBlAHIALQBmAGMALQBlAG4AYwBhAHAALQAxADQALgB0AHgAdAA= x-originating-ip: [172.17.170.37] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC903D0D7F1EXRAD5adradcoil_" MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "pwe3@ietf.org" Subject: [PWE3] RtgDir review: draft-ietf-pwer-fc-encap-14.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 14:24:10 -0000 --_000_07F7D7DED63154409F13298786A2ADC903D0D7F1EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To: * rtg-ads@tools.ietf.org * draft-ietf-pwer-fc-encap-14.all@tools.ietf.org Cc: * rtg-dir@ietf.org * pwe3@ietf.org Subject: * RtgDir review: draft-ietf-pwer-fc-encap-14.txt Hello, We (Yaakov and Sasha) have been selected as the Routing Directorate reviewe= rs for this draft. The Routing Directorate seeks to review all routing or r= outing-related drafts as they pass through IETF last call and IESG review. = The purpose of the review is to provide assistance to the Routing ADs. For = more information about the Routing Directorate, please see http://www.ietf.= org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-pwer-fc-encap-14.txt Reviewers: Alexander ("Sasha") Vainshtein and Yaakov (Jonathan) Stein Review Date: 2011/02/20 IETF LC End Date: Intended Status: Standard Track Summary: We have some concerns about this document that we believe need to be addres= sed before publication. Comments: 1. The two of us (Sasha and Yaakov) have decided to write a single joint= review, in order to reduce contradictory recommendations. 2. In order to further reduce turnaround time, we have taken the slightl= y unorthodox approach of holding direct talks with one of the draft editors= (David Black). As will be seen in the following, this approach has proven = to be highly productive. 3. The draft includes multiple references to Fibre Channel (FC) standard= s, which hinder comprehension for those not expert in the technology. The s= tatus of these references is also somewhat problematic: * [FC-BB-6] (Normative) triggers circular normative referencing betw= een IETF and T11: * It is currently a T11 working document waiting for approval. * It can only be accessed by the interested IETF participants by sen= ding a direct request to David Black, who is both co-editor of this draft a= nd T11's official liaison to the IETF. * It uses this draft as a Normative reference and hence will be appr= oved by T11 only after an RFC number has been assigned to this draft. * As this is not intended to be a downref, the responsible AD will n= eed to explain the situation to the RFC Editor once the draft is approved f= or publication. * [FC-FS-2] (Normative) is an approved T11 standard that can be acce= ssed by interested IETF participants by sending a request to David Black (d= avid.black@emc.com) in his official capacity as= T11 liaison to IETF. * [FC-SP] is listed as a Normative reference. However, it describes= the FC Security Protocol that is, according to the draft, transparent to = the FC PW. Hence it makes sense to redefine it as an Informational referenc= e. * All these references are flagged as warnings by the latest IETF ni= ts tool. 4. We would like to thank the authors for resolving in version 14 many i= ssues that we had raised in the past regarding the K-codes, timing constrai= nts, and specifically the operation of the NSP. Major Issues: 1. The draft refers in several places to the "reliable transport... prov= ided by MPLS-TE/MPLS-TP". This terminology is inappropriate in the IETF whe= re "reliable" is used in a completely different sense, especially as the dr= aft compares the FC PW to transport of FC over TCP/IP that has been defined= in RFC 3821. The problem is aggravated by the fact that the common PWE3 t= echnique that allows detection of lost and/or reordered PW packets (sequenc= ing) is intentionally disabled (in Section 3.1 the draft states that the se= quence number MUST be set to 0 by the sender and MUST be ignored by the rec= eiver). We have discussed this point with the one of the draft editors and = obtained agreement that the usage of the term "reliable" in this context is= inappropriate. We highly recommend that the authors modify the present tex= t by replacing the term "reliable" with the actual expectations regarding d= elivery of the FC PW packets (low drop rate, low chance of reordering). We = also suggest adding text on the handling of lost, re-ordered and duplicate = FC PW packets to the Applicability section. 2. The draft proposes usage of "sub-rating" of FC Primitive Sequences, w= ithout specifying acceptable sub-rating factors and without explaining whet= her these values require coordination between the two PEs. One of the docum= ent editors has assured us that coordination is not required, but that ther= e are limitations on sub-rating in order to avoid timeouts. We strongly sug= gest that the authors add some text explaining this, providing guidance reg= arding suitable sub-rating values. 3. The draft requests IANA to reserve four Interface Parameter sub-TLV v= alues for functionality that has been dropped from the draft after having b= een rejected by the PWE3 WG, in order to accommodate the possibility of thi= s functionality being reintroduced at some future time. This request would = be justified if there were multiple deployed pre-standard implementations s= upporting this functionality (as was the case for the "Martini mode" of the= Frame Relay PWs). As far as we know, there is at most only one such pre-st= andard implementation. We suggest that the responsible AD decide on the pro= per course of action. Minor Issues: 1. In contrast to the rest of the PWE3 documents, a dedicated Native Ser= vice Processor (NSP) block is mandatory for implementing (and even understa= nding) the draft. We would like to thank the authors for the much improved = explanation of this NSP in the present version. However, some of the functi= onality of the NSP operation is similar to functions that are not considere= d NSP functions in other PWE3 encapsulation documents e.g.: * Suppression of idle codes (in contrast, suppression of idle ATM ce= lls is not considered as an NSP function in RFC 4717) * Removal of 8b/10b encoding (in contrast, the same operation is not= considered as an NSP function in RFC 4448). We believe that a note should be added clarifying this point. 2. The draft refers to MTU issues associated with the FC PW, but does no= t state whether the MTU interface parameter sub-TLV MUST, SHOULD, MAY, ...,= or MUST NOT be included in the Label Mapping message during the FC PW setu= p. Since all FC interfaces have the same MTU, this parameter is not really = needed during the setup. We suggest that the authors explicitly indicate th= at the Interface MTU parameter MUST NOT appear in the FC PW setup protocol = exchange. (Aside: This is based on experience with RFC 5287 where the fact = that it was not specified that the Interface MTU parameter MUST NOT appear = in the TDM PW setup eventually led to interoperability issues). We have sen= t the authors proposed text to deal with this issue. 3. The draft defines that the CRC of the FC frames MUST always be includ= ed in the PW encapsulation. However, its handling differs from the handling= of FCS per RFC 4720; in particular, FC frames received with CRC errors mus= t be transmitted over the PW. It would be nice to explicitly note this diff= erence, and for the signaling procedure to explicitly specify non-usage of = the FCS Retention Indicator Interface Parameter sub-TLV. We have sent the a= uthors proposed text to deal with this issue. Regards, Y(J)S and Sasha --_000_07F7D7DED63154409F13298786A2ADC903D0D7F1EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To:

·&nbs= p;       <= a href=3D"mailto:rtg-ads@tools.ietf.org">rtg-ads@tools.ietf.org

Cc:

·&nbs= p;       <= a href=3D"mailto:rtg-dir@ietf.org">rtg-dir@ietf.org

Subject= :

·&nbs= p;       R= tgDir review: draft-ietf-pwer-fc-encap-14.txt

 

Hello,

We (Yaakov and Sasha) have been selected a= s the Routing Directorate reviewers for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they = pass through IETF last call and IESG review. The purpose of the review is t= o provide assistance to the Routing ADs. For more information about the Rou= ting Directorate, please see http://www.ie= tf.org/iesg/directorate/routing.html

Although these comments are primarily for = the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receiv= e, and strive to resolve them through discussion or by updating the draft.<= o:p>

Document: draft-ietf-pwer-fc-encap-14.txt
Reviewers: Alexander (“Sasha”) Vainshtein and Yaakov (Jonathan)= Stein
Review Date:  2011/02/20
IETF LC End Date:
Intended Status: Standard Track

 

Summary:

We have some concerns about this document that we believe need= to be addressed before publication.

Comments:

  1. The two of us (Sasha and Yaakov) have decided to write a single= joint review, in order to reduce contradictory recommendations.=
  2. In order to further reduce turnaround time, we have taken the s= lightly unorthodox approach of holding direct talks with one of the draft e= ditors (David Black). As will be seen in the following, this approach has proven to be highly productive.
    3. <= li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto; mso-list:l3 level1 lfo4"> The draft includes multiple references to Fibre Channel (FC) st= andards, which hinder comprehension for those not expert in the technology.= The status of these references is also somewhat problematic:
    • [FC-BB-6] (Normative) triggers circular normative referencing between IETF and T11:

·&nbs= p;       I= t is currently a T11 working document waiting for approval.

·&nbs= p;       I= t can only be accessed by the interested IETF participants by sending a dir= ect request to David Black, who is both co-editor of this draft and T11's official liaison to the IETF.

·&nbs= p;       I= t uses this draft as a Normative reference and hence will be approved by T1= 1 only after an RFC number has been assigned to this draft.

·&nbs= p;       As this is no= t intended to be a downref, the responsible AD will need to explain the situation to the RFC Editor once the draft is approve= d for publication.

    • [FC-FS-2] (No= rmative) is an approved T11 standard that can be accessed by interested IET= F participants by sending a request to David Black (david.black@emc.com) in his official capacity a= s T11 liaison to IETF.
    • [FC-SP]  is listed a= s a Normative reference. However, it describes the FC  Security Protoc= ol that is, according to the draft, transparent to the FC PW. Hence it make= s sense to redefine it as an Informational reference.
    • All these references are = flagged as warnings by the latest IETF nits tool.

= 4.    We would like= to thank the authors for resolving in version 14 many issues that we had r= aised in the past regarding the K-codes, timing constraints, and specifically the operation of the NSP.<= /p>

 

Major Issues:

1.  &nb= sp; T= he draft refers in several places to the “reliable transport… p= rovided by MPLS-TE/MPLS-TP”. This terminology is inappropriate in the IETF where &quo= t;reliable" is used in a completely different sense, especially as the= draft compares the FC PW to transport of FC over TCP/IP that has been defined in RFC 3821.  The problem is = aggravated by the fact that the common PWE3 technique that allows detection= of lost and/or reordered PW packets (sequencing) is intentionally disabled (in Section 3.1 the draft state= s that the sequence number MUST be set to 0 by the sender and MUST be ignor= ed by the receiver). We have discussed t= his point with the one of the draft editors and obtained agreement that the usage of the term “reliable&= #8221; in this context is inappropriate. We highly recommend that the authors mod= ify the present text by replacing the term “relia= ble” with the actual expectations regarding delivery of the FC= PW packets (low drop rate, low chance of reordering). We also suggest addi= ng text on the handling of lost, re-ordered and duplicate FC PW packets to the Applicability secti= on.

2.    The draft pro= poses usage of “sub-rating” of FC Primitive Sequences, without = specifying acceptable sub-rating factors and without explaining whether these values require coordination between the two PEs. One of the = document editors has assured us that coordination is not required, but that= there are limitations on sub-rating in order to avoid timeouts. We strongl= y suggest that the authors add some text explaining this, providing guidance regarding suitable sub-rating val= ues.

3.  &nb= sp; The draft req= uests IANA to reserve four Interface Parameter sub-TLV values for functiona= lity that has been dropped from the draft after having been rejected by the PWE3 WG, in order to accommodate the possibili= ty of this functionality being reintroduced at some future time. This reque= st would be justified if there were multiple deployed pre-standard implemen= tations supporting this functionality (as was the case for the “Martini mode” of the Frame Relay PWs). As far as we know, there is at most only one such pre-standard implementation. We suggest that the responsible = AD decide on the proper course of action.

Minor Issues:

  1. In contrast to the rest of= the PWE3 documents, a dedicated Native Service Processor (NSP) block is ma= ndatory for implementing (and even understanding) the draft. We would like to thank the authors for = the much improved explanation of this NSP in the present version. However, = some of the functionality of the NSP operation is similar to functions that are not considered NSP functions in other PWE3 encapsula= tion documents e.g.:
    • Suppression o= f idle codes (in contrast, suppression of idle ATM cells is not= considered as an NSP function in RFC 4717)
    • Removal= of 8b/10b encoding (in contrast, the same operation is not considered as a= n NSP function in RFC 4448).

We believe that a n= ote should be added clarifying this point.

2.    T= he draft refers to MTU issues associated with the FC PW, but does= not state whether the MTU interface parameter sub-TLV MUST, SHOULD, MAY, &= #8230;, or MUST NOT be included in the Label Mapping message during the FC PW setup. Since all FC interfaces have the same MTU, this parameter is not really needed during the setup. = We suggest that the authors explicitly indicate that the Interface MTU para= meter MUST NOT appear in the FC PW setup protocol exchange. (Aside: This is based on experience wit= h RFC 5287 where the fact that it was not specified that the Interface MTU = parameter MUST NOT appear in the TDM PW setup eventually led to interoperab= ility issues). We have sent the authors proposed text to deal with this issue.

3.    The draft def= ines that the CRC of the FC frames MUST always be included in the PW encaps= ulation. However, its handling differs from the handling of FCS per RFC 4720; in particular, FC frames received with CRC e= rrors must be transmitted over the PW. It would be nice to explicitly note = this difference, and for the signaling procedure to explicitly specify non-= usage of the FCS Retention Indicator Interface Parameter sub-TLV. We have sent the authors proposed text to dea= l with this issue.

 

Regards,

     Y(J)S and Sash= a

 

--_000_07F7D7DED63154409F13298786A2ADC903D0D7F1EXRAD5adradcoil_-- From Alexander.Vainshtein@ecitele.com Sun Feb 20 08:43:00 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D89233A6CCA; Sun, 20 Feb 2011 08:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_TOWRITE=1.05] 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 U-u9FYoan65i; Sun, 20 Feb 2011 08:42:49 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 190943A6CBF; Sun, 20 Feb 2011 08:42:47 -0800 (PST) X-AuditID: 93eaf2e7-b7c4aae000007a4b-6d-4d6144af156a Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 98.C3.31307.FA4416D4; Sun, 20 Feb 2011 18:43:27 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sun, 20 Feb 2011 18:43:24 +0200 From: Alexander Vainshtein To: "rtg-ads@tools.ietf.org" , "draft-ietf-pwer-fc-encap-14.all@tools.ietf.org" Date: Sun, 20 Feb 2011 18:43:22 +0200 Thread-Topic: RtgDir review: draft-ietf-pwer-fc-encap-14.txt Thread-Index: AQHL0QnAgbrWgjrJ7EGVdx4tUkTaHZQKl8VQ Message-ID: References: <07F7D7DED63154409F13298786A2ADC903D0BA3F@EXRAD5.ad.rad.co.il> <07F7D7DED63154409F13298786A2ADC903D0D7F1@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC903D0D7F1@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76D6FBA675FEILPTMAIL02eci_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAABBci5UoXcZZxF3JOVhdyU1s= Cc: "rtg-dir@ietf.org" , Yaakov Stein , "pwe3@ietf.org" Subject: Re: [PWE3] RtgDir review: draft-ietf-pwer-fc-encap-14.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 16:43:01 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76D6FBA675FEILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I confirm that the text of the review sent by Yaakov represents our common = position. I hope that this unorthodox approach to reviewing the draft is acceptable. Regards, Sasha From: Yaakov Stein [mailto:yaakov_s@rad.com] Sent: Sunday, February 20, 2011 4:24 PM To: rtg-ads@tools.ietf.org; draft-ietf-pwer-fc-encap-14.all@tools.ietf.org Cc: rtg-dir@ietf.org; pwe3@ietf.org; Alexander Vainshtein Subject: RtgDir review: draft-ietf-pwer-fc-encap-14.txt To: * rtg-ads@tools.ietf.org * draft-ietf-pwer-fc-encap-14.all@tools.ietf.org Cc: * rtg-dir@ietf.org * pwe3@ietf.org Subject: * RtgDir review: draft-ietf-pwer-fc-encap-14.txt Hello, We (Yaakov and Sasha) have been selected as the Routing Directorate reviewe= rs for this draft. The Routing Directorate seeks to review all routing or r= outing-related drafts as they pass through IETF last call and IESG review. = The purpose of the review is to provide assistance to the Routing ADs. For = more information about the Routing Directorate, please see http://www.ietf.= org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-pwer-fc-encap-14.txt Reviewers: Alexander ("Sasha") Vainshtein and Yaakov (Jonathan) Stein Review Date: 2011/02/20 IETF LC End Date: Intended Status: Standard Track Summary: We have some concerns about this document that we believe need to be addres= sed before publication. Comments: 1. The two of us (Sasha and Yaakov) have decided to write a single joint = review, in order to reduce contradictory recommendations. 2. In order to further reduce turnaround time, we have taken the slightly= unorthodox approach of holding direct talks with one of the draft editors = (David Black). As will be seen in the following, this approach has proven t= o be highly productive. 3. The draft includes multiple references to Fibre Channel (FC) standards= , which hinder comprehension for those not expert in the technology. The st= atus of these references is also somewhat problematic: * [FC-BB-6] (Normative) triggers circular normative referencing betwe= en IETF and T11: * It is currently a T11 working document waiting for approval. * It can only be accessed by the interested IETF participants by se= nding a direct request to David Black, who is both co-editor of this draft = and T11's official liaison to the IETF. * It uses this draft as a Normative reference and hence will be app= roved by T11 only after an RFC number has been assigned to this draft. * As this is not intended to be a downref, the responsible AD will = need to explain the situation to the RFC Editor once the draft is approved = for publication. * [FC-FS-2] (Normative) is an approved T11 standard that can be acces= sed by interested IETF participants by sending a request to David Black (da= vid.black@emc.com) in his official capacity as = T11 liaison to IETF. * [FC-SP] is listed as a Normative reference. However, it describes = the FC Security Protocol that is, according to the draft, transparent to t= he FC PW. Hence it makes sense to redefine it as an Informational reference= . * All these references are flagged as warnings by the latest IETF nit= s tool. 4. We would like to thank the authors for resolving in version 14 many i= ssues that we had raised in the past regarding the K-codes, timing constrai= nts, and specifically the operation of the NSP. Major Issues: 1. The draft refers in several places to the "reliable transport... prov= ided by MPLS-TE/MPLS-TP". This terminology is inappropriate in the IETF whe= re "reliable" is used in a completely different sense, especially as the dr= aft compares the FC PW to transport of FC over TCP/IP that has been defined= in RFC 3821. The problem is aggravated by the fact that the common PWE3 t= echnique that allows detection of lost and/or reordered PW packets (sequenc= ing) is intentionally disabled (in Section 3.1 the draft states that the se= quence number MUST be set to 0 by the sender and MUST be ignored by the rec= eiver). We have discussed this point with the one of the draft editors and = obtained agreement that the usage of the term "reliable" in this context is= inappropriate. We highly recommend that the authors modify the present tex= t by replacing the term "reliable" with the actual expectations regarding d= elivery of the FC PW packets (low drop rate, low chance of reordering). We = also suggest adding text on the handling of lost, re-ordered and duplicate = FC PW packets to the Applicability section. 2. The draft proposes usage of "sub-rating" of FC Primitive Sequences, w= ithout specifying acceptable sub-rating factors and without explaining whet= her these values require coordination between the two PEs. One of the docum= ent editors has assured us that coordination is not required, but that ther= e are limitations on sub-rating in order to avoid timeouts. We strongly sug= gest that the authors add some text explaining this, providing guidance reg= arding suitable sub-rating values. 3. The draft requests IANA to reserve four Interface Parameter sub-TLV v= alues for functionality that has been dropped from the draft after having b= een rejected by the PWE3 WG, in order to accommodate the possibility of thi= s functionality being reintroduced at some future time. This request would = be justified if there were multiple deployed pre-standard implementations s= upporting this functionality (as was the case for the "Martini mode" of the= Frame Relay PWs). As far as we know, there is at most only one such pre-st= andard implementation. We suggest that the responsible AD decide on the pro= per course of action. Minor Issues: 1. In contrast to the rest of the PWE3 documents, a dedicated Native Serv= ice Processor (NSP) block is mandatory for implementing (and even understan= ding) the draft. We would like to thank the authors for the much improved e= xplanation of this NSP in the present version. However, some of the functio= nality of the NSP operation is similar to functions that are not considered= NSP functions in other PWE3 encapsulation documents e.g.: * Suppression of idle codes (in contrast, suppression of idle ATM cel= ls is not considered as an NSP function in RFC 4717) * Removal of 8b/10b encoding (in contrast, the same operation is not = considered as an NSP function in RFC 4448). We believe that a note should be added clarifying this point. 2. The draft refers to MTU issues associated with the FC PW, but does no= t state whether the MTU interface parameter sub-TLV MUST, SHOULD, MAY, ...,= or MUST NOT be included in the Label Mapping message during the FC PW setu= p. Since all FC interfaces have the same MTU, this parameter is not really = needed during the setup. We suggest that the authors explicitly indicate th= at the Interface MTU parameter MUST NOT appear in the FC PW setup protocol = exchange. (Aside: This is based on experience with RFC 5287 where the fact = that it was not specified that the Interface MTU parameter MUST NOT appear = in the TDM PW setup eventually led to interoperability issues). We have sen= t the authors proposed text to deal with this issue. 3. The draft defines that the CRC of the FC frames MUST always be includ= ed in the PW encapsulation. However, its handling differs from the handling= of FCS per RFC 4720; in particular, FC frames received with CRC errors mus= t be transmitted over the PW. It would be nice to explicitly note this diff= erence, and for the signaling procedure to explicitly specify non-usage of = the FCS Retention Indicator Interface Parameter sub-TLV. We have sent the a= uthors proposed text to deal with this issue. Regards, Y(J)S and Sasha --_000_A3C5DF08D38B6049839A6F553B331C76D6FBA675FEILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I confirm that the text of the review sent by Yaakov rep= resents our common position.

I hope that this unorthodox approach to reviewing= the draft is acceptable.

 

Regards,

     Sasha

 

From: Yaakov Ste= in [mailto:yaakov_s@rad.com]
Sent: Sunday, February 20, 2011 4:2= 4 PM
To: rtg-ads@tools.ietf.org; draft-ietf-pwer-fc-encap-14.all@= tools.ietf.org
Cc: rtg-dir@ietf.org; pwe3@ietf.org; Alexander Vai= nshtein
Subject: RtgDir review: draft-ietf-pwer-fc-encap-14.txt

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto'>To:

·         = rtg-ads@tools.ietf.org

Cc:

·         rtg-dir@ietf.org

    <= li class=3DMsoNormal style=3D'color:black;mso-margin-top-alt:auto;mso-margi= n-bottom-alt:auto;mso-list:l5 level1 lfo2'>pwe3@ie= tf.org

Subject:

·=      =     RtgDir review: draft-ietf-pwer-fc-encap-14.txt

 

Hello,

We (Yaakov and Sasha) have been selected as the Routing Directorat= e reviewers for this draft. The Routing Directorate seeks to review all rou= ting or routing-related drafts as they pass through IETF last call and IESG= review. The purpose of the review is to provide assistance to the Routing = ADs. For more information about the Routing Directorate, please see http://www.ietf.org/= iesg/directorate/routing.html

Althoug= h these comments are primarily for the use of the Routing ADs, it would be = helpful if you could consider them along with any other IETF Last Call comm= ents that you receive, and strive to resolve them through discussion or by = updating the draft.

Document: draft-ietf-pw= er-fc-encap-14.txt
Reviewers: Alexander (“Sasha”) Vainshtei= n and Yaakov (Jonathan) Stein
Review Date:  2011/02/20
IETF LC = End Date:
Intended Status: Standard Track

<= span style=3D'font-size:9.5pt;font-family:"Verdana","sans-serif";color:blac= k'> 

Summary:

We have some concerns about th= is document that we believe need to be addressed before publication.

Comments:

=
  1. The two of us (Sasha and Yaa= kov) have decided to write a single joint review, in order to reduce contra= dictory recommendations.
  2. In = order to further reduce turnaround time, we have taken the slightly unortho= dox approach of holding direct talks with one of the draft editors (David B= lack). As will be seen in the following, this approach has proven to be hig= hly productive.
  3. The draft in= cludes multiple references to Fibre Channel (FC) standards, which hinder co= mprehension for those not expert in the technology. The status of these ref= erences is also somewhat problematic:<= /span> <= o:p>
    • [FC-BB-6] (Normative) triggers circular normative referenci= ng between IETF and T11:

<= span style=3D'font-size:9.5pt;font-family:Symbol;color:black'>·&= nbsp;        It is currently a T11 working document waiti= ng for approval.

= ·   &nbs= p;     <= /span>It can only be accessed by the interested IETF participants by se= nding a direct request to David Black, who is both co-editor of this draft = and T11's official liaison to the IETF.

·         It uses this draft as a Normative referenc= e and hence will be approved by T11 only after an RFC number has been assig= ned to this draft.

·   &n= bsp;     = As this is not intended to be a downref, the re= sponsible AD will need to explain the situation to the RFC Editor once the dra= ft is approved for publication.

    • [FC-FS-2] (No= rmative) is an approved T11 standard that can be accessed by interested IET= F participants by sending a request to David Black (david.black@em= c.com) in his official capacity as T11 liaison to IETF. <= span style=3D'font-size:9.5pt;font-family:"Verdana","sans-serif"'>
    • [FC-SP]  is listed a= s a Normative reference. However, it describes the FC  Security Protoc= ol that is, according to the draft, transparent to the FC PW. Hence it make= s sense to redefine it as an Informational reference.
    • All these references are flagged as wa= rnings by the latest IETF nits tool.

4.    We would like to thank the authors for resolving in version 14 man= y issues that we had raised in the past regarding the K-codes, timing const= raints, and specifically the operation of the NSP.

 

<= b>Major Issues:

1. =    The = draft refers in several places to the “reliable transport… prov= ided by MPLS-TE/MPLS-TP”. This terminology is inappropriate in the IET= F where "reliable" is used in a completely different sense, espec= ially as the draft compares the FC PW to transp= ort of FC over TCP/IP that has been defined in RFC 3821.  The problem = is aggravated by the fact that the common PWE3 technique that allows detect= ion of lost and/or reordered PW packets (sequencing) is intentionally disabled (in Section 3.1 the draft states tha= t the sequence number MUST be set to 0 by the sender and MUST be ignored by= the receiver). We have discussed this p= oint with the one of the draft editors and obtained agreement that the usag= e of the term “reliable” in this context is inappropriate. We highly recommend that the authors modify = the present text by replacing the term &= #8220;reliable” with the actual expectations regarding deliver= y of the FC PW packets (low drop rate, low chance of reordering). We also s= uggest adding text on the handling of lost, re-= ordered and duplicate FC PW packets to the Applicability section.

2.    The draft proposes usage of “sub-rating” of FC Primi= tive Sequences, without specifying acceptable sub-rating factors and withou= t explaining whether these values require coordination between the two PEs.= One of the document editors has assured us that coordination is not requir= ed, but that there are limitations on sub-rating in order to avoid timeouts= . We strongly suggest that the authors add some text explaining this, provi= ding guidance regarding suitable sub-rating values.

3.    The draft requests IANA to reserve four Interface Parameter sub-TLV values= for functionality that has been dropped from the draft after having been r= ejected by the PWE3 WG, in order to accommodate the possibility of this fun= ctionality being reintroduced at some future time. This request would be ju= stified if there were multiple deployed pre-standard implementations suppor= ting this functionality (as was the case for the “Martini mode”= of the Frame Relay PWs). As far as we k= now, there is at most only one such pre-= standard implementation. We suggest that the responsible AD decide on the p= roper course of action.

Minor I= ssues:

  1. In contrast to the rest of the PWE3 documents, a dedicated = Native Service Processor (NSP) block is mandatory for implementing (and eve= n understanding) the draft. We would like to thank the auth= ors for the much improved explanation of this NSP in the present version. H= owever, some of the functionality of the NSP operation is similar to functi= ons that are not considered NSP functions in other PWE3 encapsulation docum= ents e.g.:
    • Suppression of idle codes (in contrast, suppression of idle ATM= cells is not considered as an NSP function in RFC 4717) <= /li>
    • Removal of = 8b/10b encoding (in contrast, the same operation is not considered as an NS= P function in RFC 4448).

We believe that a note should be added clarifying t= his point.

2.    The draft refers to MTU issues associated wit= h the FC PW, but does not state whether the MTU interface parameter sub-TLV= MUST, SHOULD, MAY, …, or MUST NOT be included in the Label Mapping m= essage during the FC PW setup. Since all FC interfaces have the same MTU, this parameter is not really needed during the s= etup. We suggest that the authors explicitly indicate that the Interface MT= U parameter MUST NOT appear in the FC PW setup protocol exchange. (<= i>Aside: This is based on experience with RFC 5287 where the fact that it w= as not specified that the Interface MTU parameter MUST NOT appear in the TD= M PW setup eventually led to interoperability issues). We have sent the= authors proposed text to deal with this issue.

3. = ;   The draft defin= es that the CRC of the FC frames MUST always be included in the PW encapsul= ation. However, its handling differs from the handling of FCS per RFC 4720;= in particular, FC frames received with CRC errors must be transmitted over= the PW. It would be nice to explicitly note this difference, and for the s= ignaling procedure to explicitly specify non-usage of the FCS Retention Ind= icator Interface Parameter sub-TLV. We have sent the authors proposed text = to deal with this issue.

=  

Regards,

     Y(J)S and Sasha

 

= --_000_A3C5DF08D38B6049839A6F553B331C76D6FBA675FEILPTMAIL02eci_-- From manavbhatia@gmail.com Sun Feb 20 16:21:18 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877EC3A6CEC for ; Sun, 20 Feb 2011 16:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.044 X-Spam-Level: X-Spam-Status: No, score=-3.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 RI6S78pCKstc for ; Sun, 20 Feb 2011 16:21:17 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 903CB3A6CC3 for ; Sun, 20 Feb 2011 16:21:17 -0800 (PST) Received: by wwa36 with SMTP id 36so5754400wwa.13 for ; Sun, 20 Feb 2011 16:21:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=FWTZsbIhbOJLe7jINPEXGU9KtrjuxkEDx65KOOXAgeA=; b=PModKtEu8dP4xpXyHuMWGrMQlcbLL7pXkMQbIbyeYxRU5S1DZSW6ReFefFMR7zp68p Jjx/8XWPbmPiJO4INqzRR2I8+1MF7ex2T1wJm1fRgwEmxsEdpwfCMLf8QnWeI+wVbGHS TxTi/I+kMNUbtC8glLsaeCoA1EEySJDi+JZKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=BhEQm5ZaB1cN0orfnvIA9If4DiyHf3f4k1V1oN7FysOVJBy0QlOqffFSgYHqVFAIHo 0D9QwD4en6DkNFEA/ezBz3eb8bMOcOHFanfJG8kvdF6sb0aead9kC5tls4KDqHvBuQiV YURdhm0rGR4DGyekR+udGWMx1dShmF2cersHI= MIME-Version: 1.0 Received: by 10.227.30.31 with SMTP id s31mr627036wbc.27.1298247717012; Sun, 20 Feb 2011 16:21:57 -0800 (PST) Received: by 10.227.149.16 with HTTP; Sun, 20 Feb 2011 16:21:56 -0800 (PST) Date: Mon, 21 Feb 2011 05:51:56 +0530 Message-ID: From: Manav Bhatia To: pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-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: Mon, 21 Feb 2011 00:21:18 -0000 Support. > Message: 1 > Date: Wed, 16 Feb 2011 13:46:19 +0100 > From: "Bocci, Matthew (Matthew)" > Subject: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-03.txt > To: "pwe3@ietf.org" > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > WG, > > The authors of draft-jin-pwe3-cbit-negotiation-03 have asked that > the WG adopt this as a PWE3 working group draft. > > This email begins a two week poll to help us judge if there is > consensus to move forward with the draft. > > Please post any comments to the PWE3 list by Wednesday 2nd March. > > Regards, > > Matthew & Andy From mach.chen@huawei.com Mon Feb 21 02:02:15 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157313A6AFF for ; Mon, 21 Feb 2011 02:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 aJv7VKAaz9wd for ; Mon, 21 Feb 2011 02:02:14 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id F23ED3A707B for ; Mon, 21 Feb 2011 02:02:13 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGY00J2OP5RZA@szxga05-in.huawei.com> for pwe3@ietf.org; Mon, 21 Feb 2011 18:01:03 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGY00DC6P583R@szxga05-in.huawei.com> for pwe3@ietf.org; Mon, 21 Feb 2011 18:01:03 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 21 Feb 2011 18:00:55 +0800 Received: from SZXEML502-MBS.china.huawei.com ([169.254.2.38]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Mon, 21 Feb 2011 18:00:57 +0800 Date: Mon, 21 Feb 2011 10:00:56 +0000 From: Mach Chen In-reply-to: X-Originating-IP: [10.110.98.47] To: "Bocci, Matthew (Matthew)" , "pwe3@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_yxFMche21OtqCg0NPh5BiQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: WG Poll on draft-jin-pwe3-cbit-negotiation-03.txt Thread-index: AcvN14N/U4dKgzs0QU+tIbqk21be5gD1qqRg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-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: Mon, 21 Feb 2011 10:02:15 -0000 --Boundary_(ID_yxFMche21OtqCg0NPh5BiQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Support. Best regards, Mach From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) Sent: Wednesday, February 16, 2011 8:46 PM To: pwe3@ietf.org Subject: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-03.txt WG, The authors of draft-jin-pwe3-cbit-negotiation-03 have asked that the WG adopt this as a PWE3 working group draft. This email begins a two week poll to help us judge if there is consensus to move forward with the draft. Please post any comments to the PWE3 list by Wednesday 2nd March. Regards, Matthew & Andy --Boundary_(ID_yxFMche21OtqCg0NPh5BiQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Support.

 = ;

Best regar= ds,

Mach<= /o:p>

 = ;

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)
Sent: Wednesday, February 16, 2011 8:46 PM
To: pwe3@ietf.org
Subject: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-03.txt

 

WG, <= /o:p>

The authors of draft-jin-pwe3-cbit-negoti= ation-03 have asked that the WG adopt this as a PWE3 working group draft.

 <= /o:p>

This email begins a two week poll to help us judge if the= re is consensus to move forward with the draft.

 <= /o:p>

Please post any comments to the PWE3 list by Wednesday 2n= d March.

 <= /o:p>

Regards,

 <= /o:p>

Matthew & Andy

--Boundary_(ID_yxFMche21OtqCg0NPh5BiQ)-- From nick.delregno@verizon.com Mon Feb 21 10:55:21 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DDFB3A6E09; Mon, 21 Feb 2011 10:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.603, 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 DNoezABpdAdE; Mon, 21 Feb 2011 10:55:18 -0800 (PST) Received: from ashesmtp02.verizonbusiness.com (ashesmtp02.verizonbusiness.com [198.4.8.166]) by core3.amsl.com (Postfix) with ESMTP id 3D5503A6E38; Mon, 21 Feb 2011 10:55:18 -0800 (PST) Received: from omzismtp03.vzbi.com ([unknown] [165.122.46.170]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LGZ00HCWDXB6Q10@firewall.verizonbusiness.com>; Mon, 21 Feb 2011 18:56:00 +0000 (GMT) Received: from omzismtp03.vzbi.com ([unknown] [127.0.0.1]) by omzismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LGZ00A4KDXBXU00@omzismtp03.vzbi.com>; Mon, 21 Feb 2011 18:55:59 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([unknown] [153.39.68.167]) by omzismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LGZ00A6CDXAWX00@omzismtp03.vzbi.com>; Mon, 21 Feb 2011 18:55:59 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Feb 2011 18:55:58 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01CBD1F8.F8BB3703" Date: Mon, 21 Feb 2011 18:55:54 +0000 Message-id: <14584D6EE26B314187A4F68BA206060006A9D633@ASHEVS008.mcilink.com> In-reply-to: <14584D6EE26B314187A4F68BA2060600067709F5@ASHEVS008.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: LAST WEEK!! PW/VCCV User Implementation Survey Thread-index: Act8YpSEMMoOD4/+SCeRBwpsUYLmAgTfklMQDL9wpzADxnTEgA== References: <14584D6EE26B314187A4F68BA206060005AE91E1@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA206060005DB543A@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA2060600067709F5@ASHEVS008.mcilink.com> From: "Delregno, Christopher N (Nick DelRegno)" To: pwe3 , mpls@ietf.org, l2vpn@ietf.org X-OriginalArrivalTime: 21 Feb 2011 18:55:58.0100 (UTC) FILETIME=[F9AAB540:01CBD1F8] Subject: [PWE3] LAST WEEK!! PW/VCCV User Implementation Survey 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, 21 Feb 2011 18:55:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD1F8.F8BB3703 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All: =20 This is the last week to participate in the PW/VCCV User Implementation Survey. The deadline for submissions is February 25th. The survey will be ended this Friday evening and the results analyzed. =20 We have 11 responses so far. =20 It is important that we get as many participants as possible to ensure fair representation in any future PW Control Word and VCCV related work in the PWE3 working group. =20 Thanks, Nick =20 =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=3D=3D=3D=3D=3D=3D =20 All: =20 Per the direction of the PWE3 working group, beginning in IETF77 and reinforced in IETF78, the PWE3 working group is conducting a Service Provider implementation survey related to: =20 - Pseudowire Encapsulations - Control Word Support - Control Word Use - VCCV Control Channel Support - VCCV Control Channel Use =20 http://www.surveymonkey.com/s/pwe3 =20 This is a short survey directed toward Service Providers who currently operate networks using any of the defined PWE3 encapsulations. The results of this survey will be used to determine the direction of the Control Word support in current and future encapsulations as well as solutions to VCCV interoperability challenges. =20 We sincerely urge all service providers to participate. We ask that all equipment providers encourage participation by their Service Provider customers. The more feedback we receive, the better view of the existing network we can have on which to base going-forward direction. =20 If you have any questions, regarding the survey, especially of a technical nature, please contact me. If you have non-technical questions, feel free to reach out to the PWE3 WG chairs and myself. =20 The results of the survey will be aggregated and shared at a high level. No low-level details of network implementations will be shared. All participant's responses will remain private, if not anonymous. =20 All responses will require a valid email address to help ensure the survey's validity. =20 Thanks, Nick =20 Christopher N. "Nick" DelRegno, PMTS CNT, Ethernet Network Architecture & Design 400 International Pkwy Richardson, TX 75081 Tel: 972-729-3411 Email: Nick.DelRegno@verizon.com =20 ------_=_NextPart_001_01CBD1F8.F8BB3703 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All:

 

This is the = last week to participate in the PW/VCCV User Implementation = Survey.  The deadline for submissions is February 25th.  The = survey will be ended this Friday evening and the results = analyzed.

 

We have 11 responses so far.

 

It is = important that we get as many participants as possible to ensure fair = representation in any future PW Control Word and VCCV related work in = the PWE3 working group.

 

Thanks,

Nick

 

=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=3D=3D=3D=3D=3D=3D

 

All:

 

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

 

-          = Pseudowire Encapsulations

-          = Control Word Support

-          = Control Word Use

-          = VCCV Control Channel Support

-          = VCCV Control Channel Use

 

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

 

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

 

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

 

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

 

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

 

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

 

Thanks,

Nick

 

Christopher N. “Nick” DelRegno, = PMTS

CNT, Ethernet Network Architecture & = Design

400 International Pkwy

Richardson, TX  = 75081

Tel:  972-729-3411

Email:  = Nick.DelRegno@verizon.com

 

------_=_NextPart_001_01CBD1F8.F8BB3703-- From venkatflex@gmail.com Mon Feb 21 11:22:14 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FBE63A714D for ; Mon, 21 Feb 2011 11:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 xAgLzNxTb714 for ; Mon, 21 Feb 2011 11:22:13 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 855CB3A714B for ; Mon, 21 Feb 2011 11:22:13 -0800 (PST) Received: by qwh6 with SMTP id 6so711352qwh.31 for ; Mon, 21 Feb 2011 11:22:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=fNbFBEi69w3gpypDUjnvrm5wHwj+eNIWwaS6fHWwQYQ=; b=mqZUMOxrqs8FLQf9ZCKFVrsB/eL/5qHScjJ1CuvTnnAH/Y3LrStAtLJ1Utxt34QXxX Pz95yXMel2RTx81PMD6DRC7vy1AYkVWVN1bu9Ns4kjDGZvnLTJU2Ih2HJZrhZTe4aq1/ oMtXsPgUe3OLVIzzS6l3znMwNDKsSU10k/9Y0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=l1zF6Q9XaE3F+OiL1yQeZcSrf/71956QJuAr55rfiq7aHdvw+RAYlwUltDq+Xn+pEE ckADehZAEtJtxdKN/vA2ZsPCG0ax4c0kRpWpj+vsReVgNSmMRJ26xPs/tSsT5ESWplfw 5lmpPSOYWw2QP5dYdNM3c7p8LTGq00n+ARdVU= MIME-Version: 1.0 Received: by 10.224.60.73 with SMTP id o9mr1465036qah.58.1298316174990; Mon, 21 Feb 2011 11:22:54 -0800 (PST) Received: by 10.224.20.71 with HTTP; Mon, 21 Feb 2011 11:22:54 -0800 (PST) Date: Mon, 21 Feb 2011 14:22:54 -0500 Message-ID: From: venkatesan mahalingam To: pwe3@ietf.org Content-Type: multipart/alternative; boundary=0015175ca8246a9f61049ccfca70 Subject: Re: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-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: Mon, 21 Feb 2011 19:22:14 -0000 --0015175ca8246a9f61049ccfca70 Content-Type: text/plain; charset=ISO-8859-1 Yes/Support. R, -Venkat. > Message: 1 > Date: Wed, 16 Feb 2011 13:46:19 +0100 > From: "Bocci, Matthew (Matthew)" > Subject: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-03.txt > To: "pwe3@ietf.org" > Message-ID: > Content-Type: text/plain; charset="us-ascii" > WG, > > The authors of draft-jin-pwe3-cbit-negotiation-03 have asked that > the WG adopt this as a PWE3 working group draft. > > This email begins a two week poll to help us judge if there is > consensus to move forward with the draft. > > Please post any comments to the PWE3 list by Wednesday 2nd March. > > Regards, > > Matthew & Andy -- Best Regards, Venkatesan Mahalingam. --0015175ca8246a9f61049ccfca70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes/Support.

R,
-Venkat.

> Message: 1
> Date: Wed, 16 Feb 2011 13:46:19 +0100<= br>> From: "Bocci, Matthew (Matthew)" <matthew= .bocci@alcatel-lucent.com>
> Subject: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-03.txt
&= gt; To: "pwe3@ietf.org" <pwe3@ietf.org>
> Message-ID: <C981779B.9722%matthew.boc= ci@alcatel-lucent.com>
> Content-Type: text/plain; charset=3D&= quot;us-ascii"

> WG,
>
> The authors of draft-jin-pwe3-cbit-negotiation= -03 have asked that
> the WG adopt this as a PWE3 working group draft= .
>
> This email begins a two week poll to help us judge if the= re is
> consensus to move forward with the draft.
>
> Please post = any comments to the PWE3 list by Wednesday 2nd March.
>
> Regar= ds,
>
> Matthew & Andy

--
Best Regards,
Venkatesan Mahalingam.
--0015175ca8246a9f61049ccfca70-- From vivien.sterling@gmail.com Tue Feb 22 01:26:13 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8537C3A677E; Tue, 22 Feb 2011 01:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 5EN9ynjaHZMJ; Tue, 22 Feb 2011 01:26:12 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id 059923A65A6; Tue, 22 Feb 2011 01:26:11 -0800 (PST) Received: by bwz12 with SMTP id 12so3447407bwz.27 for ; Tue, 22 Feb 2011 01:26:55 -0800 (PST) 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 :message-id:subject:from:to:content-type; bh=G2etffR/qjnXH9giDS7En2AQmiLTc9K6/oRRgvusS9A=; b=q93fpiJtv8SUL/75YA2DPVOZ7qip1ryJPP5Zqd7Pm+3B5KJ9RRbbV4w2cXCdjVl0IB spI4EvVvUjZB1nD7rDldVcmT7uN7xM+0vjsMS8nF8GFTAQJVhueCB8uqqZB4s9ybZcHk DkYC/wMqvgOp6Me42G0nlb++fj5ffpyW/zfAw= 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=NEwfpDjkJtfcO935VWzXB9QfKMnfuJoAWX65BTNLK11VPWJqEYWk8i9jte8ZSOgY3N p7BaUxM8msAZULGTI2WwvXHgvXq8XxawGnWmruXj5ihCH5qrUJJSLn1oyp4/IEyTwbM2 q+/TAzZ25DONtG+l+GtmleL2+WDLX1hUs+Vvs= MIME-Version: 1.0 Received: by 10.204.46.154 with SMTP id j26mr2195524bkf.134.1298366815068; Tue, 22 Feb 2011 01:26:55 -0800 (PST) Received: by 10.204.32.82 with HTTP; Tue, 22 Feb 2011 01:26:55 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Feb 2011 10:26:55 +0100 Message-ID: From: Vivien Sterling To: "pwe3@ietf.org" , "mpls@ietf.org" , "mpls-tp@ietf.org" Content-Type: multipart/alternative; boundary=0016e6d77f15cce387049cdb942e Subject: Re: [PWE3] PWE3 WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-00 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, 22 Feb 2011 09:26:13 -0000 --0016e6d77f15cce387049cdb942e Content-Type: text/plain; charset=ISO-8859-1 Yes, support. -- Cheers, Vivien On Thu, Feb 17, 2011 at 2:34 PM, Bocci, Matthew (Matthew) < matthew.bocci@alcatel-lucent.com> wrote: > This email begins a working group last call for > draft-ietf-pwe3-mpls-tp-gal-in-pw-00.txt. > > This is a very short draft but since there are other MPLS-TP-related last > calls going on concurrently, this will be a three-week last call. > > This WG LC will end of 11th March 2011. > > Please respond with any comments to the PWE3 mailing list. > > Regards, > > Matthew and Andy > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --0016e6d77f15cce387049cdb942e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, support.
=A0
--
Cheers,
Vivien


On Thu, Feb 17, 2011 at 2:34 PM, Bocci, Matthew = (Matthew) <matthew.bocci@alcatel-lucent.com> wrote:
This email begins a working grou= p last call for
draft-ietf-pwe3-mpls-tp-gal-in-pw-00.txt.

This is= a very short draft but since there are other MPLS-TP-related last
calls going on concurrently, this will be a three-week last call.

Th= is WG LC will end of 11th March 2011.

Please respond with any commen= ts to the PWE3 mailing list.

Regards,

Matthew and Andy


_______________________________________________
pwe3 mailing lis= t
pwe3@ietf.org
https://www.ietf.o= rg/mailman/listinfo/pwe3

--0016e6d77f15cce387049cdb942e-- From david.sinicrope@ericsson.com Tue Feb 22 02:30:36 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA213A686A for ; Tue, 22 Feb 2011 02:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QA-E0GIBMsgs for ; Tue, 22 Feb 2011 02:30:35 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 7BBD23A684A for ; Tue, 22 Feb 2011 02:30:35 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p1MBI7L3026555 for ; Tue, 22 Feb 2011 05:18:09 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.208]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 22 Feb 2011 05:31:12 -0500 From: David Sinicrope To: "IETF.PWE3" Date: Tue, 22 Feb 2011 05:31:08 -0500 Thread-Topic: PWE3 Agenda Slot Call for IETF 80 - Prague Thread-Index: AcvSe6BAwFBshLvlQomd9GCWxNSyfA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PWE3] PWE3 Agenda Slot Call for IETF 80 - Prague 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, 22 Feb 2011 10:30:36 -0000 Reminder for PWE3 slot call. Dave From: David Sinicrope > Date: Wed, 9 Feb 2011 00:35:39 -0500 To: "IETF.PWE3" > Subject: PWE3 Agenda Slot Call for IETF 80 - Prague Hi All, Please let me know if you would like a time slot for the IETF 80 PWE3 sessi= on by replying to this email with the desired duration, topic/draft title, = and presenter for each slot requested. Thanks, Dave From ehudd@orckit.com Tue Feb 22 02:32:24 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401CE3A6866; Tue, 22 Feb 2011 02:32:24 -0800 (PST) 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 vLuibPt9S1QK; Tue, 22 Feb 2011 02:32:23 -0800 (PST) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by core3.amsl.com (Postfix) with ESMTP id 048EA3A6845; Tue, 22 Feb 2011 02:32:22 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Feb 2011 12:32:40 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA081306897922@tlvmail1> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] PWE3 WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-00 Thread-Index: AcvOp2qo3CL3sSTlSLeLd/7Gd8zznQD1ENqg References: From: "Ehud Doron" To: "Bocci, Matthew (Matthew)" , X-Mailman-Approved-At: Tue, 22 Feb 2011 08:39:50 -0800 Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [PWE3] PWE3 WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-00 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, 22 Feb 2011 10:32:24 -0000 Support Ehud=A0=A0=A0 Doron System Architect=20 Orckit - Corrigent -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of = Bocci, Matthew (Matthew) Sent: Thursday, February 17, 2011 3:35 PM To: pwe3@ietf.org Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [PWE3] PWE3 WG LC on draft-ietf-pwe3-mpls-tp-gal-in-pw-00 This email begins a working group last call for draft-ietf-pwe3-mpls-tp-gal-in-pw-00.txt. This is a very short draft but since there are other MPLS-TP-related = last calls going on concurrently, this will be a three-week last call. This WG LC will end of 11th March 2011. Please respond with any comments to the PWE3 mailing list. Regards, Matthew and Andy =20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From javi@trajano.us.es Thu Feb 24 03:57:14 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2DF3A6AAF for ; Thu, 24 Feb 2011 03:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.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 6XuIxyCzACLd for ; Thu, 24 Feb 2011 03:57:13 -0800 (PST) Received: from mail.us.es (mail.us.es [193.147.175.20]) by core3.amsl.com (Postfix) with ESMTP id C38E83A6AA9 for ; Thu, 24 Feb 2011 03:57:12 -0800 (PST) Received: (qmail 32393 invoked from network); 24 Feb 2011 12:57:58 +0100 Received: from unknown (HELO us.es) (192.168.2.11) by us.es with SMTP; 24 Feb 2011 12:57:58 +0100 Received: (qmail 27202 invoked by uid 507); 24 Feb 2011 11:57:57 -0000 Received: from 127.0.0.1 by antivirus1 (envelope-from , uid 501) with qmail-scanner-2.08 (clamdscan: 0.97/12769. Clear:RC:1(127.0.0.1):. Processed in 0.045968 secs); 24 Feb 2011 11:57:57 -0000 Received: from unknown (HELO antivirus1) (127.0.0.1) by us.es with SMTP; 24 Feb 2011 11:57:57 -0000 Received: from 192.168.1.13 (192.168.1.13) by antivirus1 (F-Secure/fsigk_smtp/403/antivirus1); Thu, 24 Feb 2011 12:57:57 +0100 (CET) X-Virus-Status: clean(F-Secure/fsigk_smtp/403/antivirus1) Received: (qmail 29149 invoked from network); 24 Feb 2011 12:57:56 +0100 Received: from trajano.us.es (HELO trajano.telematica) (193.147.162.130) by us.es with AES256-SHA encrypted SMTP; 24 Feb 2011 12:57:56 +0100 Received: from [193.147.162.138] (adriano.us.es [193.147.162.138]) (authenticated bits=0) by trajano.telematica (8.13.8/8.13.8/Debian-3) with ESMTP id p1OBvtXC006320 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 24 Feb 2011 12:57:56 +0100 Message-ID: <4D6647C9.7000200@trajano.us.es> Date: Thu, 24 Feb 2011 12:58:01 +0100 From: =?windows-1252?Q?Javi_Mu=F1oz?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "pwe3@ietf.org" References: <4D4369B5.9010102@trajano.us.es> <4D43DE5C.4090008@cisco.com> <4D440389.9040405@trajano.us.es> <07F7D7DED63154409F13298786A2ADC903CDC087@EXRAD5.ad.rad.co.il> <4D49F7D1.7020502@trajano.us.es> <07F7D7DED63154409F13298786A2ADC903CDD930@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC903CDD930@EXRAD5.ad.rad.co.il> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PWE3] TDMPW and MeGaCo/SDP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 11:57:14 -0000 Hi Yaakov and all, Setting-up a full mesh of PW does not scale well in this scenario (in fact, we have also faced this problem in L2VPN services). It is not a matter of BW, but of number of PW at every Access Gateway (AGW). It will require the establishment of a PW to every potential destination AGW (which may be in the numbers of tens of thousands for a single PNO). Native signalling is OK for individual channels inside the PW, and the PW control plane is OK for negotiating PW features end-to-end, but we (the MGC) still need to tell the AGW to trigger the PW establishment to a given destination AGW. The IP address of the destination AGW (and perhaps other parameters) should be communicated to the source AGW (by the MGC), so that the former can start the PW establishment procedure. And, even in the case you mention (pre-established PW), we (the MGC) still need to tell the AGW wich PW to use. It is not the AGW who knows the final destination, but the MGC (where the high-level signaling terminates). In fact I believe that the VPN example mentioned above has some similarities with the AGW scenario: in the BGP-based L3VPN (rfc 4364, was 2547bis) you do use an extra control plane (iBGP) to tell the VRF (access node) which PW to use, using an iBGP attribute (the "label") that may be thought as an "SDP description" May be I'm wrong, but, if I were right and you finally agree with my point, I would like to know your opinion on which standard body should specify the SDP description of the PW parameters: - will it be the IETF?. Some examples of similar cases where the IETF defines an SDP description to be used by a third signalling protocol may be IETF RFC4733 (SDP description for codec "telephone-event") or RFC4733 (event codes). - will if be the ITU? Some examples of similar cases where the ITU-T defines SDP atributes to be used by other protocols are V.152 (attribute "a=gpmd"), T.38 (SDP description for the protocol "udptl" and "tcptl"), V.150.1 ("a=sprtmap: v150mr/8000") and V.151 (codec "a=rtpmap: t140c/8000"). - will it be any other? Javi 06/02/2011 14:08, Yaakov Stein wrote: > Javi > > SAToP, CESoPSN, and TDMoIP-AAL1 TDM PWs are usually set up before they are needed, > and remain up as long as they may be needed. > The individual channels are then set up using native signaling. > > The scenario you mention (setting up bandwidth as needed) is handled in Y.1414 and Y.1452, > and is not in the spirit of Y.1413 or Y.1453. > There are mechanisms in RFC 5287 for the TDMoIP AAL2 mode, > that help map individual voice channels. > Once an AAL2 mode PW is set up, you needn't signal for every channel up/down event, > since the BW is not consumed if not used. > > Y(J)S From nick.delregno@verizon.com Fri Feb 25 07:20:43 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4493A68F1; Fri, 25 Feb 2011 07:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[AWL=0.321, 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 QL4tXTjP8NWM; Fri, 25 Feb 2011 07:20:36 -0800 (PST) Received: from ashesmtp01.verizonbusiness.com (ashesmtp01.verizonbusiness.com [198.4.8.163]) by core3.amsl.com (Postfix) with ESMTP id 531B33A682C; Fri, 25 Feb 2011 07:20:35 -0800 (PST) Received: from omzismtp02.vzbi.com ([unknown] [165.122.46.167]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LH60070WINRV2A0@firewall.verizonbusiness.com>; Fri, 25 Feb 2011 15:21:28 +0000 (GMT) Received: from omzismtp02.vzbi.com ([unknown] [127.0.0.1]) by omzismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LH600M0HINR8X00@omzismtp02.vzbi.com>; Fri, 25 Feb 2011 15:21:27 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([unknown] [153.39.68.168]) by omzismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LH600MC5INR5S00@omzismtp02.vzbi.com>; Fri, 25 Feb 2011 15:21:27 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Feb 2011 15:21:27 +0000 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01CBD4FF.AB5ADCFF" X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 25 Feb 2011 15:21:19 +0000 Message-id: <14584D6EE26B314187A4F68BA206060006B14EB7@ASHEVS008.mcilink.com> In-reply-to: <14584D6EE26B314187A4F68BA206060006A9D633@ASHEVS008.mcilink.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: LAST CHANCE!! PW/VCCV User Implementation Survey Closes Today @ 5PM CST Thread-index: Act8YpSEMMoOD4/+SCeRBwpsUYLmAgTfklMQDL9wpzADxnTEgADBYkhg References: <14584D6EE26B314187A4F68BA206060005AE91E1@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA206060005DB543A@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA2060600067709F5@ASHEVS008.mcilink.com> <14584D6EE26B314187A4F68BA206060006A9D633@ASHEVS008.mcilink.com> From: "Delregno, Christopher N (Nick DelRegno)" To: pwe3 , mpls@ietf.org, l2vpn@ietf.org X-OriginalArrivalTime: 25 Feb 2011 15:21:27.0237 (UTC) FILETIME=[ABAFDF50:01CBD4FF] Subject: [PWE3] LAST CHANCE!! PW/VCCV User Implementation Survey Closes Today @ 5PM CST 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, 25 Feb 2011 15:20:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD4FF.AB5ADCFF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All: =20 This is the last day to participate in the PW/VCCV User Implementation Survey. The survey closes today at 5PM CST. I will aggregate the responses and provide the results via a draft and presentation in Prague. =20 We have 18 responses so far. Thank you to all who have provided this valuable information! =20 Thanks, Nick =20 =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=3D=3D=3D=3D=3D=3D =20 All: =20 Per the direction of the PWE3 working group, beginning in IETF77 and reinforced in IETF78, the PWE3 working group is conducting a Service Provider implementation survey related to: =20 - Pseudowire Encapsulations - Control Word Support - Control Word Use - VCCV Control Channel Support - VCCV Control Channel Use =20 http://www.surveymonkey.com/s/pwe3 =20 This is a short survey directed toward Service Providers who currently operate networks using any of the defined PWE3 encapsulations. The results of this survey will be used to determine the direction of the Control Word support in current and future encapsulations as well as solutions to VCCV interoperability challenges. =20 We sincerely urge all service providers to participate. We ask that all equipment providers encourage participation by their Service Provider customers. The more feedback we receive, the better view of the existing network we can have on which to base going-forward direction. =20 If you have any questions, regarding the survey, especially of a technical nature, please contact me. If you have non-technical questions, feel free to reach out to the PWE3 WG chairs and myself. =20 The results of the survey will be aggregated and shared at a high level. No low-level details of network implementations will be shared. All participant's responses will remain private, if not anonymous. =20 All responses will require a valid email address to help ensure the survey's validity. =20 Thanks, Nick =20 Christopher N. "Nick" DelRegno, PMTS CNT, Ethernet Network Architecture & Design 400 International Pkwy Richardson, TX 75081 Tel: 972-729-3411 Email: Nick.DelRegno@verizon.com =20 ------_=_NextPart_001_01CBD4FF.AB5ADCFF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

All:

 

This is the = last day to participate in the PW/VCCV User Implementation Survey.  = The survey closes today at 5PM CST.  I will aggregate the responses = and provide the results via a draft and presentation in = Prague.

 

We have 18 responses so far.  Thank you to all = who have provided this valuable information!

 

Thanks,

Nick

 

=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=3D=3D=3D=3D=3D=3D

 

All:

 

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

 

-          = Pseudowire Encapsulations

-          = Control Word Support

-          = Control Word Use

-          = VCCV Control Channel Support

-          = VCCV Control Channel Use

 

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

 

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

 

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

 

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

 

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

 

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

 

Thanks,

Nick

 

Christopher N. “Nick” DelRegno, = PMTS

CNT, Ethernet Network Architecture & = Design

400 International Pkwy

Richardson, TX  = 75081

Tel:  972-729-3411

Email:  = Nick.DelRegno@verizon.com

 

------_=_NextPart_001_01CBD4FF.AB5ADCFF-- From lmartini@cisco.com Mon Feb 28 13:44:27 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C9E3A6CBB for ; Mon, 28 Feb 2011 13:44:27 -0800 (PST) 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 POoz2U4vZOjz for ; Mon, 28 Feb 2011 13:44:26 -0800 (PST) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by core3.amsl.com (Postfix) with ESMTP id 5F4723A69FE for ; Mon, 28 Feb 2011 13:44:26 -0800 (PST) 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 p1SLjN1C009839 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 28 Feb 2011 14:45:23 -0700 (MST) Message-ID: <4D6C1773.70406@cisco.com> Date: Mon, 28 Feb 2011 14:45:23 -0700 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 ThunderBrowse/3.3.4 MIME-Version: 1.0 To: "Bocci, Matthew (Matthew)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andrew Malis , "pwe3@ietf.org" Subject: Re: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-03.txt ( comment ) 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, 28 Feb 2011 21:44:27 -0000 Matthew & Andy, Although I support clarifying this procedure , I believe this document needs some work. In section 3 for example : When Local PE changes its control word from NOT PREFERRED to PREFERRED and only if it already received the remote label mapping message with C-bit=0, additional procedure will be added as follow: -i. Local PE sends label withdraw message to the remote if it already sends label mapping message, for it has changed its control word parameter. -ii. Local PE MUST send a label request messages to peer PE to get peer's configured control word parameter before sending new label mapping message to peer PE. -iii. After receiving the new label mapping message from peer PE and updating the remote label binding information, the Local PE should send label mapping to peer PE according to procedures defined in [RFC4447]. What does the item i) mean ? the English is not clear. Why does the PE have to do ii) ? All we really need is a statement on how the c-bit negotiation state machine can be reset if one end has changed "his mind" . Can we fix this document before issuing the -00 WG draft version ? Thanks. Luca On 02/16/11 05:46, Bocci, Matthew (Matthew) wrote: > WG, > > The authors of draft-jin-pwe3-cbit-negotiation-03 have asked that the > WG adopt this as a PWE3 working group draft. > > This email begins a two week poll to help us judge if there is > consensus to move forward with the draft. > > Please post any comments to the PWE3 list by Wednesday 2nd March. > > Regards, > > Matthew & Andy > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From lmartini@cisco.com Mon Feb 28 14:56:05 2011 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37413A6CBA for ; Mon, 28 Feb 2011 14:56:04 -0800 (PST) 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] 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 98gg1WaEvMxy for ; Mon, 28 Feb 2011 14:56:04 -0800 (PST) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by core3.amsl.com (Postfix) with ESMTP id 12D8B3A6CAF for ; Mon, 28 Feb 2011 14:56:04 -0800 (PST) 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 p1SMv5p0014645 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 28 Feb 2011 15:57:05 -0700 (MST) Message-ID: <4D6C2841.2020709@cisco.com> Date: Mon, 28 Feb 2011 15:57:05 -0700 From: Luca Martini User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 ThunderBrowse/3.3.4 MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [PWE3] more comments on draft-jin-pwe3-cbit-negotiation-03 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, 28 Feb 2011 22:56:05 -0000 Authors, In section 3 on page 4 is the following text : "The procedure of PE1 and PE2 for the case in figure 1 should be as follows: 1. PE2 changes locally configured control word to PREFERRED. 2. PE2 will then send label withdraw message to PE1. 3. PE2 MUST send label request messages to PE1 although it already received the label mapping with C-bit=0. 4. PE1 will send label release in reply to label withdraw message from PE2. 5. PE1 will send label mapping message with C-bit=1 again to PE2 (Note: PE1 MUST send label mapping with locally configured CW parameter). 6. PE2 receives the label mapping from PE1 and updates the remote label binding information. PE2 MUST wait for PE1 label binding before sending its label binding with C-bit set, only if it previously had a label binding with C-bit = 0 from PE1. 7. PE2 will send label mapping to PE1 with C-bit=1. " First of all the steps above are asynchronous, so it seems that step 4 should appear before step 3 or the old label mapping might be sent. Step 5 is in response to step 3 , but that is not clear from the above list. Also what happens if PE1 cannot support the CW ? The above description assumes PE1 can support the CW. Also this label withdraw + label request procedure is fully backward compatible with previous implementations. The document should explain this point. The label withdraw should really wait for the label release, as in the case of MS-PWs , sending an immediate label request can cause a race condition , and result in the wrong state. Thanks. Luca