From pwe3-bounces@ietf.org Thu Jun 01 06:08:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flk6b-0007sl-PL; Thu, 01 Jun 2006 06:08:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flk6a-0007nl-79 for pwe3@ietf.org; Thu, 01 Jun 2006 06:08:40 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flk6X-0006d9-Ap for pwe3@ietf.org; Thu, 01 Jun 2006 06:08:40 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0600L7GFHVEB@szxga02-in.huawei.com> for pwe3@ietf.org; Thu, 01 Jun 2006 18:22:43 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0600ATYFHVPK@szxga02-in.huawei.com> for pwe3@ietf.org; Thu, 01 Jun 2006 18:22:43 +0800 (CST) Received: from c50408 ([10.110.114.173]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J06004U7F9AV1@szxml04-in.huawei.com> for pwe3@ietf.org; Thu, 01 Jun 2006 18:17:35 +0800 (CST) Date: Thu, 01 Jun 2006 18:07:16 +0800 From: Cao Wei To: sajassi@cisco.com Message-id: <009601c68563$29727020$ad726e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <0J0400035AYUPV@szxga01-in.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: pwe3 Subject: [PWE3] Re: X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi, sajassi, Yes, 802.1ah frames can be transmitted in "raw mode", if PE does not want to do any extra work other than transmission. However, as pointed out in PWE3 arechitecture, in most cases pre-processing operations should be undertaken by PE to provide cost and operational benefits. 802.1ah introduces some new services and I doubt that if these new features can be covered by "vlan mode". Thanks. ----- Original Message ----- From: Sent: Wednesday, May 31, 2006 2:48 PM > > There is currently "raw mode" and "tagged mode" and the VLAN tag can be > carried in either of the modes, although its interpretation and > processing would be different at the NSP. For .1ah frames, why not just > simply look at the Ethernet type at the NSP and process it accordingly > - 802.1Q, .1ad, and .1ah all have their own Eth type. Either "raw mode" > or "tagged mode" can be used by .1ah. > > ________________________________ > > From: Cao Wei [mailto:caowayne@huawei.com]=20 > Sent: Tuesday, May 30, 2006 5:03 AM > To: pwe3@ietf.org > Subject: [PWE3] Suggestion of a new mode for Ethernet PW for > 802.1ah > =09 > =09 > Hi, all > I am doing some work on ethernet PW to support 802.1ah. At > present, two ethernet pw modes are defined: "raw mode" and "vlan mode". > But to support 802.1ah, NSP may have to inspect I-TAG rather than the > outmost tag only. So I suggust to introduce a new mode for this. > Is there any need or interest for this? I am writing a draft > to describe this and hope to recive advices. > =20 > Best Regards, > Cao Wei > > > ------_=_NextPart_001_01C6847E.3563401F > Content-Type: text/html; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > > > charset=3Dus-ascii"> > > > > >
face=3DArial=20 > color=3D#0000ff size=3D2>There is currently "raw mode" and "tagged = > mode" and=20 > the VLAN tag can be carried in either of the modes, although its = > interpretation=20 > and processing would be different at the NSP. For .1ah frames, why not = > just=20 > simply look at the Ethernet type at the NSP and process it=20 > accordingly  - 802.1Q, .1ad, and .1ah all have their own = > Eth=20 > type. Either "raw mode" or "tagged mode" can be used by=20 > .1ah.
>
face=3DArial=20 > color=3D#0000ff size=3D2> 
>
face=3DArial=20 > color=3D#0000ff size=3D2>-Ali 

>
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = > solid; MARGIN-RIGHT: 0px"> >
>
> From: Cao Wei = > [mailto:caowayne@huawei.com]=20 >
Sent: Tuesday, May 30, 2006 5:03 AM
To:=20 > pwe3@ietf.org
Subject: [PWE3] Suggestion of a new mode for = > Ethernet=20 > PW for 802.1ah

>
>
Hi, all
>
   I am doing some work on ethernet PW to support = > 802.1ah.=20 > At present, two ethernet pw modes are defined: "raw mode" and = > "vlan=20 > mode". But to support 802.1ah, NSP may have to inspect I-TAG rather = > than the=20 > outmost tag only. So I suggust to introduce a new mode for = > this.
>
   Is there any need or interest for this? I = > am writing a=20 > draft to describe this and hope to recive advices.
>
 
>
Best Regards,
>
    Cao Wei
> > ------_=_NextPart_001_01C6847E.3563401F-- > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jun 01 06:15:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlkCl-0001UJ-BY; Thu, 01 Jun 2006 06:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlkCj-0001U4-L5 for pwe3@ietf.org; Thu, 01 Jun 2006 06:15:01 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlkCh-0007EK-AP for pwe3@ietf.org; Thu, 01 Jun 2006 06:15:01 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J06004QHEVZ2B@szxga01-in.huawei.com> for pwe3@ietf.org; Thu, 01 Jun 2006 18:09:35 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0600FLHEVZI4@szxga01-in.huawei.com> for pwe3@ietf.org; Thu, 01 Jun 2006 18:09:35 +0800 (CST) Received: from c50408 ([10.110.114.173]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J06004DHFB5O9@szxml04-in.huawei.com> for pwe3@ietf.org; Thu, 01 Jun 2006 18:18:42 +0800 (CST) Date: Thu, 01 Jun 2006 18:08:23 +0800 From: Cao Wei Subject: Re: [PWE3] Suggestion of a new mode for Ethernet PW for 802.1ah To: Yaakov Stein , pwe3@ietf.org Message-id: <00ac01c68563$51321110$ad726e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal References: <457D36D9D89B5B47BC06DA869B1C815D9EAD4F@exrad3.ad.rad.co.il> X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0106136550==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0106136550== Content-type: multipart/alternative; boundary="Boundary_(ID_tl6bfNfu3w+p+aSkjlXjSA)" This is a multi-part message in MIME format. --Boundary_(ID_tl6bfNfu3w+p+aSkjlXjSA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, Yaakov, I also think there are some scenarios we can consider about with 802.1ah, e.g. PBNs are connected by PW. IMHO, services supported by PWE3 are more important than pure encapsulation. Thanks. ----- Original Message ----- From: Yaakov Stein To: Cao Wei ; pwe3@ietf.org Sent: Wednesday, May 31, 2006 11:07 PM Subject: RE: [PWE3] Suggestion of a new mode for Ethernet PW for 802.1ah Cao, From the pure encap point of view, nothing is needed. There is, however, an interesting issue regarding the interaction with MS-PWs. One could map BVIDs into VPWS PW labels for each domain, or one could try to to map an ISID using PW-switching. Another issue is when we have a concatenation of PBNs, PBBNs, and MPLS networks. Some portions will be 1ad, some 1ah, and some supported by PWs. Y(J)S ------------------------------------------------------------------------------ From: Cao Wei [mailto:caowayne@huawei.com] Sent: Tuesday, May 30, 2006 14:03 To: pwe3@ietf.org Subject: [PWE3] Suggestion of a new mode for Ethernet PW for 802.1ah Hi, all I am doing some work on ethernet PW to support 802.1ah. At present, two ethernet pw modes are defined: "raw mode" and "vlan mode". But to support 802.1ah, NSP may have to inspect I-TAG rather than the outmost tag only. So I suggust to introduce a new mode for this. Is there any need or interest for this? I am writing a draft to describe this and hope to recive advices. Best Regards, Cao Wei --Boundary_(ID_tl6bfNfu3w+p+aSkjlXjSA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi, Yaakov,
 
   I also think there are some scenarios we can consider about with 802.1ah, e.g. PBNs are connected by PW.
IMHO, services supported by PWE3 are more important than pure encapsulation.
 
Thanks.
----- Original Message -----
Sent: Wednesday, May 31, 2006 11:07 PM
Subject: RE: [PWE3] Suggestion of a new mode for Ethernet PW for 802.1ah

Cao,
 
From the pure encap point of view, nothing is needed.
 
There is, however, an interesting issue regarding the interaction with MS-PWs.
 
One could map BVIDs into VPWS PW labels for each domain,
or one could try to to map an ISID using PW-switching.
 
Another issue is when we have a concatenation of PBNs, PBBNs,
and MPLS networks. Some portions will be 1ad, some 1ah,
and some supported by PWs.
 
Y(J)S
 
 
From: Cao Wei [mailto:caowayne@huawei.com]
Sent: Tuesday, May 30, 2006 14:03
To: pwe3@ietf.org
Subject: [PWE3] Suggestion of a new mode for Ethernet PW for 802.1ah

Hi, all
   I am doing some work on ethernet PW to support 802.1ah. At present, two ethernet pw modes are defined: "raw mode" and "vlan mode". But to support 802.1ah, NSP may have to inspect I-TAG rather than the outmost tag only. So I suggust to introduce a new mode for this.
   Is there any need or interest for this? I am writing a draft to describe this and hope to recive advices.
 
Best Regards,
    Cao Wei
--Boundary_(ID_tl6bfNfu3w+p+aSkjlXjSA)-- --===============0106136550== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0106136550==-- From pwe3-bounces@ietf.org Thu Jun 01 11:47:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpOi-000555-8E; Thu, 01 Jun 2006 11:47:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpOh-000550-Dw for pwe3@ietf.org; Thu, 01 Jun 2006 11:47:43 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpOf-00006B-5K for pwe3@ietf.org; Thu, 01 Jun 2006 11:47:43 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2006 08:47:41 -0700 X-IronPort-AV: i="4.05,199,1146466800"; d="scan'208"; a="429545293:sNHT33337036" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k51Fldps000965; Thu, 1 Jun 2006 08:47:40 -0700 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k51FldLf018526; Thu, 1 Jun 2006 17:47:39 +0200 (MEST) Received: from [64.103.65.89] (dhcp-gpk02-vlan300-64-103-65-89.cisco.com [64.103.65.89]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA27730; Thu, 1 Jun 2006 16:47:38 +0100 (BST) Message-ID: <447F0C1A.8080503@cisco.com> Date: Thu, 01 Jun 2006 16:47:38 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=101; t=1149176860; x=1150040860; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:Stewart=20Bryant=20 |Subject:PWE3=20mtg=20@=20IETF66; X=v=3Dcisco.com=3B=20h=3D9Esf7rnjSypn1UtqsXPiaKzVX1c=3D; b=diLpGu737YaI2/gjJ83G7LH6QU2FtGu4gA+mFUToc47ycBohB42OtG8HlN98CUHvEmv60Z67 jXdTRJlZCc/tz5ixVjD6cte2teo+/J+CvvQJFpe8lq1S/chMhrsjrk2D; Authentication-Results: sj-dkim-3.cisco.com; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Matthew BOCCI , Danny McPherson Subject: [PWE3] PWE3 mtg @ IETF66 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org We need to start planning IETF66. Please can you submit your slot requests. Thanks Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jun 01 12:10:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpkM-0001qY-87; Thu, 01 Jun 2006 12:10:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpkK-0001pm-BV for pwe3@ietf.org; Thu, 01 Jun 2006 12:10:04 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpkJ-00026h-2O for pwe3@ietf.org; Thu, 01 Jun 2006 12:10:04 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2006 09:10:04 -0700 X-IronPort-AV: i="4.05,199,1146466800"; d="scan'208"; a="429549329:sNHT28492270" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k51GA1QD000472; Thu, 1 Jun 2006 09:10:02 -0700 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k51GA1Lf024535; Thu, 1 Jun 2006 18:10:01 +0200 (MEST) Received: from [64.103.65.89] (dhcp-gpk02-vlan300-64-103-65-89.cisco.com [64.103.65.89]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA00068; Thu, 1 Jun 2006 17:10:00 +0100 (BST) Message-ID: <447F1157.2010207@cisco.com> Date: Thu, 01 Jun 2006 17:09:59 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=284; t=1149178202; x=1150042202; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=stbryant@cisco.com; z=From:Stewart=20Bryant=20 |Subject:draft-ietf-pwe3-ms-pw-requirements-02.txt=20-=20last=20call; X=v=3Dcisco.com=3B=20h=3D7OotpU25Frvj4Ljc/LvFo8fqOjs=3D; b=O0FAokGyUDYWPsjOfqF5nrJd7fE0PH0KssKdtdiQ/0ORhkBgSE3T41twD8eo4lg8KEJx5Wpu SsG9xRuurUfkcmbfmiZjrESH+NYb0QDUnsYLAeM8HzezQitWy2kLboRc; Authentication-Results: sj-dkim-1.cisco.com; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Danny McPherson Subject: [PWE3] draft-ietf-pwe3-ms-pw-requirements-02.txt - last call X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is the start of last call on http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-requirements-02.txt Last call will end 19th June 2006. Please read the draft. We need to finish with this before we can move forward on the MS protocol drafts. Thanks Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jun 02 04:30:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm53O-0000FF-DR; Fri, 02 Jun 2006 04:30:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm53N-0000FA-HM for pwe3@ietf.org; Fri, 02 Jun 2006 04:30:45 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm53M-0007Oc-7B for pwe3@ietf.org; Fri, 02 Jun 2006 04:30:45 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 02 Jun 2006 01:30:44 -0700 X-IronPort-AV: i="4.05,202,1146466800"; d="scan'208"; a="287621697:sNHT38919028" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k528Ugro020020 for ; Fri, 2 Jun 2006 01:30:43 -0700 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k528UgLf003362 for ; Fri, 2 Jun 2006 10:30:42 +0200 (MEST) Received: from [10.61.81.46] (ams3-vpn-dhcp4399.cisco.com [10.61.81.46]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA13671; Fri, 2 Jun 2006 09:30:41 +0100 (BST) Message-ID: <447FF731.3060208@cisco.com> Date: Fri, 02 Jun 2006 09:30:41 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1820; t=1149237043; x=1150101043; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:Stewart=20Bryant=20 |Subject:[Fwd=3A=20Internet-Drafts=20Submission=20Cutoff=20Dates=20for=20the=2066 th=20IETF=20Meeting=0A=20in=20Montreal,=20Quebec,=20Canada]; X=v=3Dcisco.com=3B=20h=3DTqET+xNpnMrj6ebePuba8QcYQec=3D; b=H4reEyRxDax5jU8P9OEatRrcJ4Q0BePkwzXXEwLXiEtAn7oVgS/Rnf8pDk9K0LZ77fzYrVau 19XQ8GNcPmx0VmXX41Awda2mbsa/sn4Up4UAYJNvQx6DbpJBZtskBdt/; Authentication-Results: sj-dkim-4.cisco.com; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [PWE3] [Fwd: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada] X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org -------- Original Message -------- Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada Date: Fri, 02 Jun 2006 00:00:01 -0400 From: ietf-secretariat@ietf.org To: ietf-announce@ietf.org There are two (2) Internet-Draft cutoff dates for the 66th IETF Meeting in Montreal, Quebec, Canada: June 19th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, June 19th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, June 12th at 9:00 AM ET. June 26th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, June 26th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, July 10th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 66th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_66.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jun 02 07:58:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8Im-0003LF-Vd; Fri, 02 Jun 2006 07:58:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8Im-0003Ey-4I for pwe3@ietf.org; Fri, 02 Jun 2006 07:58:52 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm8Ik-0004Lt-Iv for pwe3@ietf.org; Fri, 02 Jun 2006 07:58:52 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 02 Jun 2006 04:58:49 -0700 X-IronPort-AV: i="4.05,203,1146466800"; d="scan'208"; a="287711032:sNHT47877992" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k52BwmWo015456 for ; Fri, 2 Jun 2006 04:58:49 -0700 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k52BwlLf006304 for ; Fri, 2 Jun 2006 13:58:48 +0200 (MEST) Received: from [10.61.81.137] (ams3-vpn-dhcp4490.cisco.com [10.61.81.137]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA01453; Fri, 2 Jun 2006 12:58:47 +0100 (BST) Message-ID: <448027F7.2080903@cisco.com> Date: Fri, 02 Jun 2006 12:58:47 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=6650; t=1149249529; x=1150113529; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=stbryant@cisco.com; z=From:Stewart=20Bryant=20 |Subject:Study=20Group=2015=20Liaison=20-=20final=20draft; X=v=3Dcisco.com=3B=20h=3DiTjVjfW+yZ/trtnkv/edxjH6UhE=3D; b=Bdw7PVARs34+ypYtlPrA20LpvgvTDBCe+rNHZepOqulcKuYOv7iM9PwfrE9pBmF66Nr58iKC m5FWxfo4or0XBSDGuUms88m11MiquhZ+ZhLlI/Q+tjGt3iFDsUBJQ/rn; Authentication-Results: sj-dkim-1.cisco.com; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Subject: [PWE3] Study Group 15 Liaison - final draft X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I have incorporated all of the comments that I have received from the PWE3 WG members in the text below. I will send this out over the weekend. Please read and indicate any final corrections needed. Many Thanks Stewart ======================================================== To: ITU-T Study Group 15 Greg Jones greg.jones@itu.int tsbsg15@itu.int Cc: IETF statements@ietf.org Stephen Trowbridge sjtrowbridge@lucent.com Ghani Abbas Ghani.Abbas@marconi.com Mark Jones mark.jones@sprint.com Malcolm Betts betts01@nortel.com Yoichi Maeda maeda@ansl.ntt.co.jp Scott Bradner Adrian Farrel Jari Arkko Mark Townsley Danny McPherson PWE3 mailing list From: IETF PWE3 Working Group Response contact: Stewart Bryant stbryant@cisco.com Technical contact: Stewart Bryant stbryant@cisco.com Purpose: Information Subject: Response to your liaison on T-MPLS of May 4 and April 2 2006 Thank you for your liaisons of May 4 and April 2 and for the kind invitation to the interim meeting that 19-23 June in Ottawa. We have studied the consented documents from the April liaison and the further clarifications in the May liaisons. We have ensured that IETF technical experts will participate in the Ottawa meeting. You are already in receipt of comments from the IETF MPLS-WG with which we fully concur. These comments refer to G.8110.1/Y.1370.1 Appendix 1: Functional Model for describing PWE3 and MPLS Network Interworking G.8110.1 states: "The IETF PWE3 work group has developed an MPLS transport concept, know as pseudowires." Later G.8110.1 states: "The PSN can be implemented by utilizing a MPLS label switched network." PWE3 has developed methods of transporting services over many different PSNs, one of which is MPLS. G.8110.1 states: "PWE3 is intended to provide only the minimum necessary functionality to emulate a wire with the required degree of faithfulness for the given service definition." The purpose behind the wording "provide only the minimum" was to prevent over engineering. In many cases, PWE3 provides more than just the minimum necessary functionality. We think that to put this quote from RFC3985 in it's proper context you should note that in our view an applicability statement MUST always be provided to clearly describe the extent of the emulation, and that in some cases more than one emulation method may be needed. G.8110.1 states: "A four octet Control Word is added to the MPLS payload field for some encapsulations." The control word is DEFINED for all payload types. Use is optional for HDLC/PPP, Ethernet and some ATM modes, but is REQUIRED in all other cases. G.8110.1 states: "these processes are called "Native Signal Processing (NSP)" NSP stands for Native Service Processing G.8110.1 states: "The NSP function process the Control Word." The NSP does handle the flags (when there are flags defined). However the PW-layer processing handles the sequencing, FRG, etc. G.8110.1 states: "IETF has defined pseudowire encapsulations for Ethernet, Frame Relay, ATM, PPP, PDH, and SDH." The PPP emulation also emulates HDLC, and the SDH design also supports SONET. We also have a design for Fibre- Channel and the IETF AVT WG has a design for header compressed voice samples. G.8110.1 states: "The Forwarder function is called an Interworking Function (IWF)" It is not clear that IWF and forwarder are identical in scope and purpose. G.8110.1 states: In Figure 9 Pseudowire Model G.8110.1 shows the PW as a trail with a T-MPLS trail termination function. This termination is defined here as injecting Y.1710 OAM. The IETF PWE3 specifications use VCCV as the PW OAM. G.8110.1 states: "Pseudowires can be switched by a Subnetwork Connection (SNC). This creates in PWE3 terminology Multi-Segment Pseudowires (MS-PW) as defined in the bibliography reference [1]." Bibliography reference [1] is RFC 3985, which was published prior to our work on MS-PWs. The correct reference is reference [2]. G.8110.1 states: "When the MPLS server layer is an SDH layer network, an SDH path layer may be used instead of the pseudowire PSN transport tunnel. This approach has been called "dry martini" as defined in the bibliography reference [2]." The correct reference is reference [3]. We must however caution you that this work has not been adopted as an IETF PWE3 working group item. The draft was an individual submission which has now expired under the IETF policy of expiring such drafts after six months. Within the scope material you state: "a T-MPLS network will not peer directly with an IP/MPLS network". The data plane behavior of the one currently supported adaptation ("EVC") is intended to be that of an Ethernet pseudowire as specified in Y.1415 and RFC4448. Thus it is possible for "IP/MPLS" and T-MPLS networks to interoperate at the level of the pseudowire, e.g. a multi-segment PW could span adjacent "IP/MPLS" and T-MPLS networks connected by an S-PE. G.8110.1 states: "From an OAM perspective, pseudowires provide service-specific status and alarm management". However PW status signaling and VCCV are agnostic to the native service type. PWE3 members who are also SG13 experts make the following additional observations: G.8110.1 states: "ITU SG 13 has developed a series of recommendations for MPLS / Client Network Interworking for Ethernet (Y.1415), ATM (Cell Mode - Y.1411), ATM (Frame Mode - Y.1412), and TDM (Y.1413). These recommendations are similar in concept to IETF PWE3." You omit X.84 (frame relay PW), which, although developed by SG17, it is now in SG13. These recommendations are are identical in concept, and to the best of the ability of those concerned are identical in detail. We note that in Figure 8 you pick the semi-formal diagram from Y.1415 when the same Recommendation has a G.805 diagram as well. We recommend that you show Figure 6-2 of Y.1415 in its place. G.8110.1 states: "Pseudowires can be used as a packet transport mechanism for emulating LAN Services over a Transport MPLS network. Like in Virtual Private LAN Service (VPLS) a full mesh of T-MPLS trails (PW trails) is used to interconnect split-horizon ETH Flow Domains." We suggest that you reference Appendix I of Y.1415. Stewart Bryant IETF PWE3 Working Group Co-Chair _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jun 02 11:50:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmBvA-0000w0-Q9; Fri, 02 Jun 2006 11:50:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmBv9-0000vq-57 for pwe3@ietf.org; Fri, 02 Jun 2006 11:50:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmA8N-0000jp-AY for pwe3@ietf.org; Fri, 02 Jun 2006 09:56:15 -0400 Received: from smail.alcatel.fr ([64.208.49.165]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fm9wp-0004ke-Jd for pwe3@ietf.org; Fri, 02 Jun 2006 09:44:22 -0400 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k52DhwmW016264; Fri, 2 Jun 2006 15:44:15 +0200 In-Reply-To: <447F0C1A.8080503@cisco.com> Subject: Re: [PWE3] PWE3 mtg @ IETF66 To: Stewart Bryant X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel.co.uk Date: Fri, 2 Jun 2006 14:41:43 +0100 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/02/2006 14:44:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: -2.6 (--) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: pwe3 , Danny McPherson X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Please CC me on any requests for slots. Thanks, Matthew Stewart Bryant To pwe3 01/06/2006 16:47 cc Matthew BOCCI/GB/ALCATEL@ALCATEL, Danny McPherson Subject [PWE3] PWE3 mtg @ IETF66 We need to start planning IETF66. Please can you submit your slot requests. Thanks Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jun 02 12:18:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCMF-0004rF-Um; Fri, 02 Jun 2006 12:18:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCME-0004lU-EA for pwe3@ietf.org; Fri, 02 Jun 2006 12:18:42 -0400 Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmCMC-0006vV-Ij for pwe3@ietf.org; Fri, 02 Jun 2006 12:18:42 -0400 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.13.6/8.13.6) with ESMTP id k52GIciX009034 for ; Fri, 2 Jun 2006 21:48:38 +0530 Received: from cheux004.che.flextronics.com ([10.203.112.4]) by espion.blr.hss.hns.com (Lotus Domino Release 6.5.5) with ESMTP id 2006060221473587-29392 ; Fri, 2 Jun 2006 21:47:35 +0530 Received: from chem0104 ([10.203.113.32]) by cheux004.che.flextronics.com (8.13.6/8.13.5) with SMTP id k52G2rOY014797 for ; Fri, 2 Jun 2006 21:33:11 +0530 From: Arumugam Vembu To: Date: Fri, 2 Jun 2006 21:48:15 +0530 Message-ID: <009601c68660$28136560$2071cb0a@asia.ad.flextronics.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal X-MIMETrack: Itemize by SMTP Server on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 06/02/2006 09:47:35 PM, Serialize by Router on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 06/02/2006 09:47:37 PM, Serialize complete at 06/02/2006 09:47:37 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [PWE3] PW and Transport tunnel mapping at egress X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arumugam Vembu List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hello, I need clarification for the following questions, could be a basic one. Still any help/pointer would be very much appreciated. 1. At egress side, how to identify a TE/Non-TE Transport LSP over which a particular PW has been mapped? This is required to program the data plane with proper ILM operation of Tunnel and PW labels at egress side. The pwMplsInboundTable entry (pwMplsInboundXcIndex) associated to the tunnel is a Read-only object, how this would be populated in the control plane? 2. Label stacking using LSR mib. A transport tunnel(mplsTunnelTable) has been created. Need to map 2 flows over this tunnel. 1. From an FTN (mplsFTNTable) and 2. From an another tunnel (mplsTunnelTable). How to achieve this? Thanks in advance. With Regards, Arumugam _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jun 02 12:47:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCoV-0004n9-IR; Fri, 02 Jun 2006 12:47:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCoV-0004n4-3Q for pwe3@ietf.org; Fri, 02 Jun 2006 12:47:55 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmCoT-0003TG-PT for pwe3@ietf.org; Fri, 02 Jun 2006 12:47:55 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 02 Jun 2006 09:47:39 -0700 X-IronPort-AV: i="4.05,204,1146466800"; d="scan'208"; a="1818153051:sNHT40279338244" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k52GlcRS025216; Fri, 2 Jun 2006 09:47:38 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k52GlVJ6028485; Fri, 2 Jun 2006 09:47:38 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Jun 2006 12:47:06 -0400 Received: from [10.83.15.54] ([10.83.15.54]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Jun 2006 12:47:06 -0400 In-Reply-To: <009601c68660$28136560$2071cb0a@asia.ad.flextronics.com> References: <009601c68660$28136560$2071cb0a@asia.ad.flextronics.com> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: [PWE3] PW and Transport tunnel mapping at egress Date: Fri, 2 Jun 2006 12:47:05 -0400 To: Arumugam Vembu X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 02 Jun 2006 16:47:06.0639 (UTC) FILETIME=[2EC8A1F0:01C68664] DKIM-Signature: a=rsa-sha1; q=dns; l=1242; t=1149266858; x=1150130858; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=22Thomas=20D.=20Nadeau=22=20 |Subject:Re=3A=20[PWE3]=20PW=20and=20Transport=20tunnel=20mapping=20at=20egress; X=v=3Dcisco.com=3B=20h=3D1OS7T1MUHAaHRZtgAVgel52I2Dc=3D; b=Gl7UvAQ5Py2V++35/81jg4wbdvVIgK3wRJBGiC7DIoFAejRRPBk+CjzIuqqBmRL09K8OffVh m3dTZ4C3rH8HVE2m8wfuK2x2PzPm9g6dNu586mQT3ONEVLXqFIH6KDfZ; Authentication-Results: sj-dkim-7.cisco.com; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org On Jun 2, 2006, at 12:18 PM, Arumugam Vembu wrote: > Hello, > > I need clarification for the following questions, could be a basic > one. > Still any help/pointer would be very much appreciated. > > 1. At egress side, how to identify a TE/Non-TE Transport LSP over > which a > particular PW has been mapped? This is required to program the data > plane > with proper ILM operation of Tunnel and PW labels at egress side. The > pwMplsInboundTable entry (pwMplsInboundXcIndex) associated to the > tunnel is > a Read-only object, how this would be populated in the control plane? There is an explanation of how to do provisioning using the MIB in the PW-MIB as I recall. > 2. Label stacking using LSR mib. > > A transport tunnel(mplsTunnelTable) has been created. Need to map 2 > flows > over this tunnel. > 1. From an FTN (mplsFTNTable) and > 2. From an another tunnel (mplsTunnelTable). > How to achieve this? Look at the PW-MPLS-MIB and the PW-MIB for how to do this. --Tom > > Thanks in advance. > > With Regards, > Arumugam > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jun 02 15:50:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFf2-00016t-09; Fri, 02 Jun 2006 15:50:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFel-0000uJ-Qo; Fri, 02 Jun 2006 15:50:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmFek-0004Fz-8k; Fri, 02 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k52Jo1WR028336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FmFej-0008Hi-TZ; Fri, 02 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 02 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-vccv-09.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) Author(s) : T. Nadeau, et al. Filename : draft-ietf-pwe3-vccv-09.txt Pages : 24 Date : 2006-6-2 This document describes Virtual Circuit Connection Verification (VCCV) procedures for use with pseudo wire (PW) connections. VCCV supports connection verification applications for PWs regardless of the underlying public service network technology. VCCV makes use of IP-based protocols to perform operations and maintenance functions. This is accomplished by providing a control channel associated with each PW. A network operator may use the VCCV procedures to test the network's forwarding plane liveliness. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-vccv-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-vccv-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-2123948.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-vccv-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-vccv-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-2123948.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Sat Jun 03 06:05:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmT0C-0008W5-C8; Sat, 03 Jun 2006 06:05:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmSzx-0008TU-PE; Sat, 03 Jun 2006 06:04:51 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmSzx-0007MZ-8P; Sat, 03 Jun 2006 06:04:49 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 03 Jun 2006 03:04:48 -0700 X-IronPort-AV: i="4.05,205,1146466800"; d="scan'208"; a="288284641:sNHT37975424" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k53A4lRo017872; Sat, 3 Jun 2006 03:04:48 -0700 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k53A4hLf028281; Sat, 3 Jun 2006 12:04:44 +0200 (MEST) Received: from [10.61.81.137] (ams3-vpn-dhcp4490.cisco.com [10.61.81.137]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA00418; Sat, 3 Jun 2006 11:04:40 +0100 (BST) Message-ID: <44815EB7.3000901@cisco.com> Date: Sat, 03 Jun 2006 11:04:39 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.jones@itu.int, tsbsg15@itu.int Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=6357; t=1149329088; x=1150193088; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:Stewart=20Bryant=20 |Subject:PWE3=20Liaison=20Response=3A=20T-MPLS=20; X=v=3Dcisco.com=3B=20h=3DQJ3j3oX2/GdB1sgqYMBJ1GtVAoo=3D; b=koWil1sbCIiP3yDRJe/EJ9Mtd0SMK4/xCmJhyRcZTEXkVXx82snzYDZDNzKSH6dDDFpd2diS Wk/jFgk4bGo+nra8CE1+MPIlMxmBFM1REE20f2v65Eyc29ZB6MZDofG3; Authentication-Results: sj-dkim-4.cisco.com; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: sjtrowbridge@lucent.com, mark.jones@sprint.com, maeda@ansl.ntt.co.jp, pwe3@ietf.org, statements@ietf.org, sob@harvard.edu, townsley@cisco.com, "Betts betts01"@nortel.com, danny@arbor.net, jari.arkko@piuha.net, Ghani.Abbas@marconi.com Subject: [PWE3] PWE3 Liaison Response: T-MPLS X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org To: ITU-T Study Group 15 Greg Jones greg.jones@itu.int tsbsg15@itu.int Cc: IETF statements@ietf.org Stephen Trowbridge sjtrowbridge@lucent.com Ghani Abbas Ghani.Abbas@marconi.com Mark Jones mark.jones@sprint.com Malcolm Betts betts01@nortel.com Yoichi Maeda maeda@ansl.ntt.co.jp Scott Bradner Adrian Farrel Jari Arkko Mark Townsley Danny McPherson PWE3 mailing list From: IETF PWE3 Working Group Response contact: Stewart Bryant stbryant@cisco.com Technical contact: Stewart Bryant stbryant@cisco.com Purpose: Information Subject: Response to your liaison on T-MPLS of May 4 and April 2 2006 Thank you for your liaisons of May 4 and April 2 and for the kind invitation to the interim meeting that 19-23 June in Ottawa. We have studied the consented documents from the April liaison and the further clarifications in the May liaisons. We have ensured that IETF technical experts will participate in the Ottawa meeting. You are already in receipt of comments from the IETF MPLS-WG with which we fully concur. These comments refer to G.8110.1/Y.1370.1 Appendix 1: Functional Model for describing PWE3 and MPLS Network Interworking G.8110.1 states: "The IETF PWE3 work group has developed an MPLS transport concept, know as pseudowires." Later G.8110.1 states: "The PSN can be implemented by utilizing a MPLS label switched network." PWE3 has developed methods of transporting services over many different PSNs, one of which is MPLS. G.8110.1 states: "PWE3 is intended to provide only the minimum necessary functionality to emulate a wire with the required degree of faithfulness for the given service definition." The purpose behind the wording "provide only the minimum" was to prevent over engineering. In many cases, PWE3 provides more than just the minimum necessary functionality. We think that to put this quote from RFC3985 in it's proper context you should note that in our view an applicability statement MUST always be provided to clearly describe the extent of the emulation, and that in some cases more than one emulation method may be needed. G.8110.1 states: "A four octet Control Word is added to the MPLS payload field for some encapsulations." The control word is DEFINED for all payload types. Use is optional for HDLC/PPP, Ethernet and some ATM modes, but is REQUIRED in all other cases. G.8110.1 states: "these processes are called "Native Signal Processing (NSP)" NSP stands for Native Service Processing G.8110.1 states: "The NSP function process the Control Word." The NSP does handle the flags (when there are flags defined). However the PW-layer processing handles the sequencing, FRG, etc. G.8110.1 states: "IETF has defined pseudowire encapsulations for Ethernet, Frame Relay, ATM, PPP, PDH, and SDH." The PPP emulation also emulates HDLC, and the SDH design also supports SONET. We also have a design for Fibre- Channel and the IETF AVT WG has a design for header compressed voice samples. G.8110.1 states: "The Forwarder function is called an Interworking Function (IWF)" It is not clear that IWF and forwarder are identical in scope and purpose. G.8110.1 states: In Figure 9 Pseudowire Model G.8110.1 shows the PW as a trail with a T-MPLS trail termination function. This termination is defined here as injecting Y.1710 OAM. The IETF PWE3 specifications use VCCV as the PW OAM. G.8110.1 states: "Pseudowires can be switched by a Subnetwork Connection (SNC). This creates in PWE3 terminology Multi-Segment Pseudowires (MS-PW) as defined in the bibliography reference [1]." Bibliography reference [1] is RFC 3985, which was published prior to our work on MS-PWs. The correct reference is reference [2]. G.8110.1 states: "When the MPLS server layer is an SDH layer network, an SDH path layer may be used instead of the pseudowire PSN transport tunnel. This approach has been called "dry martini" as defined in the bibliography reference [2]." The correct reference is reference [3]. We must however caution you that this work has not been adopted as an IETF PWE3 working group item. The draft was an individual submission which has now expired under the IETF policy of expiring such drafts after six months. Within the scope material you state: "a T-MPLS network will not peer directly with an IP/MPLS network". The data plane behavior of the one currently supported adaptation ("EVC") is intended to be that of an Ethernet pseudowire as specified in Y.1415 and RFC4448. Thus it is possible for "IP/MPLS" and T-MPLS networks to interoperate at the level of the pseudowire, e.g. a multi-segment PW could span adjacent "IP/MPLS" and T-MPLS networks connected by an S-PE. G.8110.1 states: "From an OAM perspective, pseudowires provide service-specific status and alarm management". However PW status signaling and VCCV are agnostic to the native service type. PWE3 members who are also SG13 experts make the following additional observations: G.8110.1 states: "ITU SG 13 has developed a series of recommendations for MPLS / Client Network Interworking for Ethernet (Y.1415), ATM (Cell Mode - Y.1411), ATM (Frame Mode - Y.1412), and TDM (Y.1413). These recommendations are similar in concept to IETF PWE3." You omit X.84 (frame relay PW), which, although developed by SG17, it is now in SG13. These recommendations are are identical in concept, and to the best of the ability of those concerned are identical in detail. We note that in Figure 8 you pick the semi-formal diagram from Y.1415 when the same Recommendation has a G.805 diagram as well. We recommend that you show Figure 6-2 of Y.1415 in its place. G.8110.1 states: "Pseudowires can be used as a packet transport mechanism for emulating LAN Services over a Transport MPLS network. Like in Virtual Private LAN Service (VPLS) a full mesh of T-MPLS trails (PW trails) is used to interconnect split-horizon ETH Flow Domains." We suggest that you reference Appendix I of Y.1415. Stewart Bryant IETF PWE3 Working Group Co-Chair _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sat Jun 03 11:02:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmXe4-0004lz-2k; Sat, 03 Jun 2006 11:02:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmXe2-0004gd-HD for pwe3@ietf.org; Sat, 03 Jun 2006 11:02:30 -0400 Received: from webmail.axerra.com ([80.74.100.75] helo=mail.axerra.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmXdz-0001uz-T1 for pwe3@ietf.org; Sat, 03 Jun 2006 11:02:30 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C68727.51E26F4A" Subject: FW: [PWE3] I-D ACTION:draft-ietf-pwe3-vccv-09.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 3 Jun 2006 18:03:57 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [PWE3] I-D ACTION:draft-ietf-pwe3-vccv-09.txt Thread-Index: AcaGhnRm4kd3QgayQ7KJmvAagNP1zAAnL4Lg From: "Sasha Vainshtein" To: "Tnadeau \(E-mail\)" , "Rahul Aggarwal \(E-mail\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: "PWE3 WG \(E-mail\)" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C68727.51E26F4A Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Tom, Rahul and all, I have a couple of questions related to the VCCV draft. 1. Source IP address in the VCCV LSP-Ping Echo Requests and Replies: a) RFC 4397 (LSP-Ping] defines in Section 4.3., that the source IP = address of the LSP Echo Request packet is a routable IP address of the sender. In Section 4.5., the same = rule is defined for setting the Source IP address of the LSP-Ping Echo Reply b) When a Single Segment PW (SS-PW) is set up using LDP (as described = in RFC 4447), one of the routable addresses of the PE is used to set up a Targeted LDP session between the = PEs. c) If LSP-Ping Echo request is sent across a SS-PW set up using LDP, = is it required to use IP address=20 that has been used for establishing the corresponding Targeted LDP = session as the source IP address=20 of the LSP-Ping Echo Request pack, or can any other routable IP = address of the PE be used? d) In the same scenario, is it required to use the IP address of the = replying PE used in the setup of the=20 Targeted LDP session as the source IP address of LSP-Ping Echo = replies, or can any other routable=20 IP address of the PE be used? 2. Sending a VCCV LSP-ping Echo Reply packet: a) RFC 4397 defines this packet as an UDP/IP packet b) When LSP-Ping is used with VCCV, is it required to send this = packet over the Associated Channel of the PW or can it be sent in any other way?=20 Regards, Sasha =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, June 02, 2006 9:50 PM To: i-d-announce@ietf.org Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-vccv-09.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge = Working Group of the IETF. Title : Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) Author(s) : T. Nadeau, et al. Filename : draft-ietf-pwe3-vccv-09.txt Pages : 24 Date : 2006-6-2 =09 This document describes Virtual Circuit Connection Verification (VCCV) procedures for use with pseudo wire (PW) connections. VCCV supports connection verification applications for PWs regardless of the underlying public service network technology. VCCV makes use of IP-based protocols to perform operations and maintenance functions. This is accomplished by providing a control channel associated with each PW. A network operator may use the VCCV procedures to test the network's forwarding plane liveliness. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-09.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-vccv-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-vccv-09.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C68727.51E26F4A Content-Type: application/octet-stream; name="ATT104271.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT104271.TXT Content-Disposition: attachment; filename="ATT104271.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi02LTIxMjM5NDguSS1EQGlldGYub3JnPg0KDQpFTkNP RElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1wd2UzLXZjY3YtMDku dHh0DQo= ------_=_NextPart_001_01C68727.51E26F4A Content-Type: application/octet-stream; name="draft-ietf-pwe3-vccv-09.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-pwe3-vccv-09.URL Content-Disposition: attachment; filename="draft-ietf-pwe3-vccv-09.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXB3ZTMtdmNjdi0wOS50eHQNCg== ------_=_NextPart_001_01C68727.51E26F4A Content-Type: text/plain; name="ATT104272.txt" Content-Transfer-Encoding: base64 Content-Description: ATT104272.txt Content-Disposition: attachment; filename="ATT104272.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnB3ZTMgbWFp bGluZyBsaXN0DQpwd2UzQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wd2UzDQo= ------_=_NextPart_001_01C68727.51E26F4A Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C68727.51E26F4A-- From pwe3-bounces@ietf.org Mon Jun 05 16:54:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnM5j-0002UQ-Kb; Mon, 05 Jun 2006 16:54:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnM5f-0002Ko-Dg; Mon, 05 Jun 2006 16:54:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnLZW-0002v1-1I; Mon, 05 Jun 2006 16:21:10 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FnLLB-0005XP-GW; Mon, 05 Jun 2006 16:06:22 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k55Jo1mU027127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FnL5N-0002Qs-OO; Mon, 05 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 05 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-sonet-13.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : SONET/SDH Circuit Emulation over Packet (CEP) Author(s) : A. Malis, et al. Filename : draft-ietf-pwe3-sonet-13.txt Pages : 53 Date : 2006-6-5 This document provides encapsulation formats and semantics for emulating SONET/SDH circuits and services over packet-switched networks, and MPLS networks in particular. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-sonet-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-sonet-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-5141219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-sonet-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-sonet-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-5141219.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Wed Jun 07 16:30:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4fQ-0002Wk-FD; Wed, 07 Jun 2006 16:30:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4fP-0002WA-AH for pwe3@ietf.org; Wed, 07 Jun 2006 16:30:15 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo4fO-0005bV-0B for pwe3@ietf.org; Wed, 07 Jun 2006 16:30:15 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2006 13:27:23 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="1821440830:sNHT2448320610" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k57KRLk4003664 for ; Wed, 7 Jun 2006 13:27:22 -0700 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k57KRLLf019257 for ; Wed, 7 Jun 2006 22:27:21 +0200 (MEST) Received: from [128.107.163.79] (dhcp-128-107-163-79.cisco.com [128.107.163.79]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA04156; Wed, 7 Jun 2006 21:27:20 +0100 (BST) Message-ID: <448736A6.3010500@cisco.com> Date: Wed, 07 Jun 2006 21:27:18 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=123; t=1149712042; x=1150576042; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:Stewart=20Bryant=20 |Subject:June=202006=09IETF=20PWE3=20WG=09ITU-T=20Study=20Group=2015=09Liaison=20 Response=3A=20on=0A=20T-MPLS=20of=20May=204=20and=20April=202=202006; X=v=3Dcisco.com=3B=20h=3D5GwdSYWoR+RK7gerKbTmZTGK+bY=3D; b=s3mFcfZA2YqHKUfs+Qo0F0VgWj1qU6B3lt+xkJh5zxuDLioK/vgWR5vQsG7QQ6093FFuCdBf mvCCI/6nSFwb2kEWuseFcZ377It+yAD9jTl4avuwfpgBg97jwIu/xFg3; Authentication-Results: sj-dkim-4.cisco.com; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [PWE3] June 2006 IETF PWE3 WG ITU-T Study Group 15 Liaison Response: on T-MPLS of May 4 and April 2 2006 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org ... has now found it's way to the IETF LS site - Stewart https://datatracker.ietf.org/documents/LIAISON/file323.txt _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jun 08 13:11:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoO2W-00076x-Vz; Thu, 08 Jun 2006 13:11:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoO2V-00076o-3w; Thu, 08 Jun 2006 13:11:23 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoO2U-0008Ee-Hu; Thu, 08 Jun 2006 13:11:23 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 08 Jun 2006 10:11:21 -0700 X-IronPort-AV: i="4.05,220,1146466800"; d="scan'208"; a="291551427:sNHT39764616" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k58HBLmw025401; Thu, 8 Jun 2006 10:11:21 -0700 Received: from [10.32.9.110] ([10.32.9.110]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k58HBIcL004380; Thu, 8 Jun 2006 10:11:18 -0700 (PDT) Message-ID: <4488591C.8090105@cisco.com> Date: Thu, 08 Jun 2006 18:06:36 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.jones@itu.int, tsbsg15@itu.int Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=6944; t=1149786681; x=1150650681; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:Stewart=20Bryant=20 |Subject:Follow=20up=20to=20PWE3=20WG=20response=20to=20your=20liaison=20on=20T-M PLS=20of=20May=204=0A=20and=20April=202=202006; X=v=3Dcisco.com=3B=20h=3D+V6q3zDMUEba1uIizGKHNxEsQWM=3D; b=dpdLCgO63r1REHwYFNMSipOhSPn6xeMEDKdTBejvRR8BrxYwxDpuMCbinu8I+TLI1bPsZKP/ e+WXyy6vdTLoVcTPfKx8MumwSeae/wdWJpE/8d64+24VdF9XyaWJXiOe; Authentication-Results: sj-dkim-8.cisco.com; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: swallow@cisco.com, sjtrowbridge@lucent.com, mark.jones@sprint.com, maeda@ansl.ntt.co.jp, mpls@ietf.org, pwe3@ietf.org, statements@ietf.org, sob@harvard.edu, townsley@cisco.com, danny@arbor.net, jari.arkko@piuha.net, Ghani.Abbas@marconi.com, betts01@nortel.com Subject: [PWE3] Follow up to PWE3 WG response to your liaison on T-MPLS of May 4 and April 2 2006 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org To: ITU-T Study Group 15 Greg Jones greg.jones@itu.int tsbsg15@itu.int Cc: IETF statements@ietf.org Stephen Trowbridge sjtrowbridge@lucent.com Ghani Abbas Ghani.Abbas@marconi.com Mark Jones mark.jones@sprint.com Malcolm Betts betts01@nortel.com Yoichi Maeda maeda@ansl.ntt.co.jp Scott Bradner Adrian Farrel Jari Arkko Mark Townsley Danny McPherson PWE3 mailing list George Swallow swallow@cisco.com Loa Andersson loa@pi.se MPLS mailing list From: IETF PWE3 Working Group Response contact: Stewart Bryant stbryant@cisco.com Technical contact: Stewart Bryant stbryant@cisco.com Purpose: Action Subject: Follow up to PWE3 WG response to your liaison on T-MPLS of May 4 and April 2 2006 The IETF PWE3 WG requests that it receives a copy of the formal response to the four issues raised by the IETF MPLS WG in their liaison response: https://datatracker.ietf.org/documents/LIAISON/file316.txt These issues were: 1. The requirements 2. The reserved labels 3. MPLS functionality equipment T-MPLS networks. 4. The IETF MPLS WG concern about what "future consideration for IP/MPLS clients" might entail. The IETF PWE3 WG additionally requests a formal response to the 13 issues that we raised in our liaison response: https://datatracker.ietf.org/documents/LIAISON/file323.txt For you convenience I append to this liaison the numerated list of issues raised by the IETF PWE3 WG. We would appreciate a response in time for us to discuss these matters at IETF66 which starts on 9th July 2006. Stewart Bryant IETF PWE3 Working Group Co-Chair ==================================== For your reference the enumerated list of IETF PWE3 WG issues is as follows: 1) G.8110.1 states: "The IETF PWE3 work group has developed an MPLS transport concept, know as pseudowires." Later G.8110.1 states: "The PSN can be implemented by utilizing a MPLS label switched network." PWE3 has developed methods of transporting services over many different PSNs, one of which is MPLS. 2) G.8110.1 states: "PWE3 is intended to provide only the minimum necessary functionality to emulate a wire with the required degree of faithfulness for the given service definition." The purpose behind the wording "provide only the minimum" was to prevent over engineering. In many cases, PWE3 provides more than just the minimum necessary functionality. We think that to put this quote from RFC3985 in it's proper context you should note that in our view an applicability statement MUST always be provided to clearly describe the extent of the emulation, and that in some cases more than one emulation method may be needed. 3) G.8110.1 states: "A four octet Control Word is added to the MPLS payload field for some encapsulations." The control word is DEFINED for all payload types. Use is optional for HDLC/PPP, Ethernet and some ATM modes, but is REQUIRED in all other cases. 4) G.8110.1 states: "these processes are called "Native Signal Processing (NSP)" NSP stands for Native Service Processing 5) G.8110.1 states: "The NSP function process the Control Word." The NSP does handle the flags (when there are flags defined). However the PW-layer processing handles the sequencing, FRG, etc. 6) G.8110.1 states: "IETF has defined pseudowire encapsulations for Ethernet, Frame Relay, ATM, PPP, PDH, and SDH." The PPP emulation also emulates HDLC, and the SDH design also supports SONET. We also have a design for Fibre- Channel and the IETF AVT WG has a design for header compressed voice samples. 7) G.8110.1 states: "The Forwarder function is called an Interworking Function (IWF)" It is not clear that IWF and forwarder are identical in scope and purpose. 8) G.8110.1 states: In Figure 9 Pseudowire Model G.8110.1 shows the PW as a trail with a T-MPLS trail termination function. This termination is defined here as injecting Y.1710 OAM. The IETF PWE3 specifications use VCCV as the PW OAM. 9) G.8110.1 states: "Pseudowires can be switched by a Subnetwork Connection (SNC). This creates in PWE3 terminology Multi-Segment Pseudowires (MS-PW) as defined in the bibliography reference [1]." Bibliography reference [1] is RFC 3985, which was published prior to our work on MS-PWs. The correct reference is reference [2]. 10) G.8110.1 states: "When the MPLS server layer is an SDH layer network, an SDH path layer may be used instead of the pseudowire PSN transport tunnel. This approach has been called "dry martini" as defined in the bibliography reference [2]." The correct reference is reference [3]. We must however caution you that this work has not been adopted as an IETF PWE3 working group item. The draft was an individual submission which has now expired under the IETF policy of expiring such drafts after six months. Within the scope material you state: "a T-MPLS network will not peer directly with an IP/MPLS network". The data plane behavior of the one currently supported adaptation ("EVC") is intended to be that of an Ethernet pseudowire as specified in Y.1415 and RFC4448. Thus it is possible for "IP/MPLS" and T-MPLS networks to interoperate at the level of the pseudowire, e.g. a multi-segment PW could span adjacent "IP/MPLS" and T-MPLS networks connected by an S-PE. 11) G.8110.1 states: "From an OAM perspective, pseudowires provide service-specific status and alarm management". However PW status signaling and VCCV are agnostic to the native service type. PWE3 members who are also SG13 experts make the following additional observations: 12) G.8110.1 states: "ITU SG 13 has developed a series of recommendations for MPLS / Client Network Interworking for Ethernet (Y.1415), ATM (Cell Mode - Y.1411), ATM (Frame Mode - Y.1412), and TDM (Y.1413). These recommendations are similar in concept to IETF PWE3." You omit X.84 (frame relay PW), which, although developed by SG17, it is now in SG13. These recommendations are are identical in concept, and to the best of the ability of those concerned are identical in detail. We note that in Figure 8 you pick the semi-formal diagram from Y.1415 when the same Recommendation has a G.805 diagram as well. We recommend that you show Figure 6-2 of Y.1415 in its place. 13) G.8110.1 states: "Pseudowires can be used as a packet transport mechanism for emulating LAN Services over a Transport MPLS network. Like in Virtual Private LAN Service (VPLS) a full mesh of T-MPLS trails (PW trails) is used to interconnect split-horizon ETH Flow Domains." We suggest that you reference Appendix I of Y.1415. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Jun 09 13:51:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fol9G-0003jC-VI; Fri, 09 Jun 2006 13:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fol9G-0003iy-8k for pwe3@ietf.org; Fri, 09 Jun 2006 13:51:54 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fol9E-0005Q1-PS for pwe3@ietf.org; Fri, 09 Jun 2006 13:51:54 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k59Hppl6011217 for ; Fri, 9 Jun 2006 13:51:51 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19242 for ; Fri, 9 Jun 2006 13:51:51 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Fri, 9 Jun 2006 13:51:50 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0CAD9721@whq-msgusr-02.pit.comms.marconi.com> From: "Aanand, Siddharth" To: "'pwe3@ietf.org'" Date: Fri, 9 Jun 2006 13:51:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [PWE3] Question regdg. ethernet pwe3 (rfc4448) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org All, In table 1 of section 4.4.1 (operations at ingress PE), for tagged mode dealing with service delimiting tags, the operations are listed as NO OP or Tag added. The "Tag Added" part leads me to believe that there could be case where a PE could receive a packet without any tags on an attachment circuit that was designated to send packets with service delimiting tags. Is this a correct assumption? If so, is it correct to say that the Raw Mode operations for Service Delimiting tags should be NOP or 1st VLAN tag removed. thanks, -Sidd Aanand _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sun Jun 11 09:32:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpQ3Y-00068Q-Fl; Sun, 11 Jun 2006 09:32:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpQ3X-00068D-7e for pwe3@ietf.org; Sun, 11 Jun 2006 09:32:43 -0400 Received: from corfw.corrigent.com ([213.31.203.2] helo=tlvmail1.corrigent.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpQ3V-0003xx-GZ for pwe3@ietf.org; Sun, 11 Jun 2006 09:32:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Jun 2006 16:32:36 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA08135774B0@tlvmail1.corrigent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pwe3-fc-encap-00.txt Thread-Index: AcaKTpvBtzJkBYRtRDWM2ZhJOpGbmQDBTK0w From: "Ronen Solomon" To: , , "Moran Roth" X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: Leon Bruckman , Luis Aguirre-Torres , rdipasquale@lucent.com, David.Peterson@mcdata.com, pwe3@ietf.org, danny@tcb.net, townsley@cisco.com Subject: [PWE3] RE: draft-ietf-pwe3-fc-encap-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org David,=20 I agree with your inputs. Additionally I would add to the IETF FCoMPLS draft the modification required for the transmitter throughout equation ( to be used in controlled and non-controlled environment i.e. CIR/EIR as described in the draft), and 'reciverNotReady' feedback. With respect to the feedback , LAPB uses the SR_SREJ (selective reject) indication to signal the transmitter on the lost frames. This is used similarly as a receiver-transmitter indication to allow the transmitter to adjust its throughout. The SR_REJ indication is an input to the transmitter throughout equation.=20 We shall have the FCoATM LABP indications (SR_SREJ , SR-RR and SR_RNR) documented in the FCoMPLS draft clearly with respect to throughput adjustment and TFRC for review.=20 Awaiting your inputs=20 Regards,=20 Ronen -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com]=20 Sent: Wednesday, June 07, 2006 5:22 PM To: Ronen Solomon; stbryant@cisco.com; Moran Roth Cc: danny@tcb.net; Luis Aguirre-Torres; rdipasquale@lucent.com; David.Peterson@mcdata.com; townsley@cisco.com; Black_David@emc.com Subject: RE: draft-ietf-pwe3-fc-encap-00.txt Ronen, > David/Mark , please have in your inputs whether we could proceed in=20 > this direction. Your inputs are much appreciated. While I'll have to look at other aspects in more detail, based on slide 3, my immediate reaction is that the order of the SR (selective retransmission - proposed for T11 standardization) and RS (Rate Shaping - proposed for IETF standardization) components is backwards because the rate shaping is shown upstream of the retransmission. The result cannot be TFRC-compliant because TFRC controls the entire sending rate, including retransmissions. A mechanism that retransmits in response to loss without regard to the congestion consequences of doing so has the effect of increasing the rate of traffic in response to indications of congestion, which is not the proverbial "right thing" to do. Among the important consequences of this is that under TFRC, the fact that a packet has been transmitted does not grant an unfettered right to retransmit it until its reception is acknowledged. At a minimum, to reuse the T11 FCoATM SR mechanism, it will be necessary to document the following in the IETF draft: - How the SR mechanism carries the receiver-to-sender information required by TFRC. - How the combination of SR and RS mechanisms deals with loss of feedback information (cf. Section 4.4 of RFC 3448). I would also observe that a retransmission protocol designed for a fixed- bandwidth mostly-reliable virtual circuit (where losses are indication of link quality issues, not network congestion) may not be appropriate for a variable-bandwidth pseudo-wire on which losses need to be viewed as indicators of possible network congestion. =20 I will look at the slides and current draft in more detail as time permits over the next few weeks. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Ronen Solomon [mailto:RonenS@corrigent.com] > Sent: Wednesday, June 07, 2006 6:43 AM > To: Stewart Bryant; Moran Roth; Black, David > Cc: Danny McPherson; Luis Aguirre-Torres; Ronen Solomon;=20 > rdipasquale@lucent.com; David.Peterson@mcdata.com; townsley@cisco.com > Subject: RE: draft-ietf-pwe3-fc-encap-00.txt >=20 > Stewart >=20 > Following the last T.11 meeting where the NSP function of the FCoMPLS=20 > has been proposed it was suggested by David Black that the bandwidth=20 > congestion management (i.e. Selective retransmission and rate shaping) > would be part of the IETF work. Currently the FCoMPLs draft includes=20 > an applicability section that described the requirement of the network > in terms of delay and QoS , while the bandwidth congestion management=20 > is part of the NSP. >=20 > Moran and I however adopted the FCoATM-VC congestion control SR=20 > mechanism already standardized by the T.11 which similarly defines the > efficient selective re-transmission (SR) and therefore propose to have > RT ( Rate shaping) adopted by the IETF ,while preserving the SR from=20 > the > T.11 with a clear interworking. Note that the SR as defined for=20 > FCoATM by T.11 has already been optimized to assure the need of the=20 > fiber channel transmission over virtual circuit such as overhead and=20 > round trip effectiveness and therefore can be similarly implemented by > FCoMPLS. The Rate shaping, on the other hand, could be implemented=20 > according to the IETF standard while defining the exact interworking=20 > the SR and RS. >=20 > We would like to discuses this direction at the next IETF to have a=20 > constant view and direction among all. >=20 > David/Mark , please have in your inputs whether we could proceed in=20 > this direction. Your inputs are much appreciated. >=20 > Regards, >=20 > Ronen >=20 > I have also CC'd the FC-BB chair and editor.=20 >=20 >=20 > FYI >=20 > FC-BB-4 Ad Hoc Group Meeting Report > Santa Fe, NM; 6th April, 2006 (06-334v0) >=20 > "Moran Roth (Corrigent) presented contribution 06-022v1 which is a=20 > follow up to the initial contribution into the previous meeting and=20 > attempts to address issues raised earlier. Discussions centered on the > previous assessment that a clear demarcation is needed between the=20 > functionalities falling within the scope of T11 and IETF. The IETF is=20 > responsible for specifying the PSN, PW label and CW. A number of=20 > issues were identified. >=20 > Regarding congestion control, it was agreed that SR (Selective > Retransmission) and RS (Rate Shaping) must interwork properly. There=20 > is a need to understand the exact relationship between the RS and SR=20 > mechanisms and also the scope of T11 and IETF (PWE3) responsibilities. > Dave Black informed the meeting about two related RFCs which need to=20 > be taken into account: RFC 2914 (Congestion Control Principles) and=20 > RFC > 3448 (TRCP - TCP-friendly rate control protocol). The initial view of=20 > the meeting was that the two functions (SR and RS) fall into the remit > of IETF. Thus congestion control is being handled in IETF and we need=20 > to be consistent with the relevant RFCs. The intent is to be=20 > consistent or compliant with these RFCs. Given this, it was decided=20 > that SR and RS need to be removed from the scope (and text) of=20 > FC-BB-4. The editor was actioned to examine this and make a proposal for the next meeting." >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Thursday, June 01, 2006 1:56 PM > To: Moran Roth; Ronen Solomon > Cc: Danny McPherson > Subject: draft-ietf-pwe3-fc-encap-00.txt >=20 > Is draft-ietf-pwe3-fc-encap-00.txt ready for cross area review yet? >=20 > BTW you will need to provide an email for Munefumi Tsurusawa as when=20 > this goes to RFC he will need to sign-off on the 48hr review. >=20 > Regards >=20 > Stewart >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jun 12 04:25:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fphjx-0006Im-D8; Mon, 12 Jun 2006 04:25:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fphjw-0006Ih-PD for pwe3@ietf.org; Mon, 12 Jun 2006 04:25:40 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fphjr-0003wy-Sm for pwe3@ietf.org; Mon, 12 Jun 2006 04:25:40 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jun 2006 09:25:34 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 09:25:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] RE: draft-ietf-pwe3-fc-encap-00.txt Date: Mon, 12 Jun 2006 09:25:30 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389169775A8@i2km07-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] RE: draft-ietf-pwe3-fc-encap-00.txt Thread-Index: AcaKTpvBtzJkBYRtRDWM2ZhJOpGbmQDBTK0wACfgQIA= From: To: , , , X-OriginalArrivalTime: 12 Jun 2006 08:25:32.0526 (UTC) FILETIME=[C56CE8E0:01C68DF9] X-Spam-Score: 0.3 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Cc: rdipasquale@lucent.com, Luis@Corrigent.com, leonb@corrigent.com, David.Peterson@mcdata.com, pwe3@ietf.org, danny@tcb.net, townsley@cisco.com X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Ronen Soloman agreed with this remark from David Black: > I would also observe that a retransmission protocol designed for a > fixed- bandwidth mostly-reliable virtual circuit (where=20 > losses are indication of link quality issues, not network=20 > congestion) may not be appropriate for a variable-bandwidth=20 > pseudo-wire on which losses need to be viewed as indicators=20 > of possible network congestion. There are some key architectural reasons why the above observation is both correct and important. These stem from the fact that in a correctly architected co-cs or co-ps mode layer network technology we have this object called a 'connection' (see G.805 func arch for definition). A connection MUST have these properties: - single source - connectivity =3D 1 This means ONLY p2p and p2mp connections are allowed in a properly architected co-cs or co-ps mode layer network. Further, because of the nature of labelling in the co-cs mode it is NOT POSSIBLE to violate the above connection properties. However, one can violate these properties in the co-ps mode...indeed both LDP mp2p LSPs and the action of PHP in MPLS cause a merging behaviour which violates the required connection property of a single source. This requires a higher layer entity to effect the demerging....and in the case of MPLS (and when the client is NOT IP) this requires the running of a p2p PW entity (see Note) ABOVE MPLS. Note - If the PW is precisely 1 hop then the PW entity is simply an adaptation function, ie it is NOT a networked entity per se. If however the PW is > 1 hop then a new PW layer network is created, and the PW entity is a new PW connection in this new co-ps PW layer network, ie it is now a networked entity. This is a major step-change in behaviour please note. Moreover, also carefully note that because of the merging behaviour in LDP/PHP then MPLS labels do NOT have consistent semantics at all levels. This can have some 'interesting implications' if defects cause labelled MPLS PDUs at different levels to become misconnected. Note also that in a properly architected co-cs or co-ps mode layer network then once a connection has been established then all routing choice is removed from that connection. A key corollary of this is that any new nodes or links that are added to a properly architected co-cs or co-ps mode layer network DO NOT affect ALREADY ESTABLISHED connections. This is a critical requirement in co-cs and co-ps mode layer networks to ensure deterministic traffic behaviour. This requirement is not satisfied however in cl-ps mode layer networks (eg IP and native ethernet) nor MPLS LDP since this also tracks the SPF behaviour of the IGP. All these factors mean that the deterministic traffic/fault/performance behaviour one gets from a properly architected co-cs or co-ps mode layer network is NOT possible in MPLS as-is. So I would say we can state far stronger architectural reasons why what David Black originally observed is correct. regards, Neil > -----Original Message----- > From: Ronen Solomon [mailto:RonenS@corrigent.com]=20 > Sent: 11 June 2006 15:33 > To: Black_David@emc.com; stbryant@cisco.com; Moran Roth > Cc: Leon Bruckman; Luis Aguirre-Torres;=20 > rdipasquale@lucent.com; David.Peterson@mcdata.com;=20 > pwe3@ietf.org; danny@tcb.net; townsley@cisco.com > Subject: [PWE3] RE: draft-ietf-pwe3-fc-encap-00.txt >=20 >=20 > David,=20 >=20 > I agree with your inputs. Additionally I would add to the=20 > IETF FCoMPLS draft the modification required for the=20 > transmitter throughout equation ( to be used in controlled=20 > and non-controlled environment i.e. CIR/EIR as described in=20 > the draft), and 'reciverNotReady' feedback. With respect to=20 > the feedback , LAPB uses the SR_SREJ (selective reject)=20 > indication to signal the transmitter on the lost frames. This=20 > is used similarly as a receiver-transmitter indication to=20 > allow the transmitter to adjust its throughout. The SR_REJ=20 > indication is an input to the transmitter throughout equation.=20 >=20 > We shall have the FCoATM LABP indications (SR_SREJ , SR-RR=20 > and SR_RNR) documented in the FCoMPLS draft clearly with=20 > respect to throughput adjustment and TFRC for review.=20 >=20 > Awaiting your inputs=20 >=20 > Regards,=20 >=20 > Ronen >=20 > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com]=20 > Sent: Wednesday, June 07, 2006 5:22 PM > To: Ronen Solomon; stbryant@cisco.com; Moran Roth > Cc: danny@tcb.net; Luis Aguirre-Torres;=20 > rdipasquale@lucent.com; David.Peterson@mcdata.com;=20 > townsley@cisco.com; Black_David@emc.com > Subject: RE: draft-ietf-pwe3-fc-encap-00.txt >=20 > Ronen, >=20 > > David/Mark , please have in your inputs whether we could proceed in > > this direction. Your inputs are much appreciated. >=20 > While I'll have to look at other aspects in more detail,=20 > based on slide 3, my immediate reaction is that the order of=20 > the SR (selective retransmission > - proposed for T11 standardization) and RS (Rate Shaping -=20 > proposed for IETF standardization) components is backwards=20 > because the rate shaping is shown upstream of the=20 > retransmission. The result cannot be TFRC-compliant because=20 > TFRC controls the entire sending rate, including=20 > retransmissions. A mechanism that retransmits in response to=20 > loss without regard to the congestion consequences of doing=20 > so has the effect of increasing the rate of traffic in=20 > response to indications of congestion, which is not the=20 > proverbial "right thing" to do. Among the important=20 > consequences of this is that under TFRC, the fact that a=20 > packet has been transmitted does not grant an unfettered=20 > right to retransmit it until its reception is acknowledged. >=20 > At a minimum, to reuse the T11 FCoATM SR mechanism, it will=20 > be necessary to document the following in the IETF draft: > - How the SR mechanism carries the receiver-to-sender=20 > information required > by TFRC. > - How the combination of SR and RS mechanisms deals with loss=20 > of feedback > information (cf. Section 4.4 of RFC 3448). >=20 > I would also observe that a retransmission protocol designed for a > fixed- bandwidth mostly-reliable virtual circuit (where=20 > losses are indication of link quality issues, not network=20 > congestion) may not be appropriate for a variable-bandwidth=20 > pseudo-wire on which losses need to be viewed as indicators=20 > of possible network congestion. =20 >=20 > I will look at the slides and current draft in more detail as=20 > time permits over the next few weeks. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > > -----Original Message----- > > From: Ronen Solomon [mailto:RonenS@corrigent.com] > > Sent: Wednesday, June 07, 2006 6:43 AM > > To: Stewart Bryant; Moran Roth; Black, David > > Cc: Danny McPherson; Luis Aguirre-Torres; Ronen Solomon; > > rdipasquale@lucent.com; David.Peterson@mcdata.com;=20 > townsley@cisco.com > > Subject: RE: draft-ietf-pwe3-fc-encap-00.txt > >=20 > > Stewart > >=20 > > Following the last T.11 meeting where the NSP function of=20 > the FCoMPLS > > has been proposed it was suggested by David Black that the=20 > bandwidth=20 > > congestion management (i.e. Selective retransmission and=20 > rate shaping) >=20 > > would be part of the IETF work. Currently the FCoMPLs draft includes > > an applicability section that described the requirement of=20 > the network >=20 > > in terms of delay and QoS , while the bandwidth congestion=20 > management > > is part of the NSP. > >=20 > > Moran and I however adopted the FCoATM-VC congestion control SR > > mechanism already standardized by the T.11 which similarly=20 > defines the >=20 > > efficient selective re-transmission (SR) and therefore=20 > propose to have >=20 > > RT ( Rate shaping) adopted by the IETF ,while preserving the SR from > > the > > T.11 with a clear interworking. Note that the SR as defined for=20 > > FCoATM by T.11 has already been optimized to assure the need of the=20 > > fiber channel transmission over virtual circuit such as=20 > overhead and=20 > > round trip effectiveness and therefore can be similarly=20 > implemented by >=20 > > FCoMPLS. The Rate shaping, on the other hand, could be implemented > > according to the IETF standard while defining the exact=20 > interworking=20 > > the SR and RS. > >=20 > > We would like to discuses this direction at the next IETF to have a > > constant view and direction among all. > >=20 > > David/Mark , please have in your inputs whether we could proceed in > > this direction. Your inputs are much appreciated. > >=20 > > Regards, > >=20 > > Ronen > >=20 > > I have also CC'd the FC-BB chair and editor. > >=20 > >=20 > > FYI > >=20 > > FC-BB-4 Ad Hoc Group Meeting Report > > Santa Fe, NM; 6th April, 2006 (06-334v0) > >=20 > > "Moran Roth (Corrigent) presented contribution 06-022v1 which is a > > follow up to the initial contribution into the previous meeting and=20 > > attempts to address issues raised earlier. Discussions=20 > centered on the >=20 > > previous assessment that a clear demarcation is needed between the > > functionalities falling within the scope of T11 and IETF.=20 > The IETF is=20 > > responsible for specifying the PSN, PW label and CW. A number of=20 > > issues were identified. > >=20 > > Regarding congestion control, it was agreed that SR (Selective > > Retransmission) and RS (Rate Shaping) must interwork properly. There > > is a need to understand the exact relationship between the=20 > RS and SR=20 > > mechanisms and also the scope of T11 and IETF (PWE3)=20 > responsibilities. > > Dave Black informed the meeting about two related RFCs=20 > which need to=20 > > be taken into account: RFC 2914 (Congestion Control Principles) and=20 > > RFC > > 3448 (TRCP - TCP-friendly rate control protocol). The=20 > initial view of=20 > > the meeting was that the two functions (SR and RS) fall=20 > into the remit >=20 > > of IETF. Thus congestion control is being handled in IETF=20 > and we need > > to be consistent with the relevant RFCs. The intent is to be=20 > > consistent or compliant with these RFCs. Given this, it was decided=20 > > that SR and RS need to be removed from the scope (and text) of=20 > > FC-BB-4. The editor was actioned to examine this and make a proposal > for the next meeting." > >=20 > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Stewart Bryant [mailto:stbryant@cisco.com] > > Sent: Thursday, June 01, 2006 1:56 PM > > To: Moran Roth; Ronen Solomon > > Cc: Danny McPherson > > Subject: draft-ietf-pwe3-fc-encap-00.txt > >=20 > > Is draft-ietf-pwe3-fc-encap-00.txt ready for cross area review yet? > >=20 > > BTW you will need to provide an email for Munefumi Tsurusawa as when > > this goes to RFC he will need to sign-off on the 48hr review. > >=20 > > Regards > >=20 > > Stewart > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jun 12 15:49:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpsPm-0006zm-Sn; Mon, 12 Jun 2006 15:49:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpsPl-0006zh-6g for pwe3@ietf.org; Mon, 12 Jun 2006 15:49:33 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpsPh-0005lv-US for pwe3@ietf.org; Mon, 12 Jun 2006 15:49:33 -0400 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id CBBC6644B2 for ; Mon, 12 Jun 2006 13:49:24 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: pwe3 pwe3 From: Danny McPherson Date: Mon, 12 Jun 2006 13:49:30 -0600 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [PWE3] IETF 66 Important Dates X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org FYI... June 12, Monday - Working Group Chair approval for initial document (Version -00) submissions appreciated by 09:00 ET (13:00 UTC/GMT) June 19, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (13:00 UTC/GMT) June 26, Monday - Internet Draft final submission cut-off by 09:00 ET (13:00 UTC/GMT) Additional important dates available here: http://www.ietf.org/meetings/cutoff_dates_66.html Please get Stewart, Matthew and I your requests for slots at the upcoming meeting ASAP - only a couple received to date. Thanks! -danny _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jun 15 14:18:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqwQ8-0002g3-Li; Thu, 15 Jun 2006 14:18:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqwQ7-0002fp-Lx for pwe3@ietf.org; Thu, 15 Jun 2006 14:18:19 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqwQ7-0002tS-5v for pwe3@ietf.org; Thu, 15 Jun 2006 14:18:19 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k5FII2XN029041; Thu, 15 Jun 2006 14:18:02 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5FIHEIk006639; Thu, 15 Jun 2006 14:17:45 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Jun 2006 14:16:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Jun 2006 14:16:58 -0400 Message-ID: In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08135774B0@tlvmail1.corrigent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pwe3-fc-encap-00.txt Thread-Index: AcaKTpvBtzJkBYRtRDWM2ZhJOpGbmQDBTK0wANRTC+A= To: , X-OriginalArrivalTime: 15 Jun 2006 18:16:59.0049 (UTC) FILETIME=[E447D990:01C690A7] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.6.15.105433 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: rdipasquale@lucent.com, pwe3@ietf.org, leonb@corrigent.com Subject: [PWE3] RE: draft-ietf-pwe3-fc-encap-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Ronen, > Awaiting your inputs=20 Here's the next round of input on this. The T11.3 FC-BB-4 working group is responsible for standardization of the Fibre Channel aspects of the Fibre Channel pseudo-wire. In my role as (what passes for) liaison between T11 and IETF, I can report that the FC-BB-4 working group just met this morning (in Anchorage, Alaska, where it's still morning), and has essentially reiterated its conclusions on SR (Selective Retransmit) and RS (Rate Shaping) from prior discussion (in April) as reported below: > > The initial view of the [April] meeting was that the two functions > > (SR and RS) fall into the remit > > of IETF. Thus congestion control is being handled in IETF and we need=20 > > to be consistent with the relevant RFCs. The intent is to be=20 > > consistent or compliant with these RFCs. Given this, it was decided=20 > > that SR and RS need to be removed from the scope (and text) of=20 > > FC-BB-4. The current status is that FC-BB-4 believes that SR and RS should be specified together, and specified by IETF since TCP-friendliness (traffic behavior in response to congestion) is considered to be important. SR has been removed from the FC-BB-4 working draft as the protocols that use SR (e.g., FCoATM) are considered mature and will not be further revised. The existing FC-BB-3 SR text probably needs attention if it is to be reused. There should be no problem in importing that SR text into an IETF draft, but referencing it in its existing form in the FC-BB-3 standard is not a recommended approach. It is also important that Corrigent attend the next BB-4 meeting in Calgary in August in order to make progress on the FC aspects of the pseudo-wire. I will take a look at the current FC PW draft and comment on it in a separate message. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Ronen Solomon [mailto:RonenS@corrigent.com]=20 > Sent: Sunday, June 11, 2006 10:33 AM > To: Black, David; stbryant@cisco.com; Moran Roth > Cc: danny@tcb.net; Luis Aguirre-Torres;=20 > rdipasquale@lucent.com; David.Peterson@mcdata.com;=20 > townsley@cisco.com; pwe3@ietf.org; Leon Bruckman > Subject: RE: draft-ietf-pwe3-fc-encap-00.txt >=20 > David,=20 >=20 > I agree with your inputs. Additionally I would add to the IETF FCoMPLS > draft the modification required for the transmitter throughout equation > ( to be used in controlled and non-controlled environment i.e. CIR/EIR > as described in the draft), and 'reciverNotReady' feedback. With respect > to the feedback , LAPB uses the SR_SREJ (selective reject) indication to > signal the transmitter on the lost frames. This is used similarly as a > receiver-transmitter indication to allow the transmitter to adjust its > throughout. The SR_REJ indication is an input to the transmitter > throughout equation.=20 >=20 > We shall have the FCoATM LABP indications (SR_SREJ , SR-RR and SR_RNR) > documented in the FCoMPLS draft clearly with respect to throughput > adjustment and TFRC for review.=20 >=20 > Awaiting your inputs=20 >=20 > Regards,=20 >=20 > Ronen >=20 > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com]=20 > Sent: Wednesday, June 07, 2006 5:22 PM > To: Ronen Solomon; stbryant@cisco.com; Moran Roth > Cc: danny@tcb.net; Luis Aguirre-Torres; rdipasquale@lucent.com; > David.Peterson@mcdata.com; townsley@cisco.com; Black_David@emc.com > Subject: RE: draft-ietf-pwe3-fc-encap-00.txt >=20 > Ronen, >=20 > > David/Mark , please have in your inputs whether we could proceed in > > this direction. Your inputs are much appreciated. >=20 > While I'll have to look at other aspects in more detail, based on slide > 3, my immediate reaction is that the order of the SR (selective retransmission > - proposed for T11 standardization) and RS (Rate Shaping - proposed for > IETF standardization) components is backwards because the rate shaping > is shown upstream of the retransmission. The result cannot be > TFRC-compliant because TFRC controls the entire sending rate, including > retransmissions. > A mechanism that retransmits in response to loss without regard to the > congestion consequences of doing so has the effect of increasing the > rate of traffic in response to indications of congestion, which is not > the proverbial "right thing" to do. Among the important consequences of > this is that under TFRC, the fact that a packet has been transmitted > does not grant an unfettered right to retransmit it until its reception > is acknowledged. >=20 > At a minimum, to reuse the T11 FCoATM SR mechanism, it will be necessary > to document the following in the IETF draft: > - How the SR mechanism carries the receiver-to-sender information required > by TFRC. > - How the combination of SR and RS mechanisms deals with loss of feedback > information (cf. Section 4.4 of RFC 3448). >=20 > I would also observe that a retransmission protocol designed for a > fixed- bandwidth mostly-reliable virtual circuit (where losses are > indication of link quality issues, not network congestion) may not be > appropriate for a variable-bandwidth pseudo-wire on which losses need to > be viewed as indicators of possible network congestion. =20 >=20 > I will look at the slides and current draft in more detail as time > permits over the next few weeks. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > > -----Original Message----- > > From: Ronen Solomon [mailto:RonenS@corrigent.com] > > Sent: Wednesday, June 07, 2006 6:43 AM > > To: Stewart Bryant; Moran Roth; Black, David > > Cc: Danny McPherson; Luis Aguirre-Torres; Ronen Solomon;=20 > > rdipasquale@lucent.com; David.Peterson@mcdata.com; townsley@cisco.com > > Subject: RE: draft-ietf-pwe3-fc-encap-00.txt > >=20 > > Stewart > >=20 > > Following the last T.11 meeting where the NSP function of the FCoMPLS=20 > > has been proposed it was suggested by David Black that the bandwidth > > congestion management (i.e. Selective retransmission and rate shaping) > > would be part of the IETF work. Currently the FCoMPLs draft includes > > an applicability section that described the requirement of the network > > in terms of delay and QoS , while the bandwidth congestion management=20 > > is part of the NSP. > >=20 > > Moran and I however adopted the FCoATM-VC congestion control SR=20 > > mechanism already standardized by the T.11 which similarly defines the > > efficient selective re-transmission (SR) and therefore propose to have > > RT ( Rate shaping) adopted by the IETF ,while preserving the SR from the > > T.11 with a clear interworking. Note that the SR as defined for=20 > > FCoATM by T.11 has already been optimized to assure the need of the=20 > > fiber channel transmission over virtual circuit such as overhead and > > round trip effectiveness and therefore can be similarly implemented by > > FCoMPLS. The Rate shaping, on the other hand, could be implemented=20 > > according to the IETF standard while defining the exact interworking > > the SR and RS. > >=20 > > We would like to discuses this direction at the next IETF to have a=20 > > constant view and direction among all. > >=20 > > David/Mark , please have in your inputs whether we could proceed in > > this direction. Your inputs are much appreciated. > >=20 > > Regards, > >=20 > > Ronen > >=20 > > I have also CC'd the FC-BB chair and editor.=20 > >=20 > >=20 > > FYI > >=20 > > FC-BB-4 Ad Hoc Group Meeting Report > > Santa Fe, NM; 6th April, 2006 (06-334v0) > >=20 > > "Moran Roth (Corrigent) presented contribution 06-022v1 which is a=20 > > follow up to the initial contribution into the previous meeting and=20 > > attempts to address issues raised earlier. Discussions centered on the > > previous assessment that a clear demarcation is needed between the=20 > > functionalities falling within the scope of T11 and IETF. The IETF is=20 > > responsible for specifying the PSN, PW label and CW. A number of=20 > > issues were identified. > >=20 > > Regarding congestion control, it was agreed that SR (Selective > > Retransmission) and RS (Rate Shaping) must interwork properly. There > > is a need to understand the exact relationship between the RS and SR > > mechanisms and also the scope of T11 and IETF (PWE3) responsibilities. > > Dave Black informed the meeting about two related RFCs which need to > > be taken into account: RFC 2914 (Congestion Control Principles) and RFC > > 3448 (TRCP - TCP-friendly rate control protocol). The initial view of=20 > > the meeting was that the two functions (SR and RS) fall into the remit > > of IETF. Thus congestion control is being handled in IETF and we need=20 > > to be consistent with the relevant RFCs. The intent is to be=20 > > consistent or compliant with these RFCs. Given this, it was decided=20 > > that SR and RS need to be removed from the scope (and text) of=20 > > FC-BB-4. The editor was actioned to examine this and make a proposal > > for the next meeting." > >=20 > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Stewart Bryant [mailto:stbryant@cisco.com] > > Sent: Thursday, June 01, 2006 1:56 PM > > To: Moran Roth; Ronen Solomon > > Cc: Danny McPherson > > Subject: draft-ietf-pwe3-fc-encap-00.txt > >=20 > > Is draft-ietf-pwe3-fc-encap-00.txt ready for cross area review yet? > >=20 > > BTW you will need to provide an email for Munefumi Tsurusawa as when > > this goes to RFC he will need to sign-off on the 48hr review. > >=20 > > Regards > >=20 > > Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jun 15 20:42:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr2Q1-0008ID-Cs; Thu, 15 Jun 2006 20:42:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr2Px-000894-75; Thu, 15 Jun 2006 20:42:33 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr2Pv-0002Ka-Nw; Thu, 15 Jun 2006 20:42:33 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k5G0gVCj012648; Thu, 15 Jun 2006 17:42:31 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k5G0gVCa012647; Thu, 15 Jun 2006 17:42:31 -0700 Date: Thu, 15 Jun 2006 17:42:31 -0700 Message-Id: <200606160042.k5G0gVCa012647@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: pwe3@ietf.org, rfc-editor@rfc-editor.org Subject: [PWE3] RFC 4553 on Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4553 Title: Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) Author: A. Vainshtein, Ed., YJ. Stein, Ed. Status: Standards Track Date: June 2006 Mailbox: sasha@axerra.com, yaakov_s@rad.com Pages: 27 Characters: 58141 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pwe3-satop-05.txt URL: http://www.rfc-editor.org/rfc/rfc4553.txt This document describes a pseudowire encapsulation for Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing. [STANDARDS TRACK] This document is a product of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jun 19 08:21:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIkb-0007rj-Ld; Mon, 19 Jun 2006 08:21:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsIka-0007re-Fc for pwe3@ietf.org; Mon, 19 Jun 2006 08:21:04 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsIkZ-0002Ay-2N for pwe3@ietf.org; Mon, 19 Jun 2006 08:21:04 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5JCHIPT002242 for ; Mon, 19 Jun 2006 08:17:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] draft-ietf-pwe3-ms-pw-requirements-02.txt - last call Date: Mon, 19 Jun 2006 15:21:01 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] draft-ietf-pwe3-ms-pw-requirements-02.txt - last call Thread-Index: AcaFleQgwmm/nvvnTc2/bC1gWwa5kAOA9ubQ From: "Romascanu, Dan \(Dan\)" To: "Stewart Bryant" , "pwe3" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Danny McPherson X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I would like to get clarification wrt. to a couple of management functions that seem to be missing in the document. The management functionality described in the WG charter by the following paragraph: > Specify the control and management functions of chartered PW types, to include PW setup, configuration, maintenance and tear-down. The PWE3 WG will do this in its entirety for MPLS PSNs, and the L2TPEXT WG will develop the L2TP specifics for L2TPv3-based PWs. 1. While there is quire detailed information and supplemental requirements about setup, configuration and tear-down, I cannot find anything in the requirements document concerning MS PWs tear-down=20 2. I expected to find some information and specific requirements plus security considerations about manageability of multi-segment PWs. Management of multiple domains imposes supplemental access and authentication requirements, maybe supplemental MIB objects, or access restrictions of MIB views containing information pertaining to other domains.=20 Dan =20 =20 > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com]=20 > Sent: Thursday, June 01, 2006 7:10 PM > To: pwe3 > Cc: Danny McPherson > Subject: [PWE3] draft-ietf-pwe3-ms-pw-requirements-02.txt - last call >=20 > This is the start of last call on >=20 > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-requ > irements-02.txt >=20 > Last call will end 19th June 2006. >=20 > Please read the draft. We need to finish with this before we=20 > can move forward on the MS protocol drafts. >=20 > Thanks >=20 > Stewart >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jun 20 09:33:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsgMU-0006U7-Ig; Tue, 20 Jun 2006 09:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsgMT-0006Qb-6a for pwe3@ietf.org; Tue, 20 Jun 2006 09:33:45 -0400 Received: from corfw.corrigent.com ([213.31.203.2] helo=tlvmail1.corrigent.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsgMR-0004xP-Rw for pwe3@ietf.org; Tue, 20 Jun 2006 09:33:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jun 2006 16:33:41 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA08134E8A07@tlvmail1.corrigent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about implementation of PW-ENET-STD-MIB Thread-Index: AcaUdoZeCQLo8rjbTTmnM69MEWHqQg== From: "David Zelig" To: "pwe3" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [PWE3] Question about implementation of PW-ENET-STD-MIB X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1729099084==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1729099084== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69476.86A82FCB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69476.86A82FCB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I am wondering if someone implemented (or plan to) the pwEnetMplsPriMappingTable in PW-ENET-STD-MIB - we would like to remove it from the MIB module. =20 Thanks David ------_=_NextPart_001_01C69476.86A82FCB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
I am = wondering if=20 someone implemented (or plan to) the pwEnetMplsPriMappingTable = in=20 PW-ENET-STD-MIB - we would like to remove it from the MIB = module.
 
Thanks
David
------_=_NextPart_001_01C69476.86A82FCB-- --===============1729099084== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1729099084==-- From pwe3-bounces@ietf.org Tue Jun 20 12:32:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsj92-000592-Ut; Tue, 20 Jun 2006 12:32:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsj92-00058s-2R for pwe3@ietf.org; Tue, 20 Jun 2006 12:32:04 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsj90-0003h6-Kf for pwe3@ietf.org; Tue, 20 Jun 2006 12:32:04 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-3.cisco.com with ESMTP; 20 Jun 2006 09:32:02 -0700 X-IronPort-AV: i="4.06,156,1149490800"; d="scan'208,217"; a="431045249:sNHT43453384" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5KGW1mO006479; Tue, 20 Jun 2006 09:32:01 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5KGW0Is029042; Tue, 20 Jun 2006 09:32:00 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 09:32:00 -0700 Received: from [128.107.161.149] ([128.107.161.149]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Jun 2006 09:31:59 -0700 In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08134E8A07@tlvmail1.corrigent.com> References: <44F4E579A764584EA9BDFD07D0CA08134E8A07@tlvmail1.corrigent.com> Mime-Version: 1.0 (Apple Message framework v750) Message-Id: <4134E0DC-B11C-4CA5-933C-9EFB81148606@cisco.com> From: "Thomas D. Nadeau" Subject: Re: [PWE3] Question about implementation of PW-ENET-STD-MIB Date: Tue, 20 Jun 2006 09:32:01 -0700 To: David Zelig X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 20 Jun 2006 16:31:59.0978 (UTC) FILETIME=[0DCEA4A0:01C69487] DKIM-Signature: a=rsa-sha1; q=dns; l=2671; t=1150821121; x=1151685121; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=22Thomas=20D.=20Nadeau=22=20 |Subject:Re=3A=20[PWE3]=20Question=20about=20implementation=20of=20PW-ENET-STD-MI B; X=v=3Dcisco.com=3B=20h=3DxyDNYI0hpdMyt3S66C0fbgUwUsc=3D; b=Qs010pNXvtaZmW2lkE/gY5Uv5H/MvE5zUGWt2pQU2bHsf3kYg1orAqbY9cdU/dGs0/0fcbaP tg1QFdHyGEUp+HEzuOCktaV6h5ElD9eKn9IlaBvesROXODH431Rds1kl; Authentication-Results: sj-dkim-8.cisco.com; header.From=tnadeau@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: pwe3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0665799646==" Errors-To: pwe3-bounces@ietf.org --===============0665799646== Content-Type: multipart/alternative; boundary=Apple-Mail-11-715229739 --Apple-Mail-11-715229739 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed We did not implement it, so I am okay with scraping it. --tom > All, > I am wondering if someone implemented (or plan to) the > pwEnetMplsPriMappingTable in PW-ENET-STD-MIB - we would like to > remove it from the MIB module. > > Thanks > David > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 --Apple-Mail-11-715229739 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

We did not implement it, so I am = okay with scraping it.

= --tom



=
All,
I am = wondering if someone=A0implemented=A0(or plan to) the = pwEnetMplsPriMappingTable in PW-ENET-STD-MIB - we would = like to remove it from the MIB module.
=A0
Thanks
David
pwe3 mailing list
=

= --Apple-Mail-11-715229739-- --===============0665799646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0665799646==-- From pwe3-bounces@ietf.org Wed Jun 21 20:38:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDDc-0007WT-39; Wed, 21 Jun 2006 20:38:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDDa-0007WO-Uf for pwe3@ietf.org; Wed, 21 Jun 2006 20:38:46 -0400 Received: from division.aa.arbor.net ([152.160.38.65] helo=gott.aa.arbor.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtDDZ-0002wt-I9 for pwe3@ietf.org; Wed, 21 Jun 2006 20:38:46 -0400 Received: from [205.168.100.52] (unknown [10.0.12.129]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by gott.aa.arbor.net (Postfix) with ESMTP id 67597144A8 for ; Wed, 21 Jun 2006 20:38:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v750) References: <200606160042.k5G0gVCa012647@nit.isi.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4F5DD3B3-31FC-4956-B2A6-F3FAB96DCC1E@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Fwd: [PWE3] RFC 4553 on Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) Date: Wed, 21 Jun 2006 18:38:41 -0600 To: pwe3 pwe3 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Many thanks to Sasha and Yaakov for their ability to bring this work to fruition! -danny Begin forwarded message: > From: rfc-editor@rfc-editor.org > Date: June 15, 2006 6:42:31 PM MDT > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: pwe3@ietf.org, rfc-editor@rfc-editor.org > Subject: [PWE3] RFC 4553 on Structure-Agnostic Time Division > Multiplexing (TDM) over Packet (SAToP) > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 4553 > > Title: Structure-Agnostic Time Division Multiplexing > (TDM) > over Packet (SAToP) > Author: A. Vainshtein, Ed., > YJ. Stein, Ed. > Status: Standards Track > Date: June 2006 > Mailbox: sasha@axerra.com, > yaakov_s@rad.com > Pages: 27 > Characters: 58141 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-pwe3-satop-05.txt > > URL: http://www.rfc-editor.org/rfc/rfc4553.txt > > This document describes a pseudowire encapsulation for Time Division > Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any > structure that may be imposed on these streams, in particular the > structure imposed by the standard TDM framing. [STANDARDS TRACK] > > This document is a product of the Pseudo Wire Emulation Edge to Edge > Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions for improvements.Please refer to the current edition of > the > Internet Official Protocol Standards (STD 1) for the standardization > state and status of this protocol. Distribution of this memo is > unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. > Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions > to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Jun 22 15:50:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtVBu-00067N-TG; Thu, 22 Jun 2006 15:50:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtVBj-0005sD-GJ; Thu, 22 Jun 2006 15:50:03 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtVBi-0004MN-6b; Thu, 22 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5MJo1Rx017596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtVBh-000699-Uc; Thu, 22 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-tdmoip-05.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : TDM over IP Author(s) : Y. Stein, et al. Filename : draft-ietf-pwe3-tdmoip-05.txt Pages : 47 Date : 2006-6-22 This document describes methods for structure-aware transport of Time Division Multiplexed (TDM) traffic over packet switched networks using pseudowires. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdmoip-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-tdmoip-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-tdmoip-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-22100302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-tdmoip-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-tdmoip-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22100302.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Fri Jun 23 15:50:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtrfY-0002fp-C8; Fri, 23 Jun 2006 15:50:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtrfH-0002LH-AM; Fri, 23 Jun 2006 15:50:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtrfG-0004uj-0X; Fri, 23 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5NJo1WR012271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtrfF-0003AC-MV; Fri, 23 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 23 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-dynamic-ms-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Dynamic Placement of Multi Segment Pseudo Wires Author(s) : F. Balus, et al. Filename : draft-ietf-pwe3-dynamic-ms-pw-01.txt Pages : 20 Date : 2006-6-23 There is a requirement for service providers to be able to extend the reach of pseudo wires (PW) across multiple Packet Switched Network domains. A Multi-Segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point- to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi segment pseudo wire among a set of Provider Edge (PE) routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-dynamic-ms-pw-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-dynamic-ms-pw-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-dynamic-ms-pw-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-23120947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-dynamic-ms-pw-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-dynamic-ms-pw-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-23120947.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Mon Jun 26 04:39:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumdO-0005ob-P4; Mon, 26 Jun 2006 04:39:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumdM-0005oO-Rv for pwe3@ietf.org; Mon, 26 Jun 2006 04:39:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FumdM-0001rx-Q7 for pwe3@ietf.org; Mon, 26 Jun 2006 04:39:52 -0400 Received: from [80.74.100.136] (helo=antivir1.rad.co.il) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FumaY-00021E-1H for pwe3@ietf.org; Mon, 26 Jun 2006 04:37:04 -0400 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k5Q8V8D5008915 for ; Mon, 26 Jun 2006 11:31:08 +0300 (IDT) Received: from exrad3.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id k5Q8V7wX008909; Mon, 26 Jun 2006 11:31:07 +0300 (IDT) X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Jun 2006 11:38:15 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815DDEAEA6@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: fragmentation and MTU Thread-Index: AcaZBD/OoZTfn5iLTzmjtwx58825Og== From: "Yaakov Stein" To: "Malis, Andrew G." X-Spam-Score: -2.6 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: pwe3 Subject: [PWE3] fragmentation and MTU X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Andy,=20 =20 I just noticed something that is possibly missing in the=20 MPLS control protocol extension section of the fragmentation draft. =20 The PW Interface Parameter sub-TLV parameter 0x09 indicates whether a PE supports fragmentation (i.e. can process the FRG field in the CW, has memory for storage of intermediate packets, etc) but there is no indication of the MTU of the AC. Thus, for an Ethernet PW, we don't know whether a PE specifying that it can handle fragmentation means that it can swallow a jumbo frame, or just reconstruct a regular 1500 byte frame that had to be fragmented due to the PSN overhead.=20 The L2TPv3 section has MRU and MRRU AVPs, but they focus on the PW packet (i.e. includes some or all of the L2TP + PSN overheads), rather than the AC limitations. Of course for the L2TPv3 case an AC limitation can be uniquely translated. Y(J)S =20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jun 26 05:46:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FunfT-0001oD-GF; Mon, 26 Jun 2006 05:46:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FunfR-0001o8-Ax for pwe3@ietf.org; Mon, 26 Jun 2006 05:46:05 -0400 Received: from webmail.axerra.com ([80.74.100.75] helo=mail.axerra.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FunfP-0006Pq-Sg for pwe3@ietf.org; Mon, 26 Jun 2006 05:46:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] fragmentation and MTU Date: Mon, 26 Jun 2006 12:47:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: fragmentation and MTU Thread-Index: AcaZBD/OoZTfn5iLTzmjtwx58825OgACKCMg From: "Sasha Vainshtein" To: "Yaakov Stein" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: "Malis, Andrew G." , "Luca Martini \(E-mail\)" , pwe3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Yaakov, Luca, Andy and all, IMO this is already taken care of by the Interface MTU Sub-TLV that is = defined in RFC 4447, Section 5.5.: - Interface MTU sub-TLV type A 2-octet value indicating the MTU in octets. This is the Maximum Transmission Unit, excluding encapsulation overhead, of the egress packet interface that will be transmitting the decapsulated PDU that is received from the MPLS-enabled network. This parameter is applicable only to PWs transporting packets and is REQUIRED for these PW types. If this parameter does not match in both directions of a specific PW, that PW MUST NOT be enabled. .=20 IANA has assigned a type of 0x01 for this sub-TLV (see = http://www.iana.org/assignments/pwe3-parameters). Did I miss something? Regards, Sasha > -----Original Message----- > From: Yaakov Stein [mailto:yaakov_s@rad.com] > Sent: Monday, June 26, 2006 11:38 AM > To: Malis, Andrew G. > Cc: pwe3 > Subject: [PWE3] fragmentation and MTU >=20 >=20 > Andy,=20 > =20 > I just noticed something that is possibly missing in the=20 > MPLS control protocol extension section of the fragmentation draft. > =20 > The PW Interface Parameter sub-TLV parameter 0x09 > indicates whether a PE supports fragmentation (i.e. can process > the FRG field in the CW, has memory for storage of=20 > intermediate packets, > etc) > but there is no indication of the MTU of the AC. >=20 > Thus, for an Ethernet PW, we don't know whether a PE specifying > that it can handle fragmentation means that it can swallow a jumbo > frame, > or just reconstruct a regular 1500 byte frame that had to be=20 > fragmented > due to the PSN overhead.=20 >=20 > The L2TPv3 section has MRU and MRRU AVPs, but they focus on the PW > packet > (i.e. includes some or all of the L2TP + PSN overheads),=20 > rather than the > AC > limitations. Of course for the L2TPv3 case an AC limitation can be > uniquely translated. >=20 > Y(J)S >=20 > =20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jun 26 09:53:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurWd-00011x-3J; Mon, 26 Jun 2006 09:53:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurWb-0000o5-LQ for pwe3@ietf.org; Mon, 26 Jun 2006 09:53:13 -0400 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FurWa-0001Av-AC for pwe3@ietf.org; Mon, 26 Jun 2006 09:53:13 -0400 Received: from usruamalisl.mail.com (m815f36d0.tmodns.net[208.54.95.129]) by comcast.net (rwcrmhc12) with SMTP id <20060626135309m1200a7t0ce>; Mon, 26 Jun 2006 13:53:10 +0000 Message-Id: <7.0.1.0.2.20060626094451.052e5e58@comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 26 Jun 2006 09:53:03 -0400 To: "Sasha Vainshtein" From: "Andrew G. Malis" Subject: RE: [PWE3] fragmentation and MTU In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: "Malis, Andrew G." , pwe3 , Yaakov Stein , "Luca Martini \(E-mail\)" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Sasha and Yaakov, Sasha is correct - the Interface MTU Sub-TLV signals the MTU of the AC. Note that this is independent of the fragmentation draft, which fragments based on the MTU of the PSN, not of the AC, although the MTU of the AC should be used to help size the reassembly buffers (see section 4.2 of the fragmentation draft). Cheers, Andy ----------- At 6/26/2006 12:47 +0200, Sasha Vainshtein wrote: >Yaakov, Luca, Andy and all, > >IMO this is already taken care of by the Interface MTU Sub-TLV that >is defined in RFC 4447, Section 5.5.: > > > - Interface MTU sub-TLV type > > A 2-octet value indicating the MTU in octets. This is the Maximum > Transmission Unit, excluding encapsulation overhead, of the egress > packet interface that will be transmitting the decapsulated PDU > that is received from the MPLS-enabled network. This parameter is > applicable only to PWs transporting packets and is REQUIRED for > these PW types. If this parameter does not match in both > directions of a specific PW, that PW MUST NOT be enabled. > >. > >IANA has assigned a type of 0x01 for this sub-TLV >(see http://www.iana.org/assignments/pwe3-parameters). > >Did I miss something? > >Regards, > Sasha > > > -----Original Message----- > > From: Yaakov Stein [mailto:yaakov_s@rad.com] > > Sent: Monday, June 26, 2006 11:38 AM > > To: Malis, Andrew G. > > Cc: pwe3 > > Subject: [PWE3] fragmentation and MTU > > > > > > Andy, > > > > I just noticed something that is possibly missing in the > > MPLS control protocol extension section of the fragmentation draft. > > > > The PW Interface Parameter sub-TLV parameter 0x09 > > indicates whether a PE supports fragmentation (i.e. can process > > the FRG field in the CW, has memory for storage of > > intermediate packets, > > etc) > > but there is no indication of the MTU of the AC. > > > > Thus, for an Ethernet PW, we don't know whether a PE specifying > > that it can handle fragmentation means that it can swallow a jumbo > > frame, > > or just reconstruct a regular 1500 byte frame that had to be > > fragmented > > due to the PSN overhead. > > > > The L2TPv3 section has MRU and MRRU AVPs, but they focus on the PW > > packet > > (i.e. includes some or all of the L2TP + PSN overheads), > > rather than the > > AC > > limitations. Of course for the L2TPv3 case an AC limitation can be > > uniquely translated. > > > > Y(J)S > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Jun 26 13:03:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuuUu-0001bY-Hn; Mon, 26 Jun 2006 13:03:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuuUt-0001bT-FI for pwe3@ietf.org; Mon, 26 Jun 2006 13:03:39 -0400 Received: from mx2-n.rad.co.il ([62.0.23.221] helo=antivir2.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuuUo-00024z-9X for pwe3@ietf.org; Mon, 26 Jun 2006 13:03:39 -0400 Received: from antivir2.rad.co.il (localhost [127.0.0.1]) by antivir2.rad.co.il (8.12.10/8.12.10) with ESMTP id k5QH3tkl006874 for ; Mon, 26 Jun 2006 20:03:57 +0300 (IDT) Received: from exrad3.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir2.rad.co.il (8.12.10/8.12.10) with ESMTP id k5QH3sEx006871; Mon, 26 Jun 2006 20:03:54 +0300 (IDT) X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] fragmentation and MTU Date: Mon, 26 Jun 2006 20:04:58 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815DF0612A@exrad3.ad.rad.co.il> In-Reply-To: <7.0.1.0.2.20060626094451.052e5e58@comcast.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] fragmentation and MTU Thread-Index: AcaZMHeqHBz0Ri0uTqWJTt9YiS57IQAGi8Eg From: "Yaakov Stein" To: "Andrew G. Malis" , "Sasha Vainshtein" X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: "Malis, Andrew G." , pwe3 , "Luca Martini \(E-mail\)" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Andy / Sasha,=20 Yes, Sasha is correct. I wanted to avoid a jumbo frame being fragmented but then discarded as the far-end AC could not support. But this can't happen if the PW is not set up unless the MTUs match. BTW, "transporting packets" needs to be interpreted as "transporting packets or frames". Thanks to both of you,=20 Y(J)S -----Original Message----- From: Andrew G. Malis [mailto:andymalis@comcast.net]=20 Sent: Monday, June 26, 2006 15:53 To: Sasha Vainshtein Cc: Yaakov Stein; Malis, Andrew G.; Luca Martini (E-mail); pwe3 Subject: RE: [PWE3] fragmentation and MTU Sasha and Yaakov, Sasha is correct - the Interface MTU Sub-TLV signals the MTU of the AC. Note that this is independent of the fragmentation draft, which fragments based on the MTU of the PSN, not of the AC, although the MTU of the AC should be used to help size the reassembly buffers (see section 4.2 of the fragmentation draft). Cheers, Andy ----------- At 6/26/2006 12:47 +0200, Sasha Vainshtein wrote: >Yaakov, Luca, Andy and all, > >IMO this is already taken care of by the Interface MTU Sub-TLV that is=20 >defined in RFC 4447, Section 5.5.: > > > - Interface MTU sub-TLV type > > A 2-octet value indicating the MTU in octets. This is the Maximum > Transmission Unit, excluding encapsulation overhead, of the egress > packet interface that will be transmitting the decapsulated PDU > that is received from the MPLS-enabled network. This parameter is > applicable only to PWs transporting packets and is REQUIRED for > these PW types. If this parameter does not match in both > directions of a specific PW, that PW MUST NOT be enabled. > >. > >IANA has assigned a type of 0x01 for this sub-TLV (see =20 >http://www.iana.org/assignments/pwe3-parameters). > >Did I miss something? > >Regards, > Sasha > > > -----Original Message----- > > From: Yaakov Stein [mailto:yaakov_s@rad.com] > > Sent: Monday, June 26, 2006 11:38 AM > > To: Malis, Andrew G. > > Cc: pwe3 > > Subject: [PWE3] fragmentation and MTU > > > > > > Andy, > > > > I just noticed something that is possibly missing in the MPLS=20 > > control protocol extension section of the fragmentation draft. > > > > The PW Interface Parameter sub-TLV parameter 0x09 indicates whether=20 > > a PE supports fragmentation (i.e. can process the FRG field in the=20 > > CW, has memory for storage of intermediate packets, > > etc) > > but there is no indication of the MTU of the AC. > > > > Thus, for an Ethernet PW, we don't know whether a PE specifying that > > it can handle fragmentation means that it can swallow a jumbo frame, > > or just reconstruct a regular 1500 byte frame that had to be=20 > > fragmented due to the PSN overhead. > > > > The L2TPv3 section has MRU and MRRU AVPs, but they focus on the PW=20 > > packet (i.e. includes some or all of the L2TP + PSN overheads),=20 > > rather than the AC limitations. Of course for the L2TPv3 case an AC=20 > > limitation can be uniquely translated. > > > > Y(J)S > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jun 27 15:37:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJN7-0005Oc-4h; Tue, 27 Jun 2006 15:37:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJN6-0005OU-MX for pwe3@ietf.org; Tue, 27 Jun 2006 15:37:16 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJN5-0007Si-FA for pwe3@ietf.org; Tue, 27 Jun 2006 15:37:16 -0400 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id E8B57644D7 for ; Tue, 27 Jun 2006 13:37:10 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v750) References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <13D803E1-95F6-4400-BB29-737115122AA8@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Date: Tue, 27 Jun 2006 13:37:13 -0600 To: pwe3 pwe3 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [PWE3] Fwd: 66th IETF Final Agenda X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org FYI... -danny Begin forwarded message: > From: IETF Agenda > Date: June 26, 2006 7:45:06 PM MDT > To: Working Group Chairs > Cc: bofchairs@ietf.org, irtfchairs@irtf.org > Subject: 66th IETF Final Agenda > > The final agenda for the 66th IETF meeting can be found at > http://www.ietf.org/meetings/IETF-66.html > [snip] > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jun 27 15:59:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJii-00027w-OD; Tue, 27 Jun 2006 15:59:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJa2-0007PI-43; Tue, 27 Jun 2006 15:50:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJa1-0001Qy-RI; Tue, 27 Jun 2006 15:50:38 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo2UA002946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 19:50:04 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZS-0005Hc-El; Tue, 27 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mpls-mib-09.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Pseudo Wire (PW) over MPLS PSN Management Information Base Author(s) : D. Zelig, T. Nadeau Filename : draft-ietf-pwe3-pw-mpls-mib-09.txt Pages : 28 Date : 2006-6-27 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for PW operation over Multi-Protocol Label Switching (MPLS) Label Switch Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mpls-mib-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-pw-mpls-mib-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-mpls-mib-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27131124.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-pw-mpls-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-pw-mpls-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27131124.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Tue Jun 27 16:13:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJvk-0002L0-0B; Tue, 27 Jun 2006 16:13:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJvi-0002IH-Bf for pwe3@ietf.org; Tue, 27 Jun 2006 16:13:02 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJvh-0005Oo-3Q for pwe3@ietf.org; Tue, 27 Jun 2006 16:13:02 -0400 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id A3F856444B for ; Tue, 27 Jun 2006 14:12:56 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v750) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E4FDFAD-8D25-475A-B30F-CCE4827D84C4@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Date: Tue, 27 Jun 2006 14:12:59 -0600 To: pwe3 pwe3 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [PWE3] Fwd: Recommending the 'Tao of the IETF' to your WG members X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org FYI.... -danny Begin forwarded message: > From: Paul Hoffman > Date: June 12, 2006 11:38:10 AM MDT > To: wgchairs@ietf.org > Subject: Recommending the 'Tao of the IETF' to your WG members > > Greetings again. If you have been suggesting that newbies in your > WG coming to their first IETF read the 'Tao of the IETF', there is > now a new official version. Feel free to point them at www.ietf.org/internet-drafts/draft-hoffman-taobis-08.txt>, which > has just been approved as an Informational RFC to replace the old Tao. > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Jun 27 16:42:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKOH-0004zR-7P; Tue, 27 Jun 2006 16:42:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKOG-0004yy-Fj; Tue, 27 Jun 2006 16:42:32 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJwV-0005QL-7y; Tue, 27 Jun 2006 16:13:51 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvJZT-0003U3-08; Tue, 27 Jun 2006 15:50:11 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo29F012482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZS-0005Ho-HP; Tue, 27 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-enet-mib-08.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Ethernet Pseudo Wire (PW) Management Information Base Author(s) : D. Zelig, T. Nadeau Filename : draft-ietf-pwe3-enet-mib-08.txt Pages : 22 Date : 2006-6-27 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Ethernet Pseudo Wire (PW) services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-enet-mib-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-enet-mib-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-enet-mib-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27131758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-enet-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-enet-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27131758.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Tue Jun 27 16:44:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKQM-0000c5-0j; Tue, 27 Jun 2006 16:44:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKQF-0000KU-R6; Tue, 27 Jun 2006 16:44:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJvw-0005Ox-Nk; Tue, 27 Jun 2006 16:13:16 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvJnq-0004X9-5e; Tue, 27 Jun 2006 16:04:56 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo3jx016451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 19:50:04 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZS-0005J4-Vy; Tue, 27 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-cep-mib-08.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base Using SMIv2 Author(s) : T. Nadeau, et al. Filename : draft-ietf-pwe3-cep-mib-08.txt Pages : 62 Date : 2006-6-27 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Native Service Processing of SONET/SDH circuits over a Packet Switch Network (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cep-mib-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-cep-mib-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-cep-mib-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27143754.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-cep-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-cep-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27143754.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Tue Jun 27 16:47:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKSk-0005q5-33; Tue, 27 Jun 2006 16:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKSf-0005ex-Ce; Tue, 27 Jun 2006 16:47:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJwV-0005Q8-7l; Tue, 27 Jun 2006 16:13:51 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvJZT-0003U4-1E; Tue, 27 Jun 2006 15:50:12 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo29F012477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZS-0005Hf-FJ; Tue, 27 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-08.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Pseudo Wire (PW) Management Information Base Author(s) : D. Zelig, T. Nadeau Filename : draft-ietf-pwe3-pw-mib-08.txt Pages : 56 Date : 2006-6-27 This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudo Wire Edge-to-Edge services carried over a general Packet Switched Network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-pw-mib-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27131306.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-pw-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-pw-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27131306.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Wed Jun 28 16:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvgzo-000137-1P; Wed, 28 Jun 2006 16:50:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvgzf-0000Vs-TW; Wed, 28 Jun 2006 16:50:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvgWp-0007hh-P6; Wed, 28 Jun 2006 16:20:51 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvgHV-0005M7-0l; Wed, 28 Jun 2006 16:05:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5SJo2jx013889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fvg30-00031F-DM; Wed, 28 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Jun 2006 15:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-vccv-10.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) Author(s) : T. Nadeau, et al. Filename : draft-ietf-pwe3-vccv-10.txt Pages : 25 Date : 2006-6-28 This document describes Virtual Circuit Connection Verification (VCCV) which provides a control channel that is associated with a pseudo wire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-vccv-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-vccv-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-28131606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-vccv-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-vccv-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-28131606.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Thu Jun 29 15:50:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2Wo-0005CY-2u; Thu, 29 Jun 2006 15:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2WY-0004jU-Hp; Thu, 29 Jun 2006 15:50:02 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw2WY-0001Y6-07; Thu, 29 Jun 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5TJo19F012743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fw2WX-0003RI-Fw; Thu, 29 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 29 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-fc-encap-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks Author(s) : M. Roth, et al. Filename : draft-ietf-pwe3-fc-encap-01.txt Pages : 18 Date : 2006-6-29 A Fibre Channel Pseudowire (PW) is used to carry Fibre Channel frames over an MPLS network. This enables service providers to offer "emulated" Fibre Channel services over existing MPLS networks. This document specifies the encapsulation of Fibre Channel PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a Fibre Channel service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fc-encap-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-fc-encap-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-fc-encap-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-29101612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-fc-encap-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-fc-encap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-29101612.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart--