From l3vpn-bounces@ietf.org Thu Apr 05 22:00:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdjC-0000az-N7; Thu, 05 Apr 2007 21:59:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdjB-0000Zv-9c for l3vpn@ietf.org; Thu, 05 Apr 2007 21:59:01 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZdj9-0002QI-P5 for l3vpn@ietf.org; Thu, 05 Apr 2007 21:59:01 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JG2002N3050QT@szxga03-in.huawei.com> for l3vpn@ietf.org; Fri, 06 Apr 2007 09:58:12 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JG20031I04ZG1@szxga03-in.huawei.com> for l3vpn@ietf.org; Fri, 06 Apr 2007 09:58:12 +0800 (CST) Received: from k70172 ([10.111.64.23]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JG2000MX04YLT@szxml03-in.huawei.com> for l3vpn@ietf.org; Fri, 06 Apr 2007 09:58:11 +0800 (CST) Date: Fri, 06 Apr 2007 09:58:10 +0800 From: Kalyankumar S Asangi To: l3vpn@ietf.org Message-id: <00c201c777ef$07251bb0$17406f0a@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: multipart/alternative; boundary="Boundary_(ID_XbljWWftfUpXtcmnvbkPiQ)" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: L3VPN : CE Multihoming Question X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_XbljWWftfUpXtcmnvbkPiQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi , I have question related to CE multihoming in the following scenario 1. CE1 is multi homed to PE1 and PE2 and sends the route 10.10.0.0/16 to both PE1 and PE2 2. PE1 select this route as best route and send it to PE3 as VPNv4 with RD 1:1 and ERT 11:11 3. PE2 also select this route as best route and send it to PE3 as VPNv4 with RD 2:2 and ERT 22:22 4. PE3 has VRF1 connected to CE2 with IRT 11:11 and 22:22 and OSPF is running between PE3 and CE2 5. Now PE3 receives the two VPNv4 routes for prefix 10.10.0.0./16 from two sources with two different RD, Which route PE3 BGP will choose and download to VRF1 ? 6. Should BGP compare these two routes even if they come with two different RDs and download one route to VRF or download both routes to VRF as they come with two different RDs ? Regards, Kalyan --Boundary_(ID_XbljWWftfUpXtcmnvbkPiQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi ,
 
I have question related to CE multihoming in the following scenario
 
1. CE1 is multi homed to PE1 and PE2 and sends the route 10.10.0.0/16 to both PE1 and PE2
2. PE1 select this route as best route and send it to PE3 as VPNv4 with RD 1:1 and ERT 11:11
3. PE2 also select this route as best route and send it to PE3 as VPNv4 with RD 2:2 and ERT 22:22
4. PE3 has VRF1 connected to CE2 with IRT 11:11 and 22:22 and OSPF is running between PE3 and CE2
5. Now PE3 receives the two VPNv4 routes for prefix 10.10.0.0./16 from two sources with two different RD, 
   Which route PE3 BGP will choose and download to VRF1 ?
6. Should BGP compare these two routes even if they come with two different RDs and download one route to VRF
   or download both routes to VRF as they come with two different RDs ?
 
Regards,
Kalyan
--Boundary_(ID_XbljWWftfUpXtcmnvbkPiQ)-- From l3vpn-bounces@ietf.org Thu Apr 05 23:23:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZf2F-0001II-Ti; Thu, 05 Apr 2007 23:22:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZf2F-0001ID-4n for l3vpn@ietf.org; Thu, 05 Apr 2007 23:22:47 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZf2E-0000rn-4U for l3vpn@ietf.org; Thu, 05 Apr 2007 23:22:47 -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 <0JG2003WJ40MOZ@szxga02-in.huawei.com> for l3vpn@ietf.org; Fri, 06 Apr 2007 11:21:58 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JG200FNP40LM5@szxga02-in.huawei.com> for l3vpn@ietf.org; Fri, 06 Apr 2007 11:21:58 +0800 (CST) Received: from k70172 ([10.111.64.23]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JG2000C440KLT@szxml03-in.huawei.com> for l3vpn@ietf.org; Fri, 06 Apr 2007 11:21:57 +0800 (CST) Date: Fri, 06 Apr 2007 11:21:56 +0800 From: Kalyankumar S Asangi To: RAUT Devendra , l3vpn@ietf.org Message-id: <00e701c777fa$bafeab50$17406f0a@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: multipart/alternative; boundary="Boundary_(ID_0TVqRQGMpxXSjSn9zcrZBg)" X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: Subject: Re: L3VPN : CE Multihoming Question X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_0TVqRQGMpxXSjSn9zcrZBg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT But as per RFC 4364 section 4.3, it is the decision process of protocol running between PE and CE " At these other PEs, BGP will again choose the best route for a particular VPN-IP4 address prefix. Then the chosen VPN-IP4 routes are converted back into IP routes, and "imported" into one or more VRFs. Whether they are actually installed in the VRFs depends on the decision process of the routing method used between the PE and those CEs that are associated with the VRF in question. Finally, any route installed in a VRF may be distributed to the associated CE routers" Regards, Kalyan ----- Original Message ----- From: RAUT Devendra To: Kalyankumar S Asangi ; l3vpn@ietf.org Sent: Friday, April 06, 2007 10:31 AM Subject: RE: L3VPN : CE Multihoming Question Yes, BGP should compare these routes. Once RD is stripped and route is candidate for import into a VRF, the routes are like any other BGP routes with attributes and should be compared. -Deven ------------------------------------------------------------------------------ From: Kalyankumar S Asangi [mailto:kalyana@huawei.com] Sent: Thursday, April 05, 2007 6:58 PM To: l3vpn@ietf.org Subject: L3VPN : CE Multihoming Question Hi , I have question related to CE multihoming in the following scenario 1. CE1 is multi homed to PE1 and PE2 and sends the route 10.10.0.0/16 to both PE1 and PE2 2. PE1 select this route as best route and send it to PE3 as VPNv4 with RD 1:1 and ERT 11:11 3. PE2 also select this route as best route and send it to PE3 as VPNv4 with RD 2:2 and ERT 22:22 4. PE3 has VRF1 connected to CE2 with IRT 11:11 and 22:22 and OSPF is running between PE3 and CE2 5. Now PE3 receives the two VPNv4 routes for prefix 10.10.0.0./16 from two sources with two different RD, Which route PE3 BGP will choose and download to VRF1 ? 6. Should BGP compare these two routes even if they come with two different RDs and download one route to VRF or download both routes to VRF as they come with two different RDs ? Regards, Kalyan --Boundary_(ID_0TVqRQGMpxXSjSn9zcrZBg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
But as per RFC 4364 section 4.3, it is the decision process of protocol running between PE and CE
 
" At these other PEs, BGP will again choose the
   best route for a particular VPN-IP4 address prefix.  Then the chosen
   VPN-IP4 routes are converted back into IP routes, and "imported" into
   one or more VRFs.  Whether they are actually installed in the VRFs
   depends on the decision process of the routing method used between
   the PE and those CEs that are associated with the VRF in question.
   Finally, any route installed in a VRF may be distributed to the
   associated CE routers"
 
Regards,
Kalyan
----- Original Message -----
Sent: Friday, April 06, 2007 10:31 AM
Subject: RE: L3VPN : CE Multihoming Question

Yes, BGP should compare these routes. Once RD is stripped and route is candidate for import into a VRF, the routes are 
like any other BGP routes with attributes and should be compared.
 
-Deven

From: Kalyankumar S Asangi [mailto:kalyana@huawei.com]
Sent: Thursday, April 05, 2007 6:58 PM
To: l3vpn@ietf.org
Subject: L3VPN : CE Multihoming Question

Hi ,
 
I have question related to CE multihoming in the following scenario
 
1. CE1 is multi homed to PE1 and PE2 and sends the route 10.10.0.0/16 to both PE1 and PE2
2. PE1 select this route as best route and send it to PE3 as VPNv4 with RD 1:1 and ERT 11:11
3. PE2 also select this route as best route and send it to PE3 as VPNv4 with RD 2:2 and ERT 22:22
4. PE3 has VRF1 connected to CE2 with IRT 11:11 and 22:22 and OSPF is running between PE3 and CE2
5. Now PE3 receives the two VPNv4 routes for prefix 10.10.0.0./16 from two sources with two different RD, 
   Which route PE3 BGP will choose and download to VRF1 ?
6. Should BGP compare these two routes even if they come with two different RDs and download one route to VRF
   or download both routes to VRF as they come with two different RDs ?
 
Regards,
Kalyan
--Boundary_(ID_0TVqRQGMpxXSjSn9zcrZBg)-- From l3vpn-bounces@ietf.org Tue Apr 17 17:09:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HduvC-0008IP-Ew; Tue, 17 Apr 2007 17:09:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hduv8-0008F3-QR; Tue, 17 Apr 2007 17:09:02 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hduv6-0002iz-1n; Tue, 17 Apr 2007 17:09:01 -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 l3HL8xdI007695; Tue, 17 Apr 2007 14:08:59 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l3HL8xYi007694; Tue, 17 Apr 2007 14:08:59 -0700 Date: Tue, 17 Apr 2007 14:08:59 -0700 Message-Id: <200704172108.l3HL8xYi007694@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: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: l3vpn@ietf.org, rfc-editor@rfc-editor.org Subject: RFC 4834 on Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4834 Title: Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) Author: T. Morin, Ed. Status: Informational Date: April 2007 Mailbox: thomas.morin@orange-ftgroup.com Pages: 37 Characters: 80341 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l3vpn-ppvpn-mcast-reqts-10.txt URL: http://www.rfc-editor.org/rfc/rfc4834.txt This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within Layer 3 (L3) Provider-Provisioned Virtual Private Networks (PPVPNs). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines. This memo provides information for the Internet community. This document is a product of the Layer 3 Virtual Private Networks Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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. The RFC Editor Team USC/Information Sciences Institute ... From l3vpn-bounces@ietf.org Mon Apr 23 15:20:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg45e-0005Qc-Gj; Mon, 23 Apr 2007 15:20:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg45d-0005QX-Rw for l3vpn@ietf.org; Mon, 23 Apr 2007 15:20:45 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg45c-0004w2-JN for l3vpn@ietf.org; Mon, 23 Apr 2007 15:20:45 -0400 X-IronPort-AV: E=Sophos;i="4.14,443,1170662400"; d="scan'208";a="713433119" Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 23 Apr 2007 12:20:44 -0700 Received: from [172.23.1.36] ([172.23.1.36] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 15:20:42 -0400 Message-ID: <462D0706.2040904@juniper.net> Date: Mon, 23 Apr 2007 15:20:38 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l3vpn@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2007 19:20:42.0285 (UTC) FILETIME=[7BFD5DD0:01C785DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: Minutes - better late than never X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-bounces@ietf.org Folks, Rick and I apologize for being late with minutes. Minutes for IETF 68 L3VPN follow: L3VPN Working Group Meeting, IETF 68, Prague, Czech Republic Co-chairs: Ron Bonica, Rick Wilder Document status: For quite a while, several working group drafts have needed revisions in order to progress. The following documents therefore need an ETA for an updated draft within a month to avoid being dropped: - draft-ietf-l3vpn-ce-based - draft-ietf-l3vpn-vpn-vr - draft-ietf-l3vpn-vr-mib - draft-declercq-l3vpn-ce-based-as - draft-ietf-l3vpn-as-vr - draft-ietf-l3vpn-bgpvpn-auto Working Group charter: The Charter is in need of an update. Multicast VPN work is by far the most prominent item of work, but MPLS service delivery over L3VPN is being considered. The work load for the group also makes the adoption of other work items possible, so input is solicited for additions to the WG charter. Detailed discussion of the charter will not be taken up at this meeting due to time constraints. Delivery of MPLS Services Over L3VPN Kenji Kumaki requested that Requirements for delivering MPLS Services over L3VPN - draft-kumaki-l3vpn-e2e-rsvp-te-reqs-03 be adopted as an L3VPN working group draft. The issue of whether draft should be a working group doc will be taken up after the WG charter is updated. Considerations about Multicast BGP/MPLS Standardization - T. Morin draft-morin-l3vpn-mvpn-considerations The document outlines building blocks for monitoring MVPN infrastructure. (see slides) BGP-based and PIM-based autodiscovery is considered and scalability analyzed. Discussion of the document on the email list is needed to determine consensus on adopting the draft as a working group document. Multicast MPLS/BGP Vans Revisited - M. Napier draft-mnapierala-mvpn-rev-00 Additional multicast capabilities required by customer applications are outlined and recommended for inclusion into MVPNs. (see slides) Discussion on the WG email list is solicited. From l3vpn-bounces@ietf.org Wed Apr 25 15:51:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgnVq-0005oX-M4; Wed, 25 Apr 2007 15:50:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgnVZ-0005OX-Pv; Wed, 25 Apr 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HgnVZ-0006fW-FV; Wed, 25 Apr 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id BD5BD175E0; Wed, 25 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HgnV4-00079C-GF; Wed, 25 Apr 2007 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, 25 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: l3vpn@ietf.org Subject: I-D ACTION:draft-ietf-l3vpn-bgpvpn-auto-09.txt X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l3vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l3vpn-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 Layer 3 Virtual Private Networks Working Group of the IETF. Title : Using BGP as an Auto-Discovery Mechanism for VR-based Layer-3 VPNs Author(s) : H. Ould-Brahim, et al. Filename : draft-ietf-l3vpn-bgpvpn-auto-09.txt Pages : 12 Date : 2007-4-25 In any provider-based VPN scheme, the Provider Edge (PE) devices attached to a common VPN must exchange certain information as a prerequisite to establish VPN-specific connectivity. The main purpose of an auto-discovery mechanism is to enable a PE to dynamically discover the set of remote PEs having VPN members in common. The auto-discovery mechanism proceeds by having a PE advertises to other PEs, at a minimum, its own IP address and the list of VPN members configured on that PE. Once that information is received the remote PEs will then identify the list of VPN sites members of the same VPN, and use the information carried within the discovery mechanism to establish VPN connectivity. This draft defines a BGP based auto-discovery mechanism for Virtual Router-based layer-3 VPNs. This mechanism is based on the approach used by BGP/MPLS-IP-VPN for distributing VPN routing information within the service provider(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-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-l3vpn-bgpvpn-auto-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-l3vpn-bgpvpn-auto-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: <2007-4-25113800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l3vpn-bgpvpn-auto-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-25113800.I-D@ietf.org> --OtherAccess-- --NextPart--