From mailman-bounces@ietf.org Wed Dec 1 08:37:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27824 for ; Wed, 1 Dec 2004 08:37:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZUkx-0000D5-FP for idr-archive@ietf.org; Wed, 01 Dec 2004 08:42:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZSbV-0006ZP-3Q for idr-archive@ietf.org; Wed, 01 Dec 2004 06:25:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: idr-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Dec 2004 05:45:16 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for idr-archive@ietf.org: List Password // URL ---- -------- idr@ietf.org omkeeh https://www1.ietf.org/mailman/options/idr/idr-archive%40ietf.org From idr-bounces@ietf.org Wed Dec 1 12:37:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01543; Wed, 1 Dec 2004 12:37:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZYV5-00064w-OC; Wed, 01 Dec 2004 12:42:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZXY1-0000LG-44; Wed, 01 Dec 2004 11:41:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZW1M-0001Pn-62 for idr@megatron.ietf.org; Wed, 01 Dec 2004 10:03:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06967 for ; Wed, 1 Dec 2004 10:03:55 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZW6f-0001sv-V6 for idr@ietf.org; Wed, 01 Dec 2004 10:09:27 -0500 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iB1F300I013303 for ; Wed, 1 Dec 2004 09:03:07 -0600 (CST) Received: by NJ7460EXCH001H with Internet Mail Service (5.5.2657.72) id <4M3JBDBX>; Wed, 1 Dec 2004 10:02:58 -0500 Message-ID: From: "Busschbach, Peter B (Peter)" To: idr@ietf.org Date: Wed, 1 Dec 2004 10:02:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 We recently published a new version of "Carrying ATM reachability information in BGP" http://www.ietf.org/internet-drafts/draft-ck-bgp-atm-nlri-01.txt The differences with the previous version are minor: - A few textual changes in the introduction - Clarification of how to map the four-byte ATM Administrative Weight in the corresponding Extended Communities attribute - Addition of a paragraph on the use of the Site of Origin attribute As discussed in the WG meeting in Washington D.C., we would like the working group to accept this draft as a working group document. Please respond to this email with your comments. Thanks, CK Chris Metz Peter Busschbach _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Dec 3 15:07:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01083; Fri, 3 Dec 2004 15:07:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaJo6-00032o-Ca; Fri, 03 Dec 2004 15:13:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaJRr-0000zu-92; Fri, 03 Dec 2004 14:50:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaJ0K-0006pi-PW for idr@megatron.ietf.org; Fri, 03 Dec 2004 14:22:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24273 for ; Fri, 3 Dec 2004 14:22:07 -0500 (EST) Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CaJ67-00012h-QG for idr@ietf.org; Fri, 03 Dec 2004 14:28:08 -0500 Received: (qmail 24775 invoked from network); 3 Dec 2004 19:22:02 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 3 Dec 2004 19:22:02 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iB3JM9gd004115; Fri, 3 Dec 2004 14:22:10 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200412031922.iB3JM9gd004115@workhorse.faster-light.net> To: "Busschbach, Peter B (Peter)" Subject: Re: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? In-reply-to: Your message of "Wed, 01 Dec 2004 10:02:56 EST." Date: Fri, 03 Dec 2004 14:22:09 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 In message "Busschbach, Peter B (Peter)" writes: > > We recently published a new version of "Carrying ATM reachability information in BGP" > > http://www.ietf.org/internet-drafts/draft-ck-bgp-atm-nlri-01.txt > > The differences with the previous version are minor: > > - A few textual changes in the introduction > > - Clarification of how to map the four-byte ATM Administrative Weight in the corresponding Extended Communities attribute > > - Addition of a paragraph on the use of the Site of Origin attribute > > > > As discussed in the WG meeting in Washington D.C., we would like the working group to accept this draft as a working group document. Please respond to this email with your comments. > > Thanks, > > CK > Chris Metz > Peter Busschbach > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr Is anyone actually interested in deploying this or is it more of an intellectual exercise. The routing area has in the past required that there be a clear requirement for new work in a work group. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Dec 3 15:47:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05104; Fri, 3 Dec 2004 15:47:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaKQY-0004Mj-Pk; Fri, 03 Dec 2004 15:53:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaKCG-0003eH-0l; Fri, 03 Dec 2004 15:38:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaK5c-0005TG-JY for idr@megatron.ietf.org; Fri, 03 Dec 2004 15:31:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03737 for ; Fri, 3 Dec 2004 15:31:39 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaKBQ-0003tu-9h for idr@ietf.org; Fri, 03 Dec 2004 15:37:40 -0500 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iB3KV7vC018982 for ; Fri, 3 Dec 2004 14:31:08 -0600 (CST) Received: by NJ7460EXCH001H with Internet Mail Service (5.5.2657.72) id <4M3J1P88>; Fri, 3 Dec 2004 15:31:07 -0500 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'curtis@faster-light.net'" Subject: RE: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? Date: Fri, 3 Dec 2004 15:31:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Curtis Villamizar wrote: >> Is anyone actually interested in deploying this or is it more of an > intellectual exercise. The routing area has in the past required that > there be a clear requirement for new work in a work group. > > Curtis I know of two vendors who are working on implementations and several Service Providers who have expressed interest. In addition, the draft hardly qualifies as "new work". It is a straightforward application of MP-BGP. Peter _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Dec 3 17:45:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14798; Fri, 3 Dec 2004 17:45:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaMGx-0007fq-G3; Fri, 03 Dec 2004 17:51:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaLnI-0003dB-B0; Fri, 03 Dec 2004 17:20:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaLL4-0000HX-1e for idr@megatron.ietf.org; Fri, 03 Dec 2004 16:51:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09587 for ; Fri, 3 Dec 2004 16:51:39 -0500 (EST) Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CaLQq-0005yP-Qs for idr@ietf.org; Fri, 03 Dec 2004 16:57:42 -0500 Received: (qmail 91758 invoked from network); 3 Dec 2004 21:51:38 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 3 Dec 2004 21:51:38 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iB3LpnSM004497; Fri, 3 Dec 2004 16:51:49 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200412032151.iB3LpnSM004497@workhorse.faster-light.net> To: "Busschbach, Peter B (Peter)" Subject: Re: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? In-reply-to: Your message of "Fri, 03 Dec 2004 15:31:05 EST." Date: Fri, 03 Dec 2004 16:51:49 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b In message "Busschbach, Peter B (Peter)" writes: > > Curtis Villamizar wrote: > >> Is anyone actually interested in deploying this or is it more of an > > intellectual exercise. The routing area has in the past required that > > there be a clear requirement for new work in a work group. > > > > Curtis > > I know of two vendors who are working on implementations and several Service Providers who have expressed interest. > > In addition, the draft hardly qualifies as "new work". It is a straightforward application of MP-BGP. > > Peter Peter, Anything that is not a WG item and is being considered for a WG item is by definition new work for the WG and therefore it should be determined that there is a requirement for it. I think those several service providers should speak up for themselves if they are interested in seeing this work progress. Having been on the provider side of this business in the past I know that at times a vendor will approach a service provider with an idea and if they provider doesn't bodily throw them out the door the vendor counts them as "possibly interested" for the purpose of discussions such as this. Therefore I'd like to see the providers speak for themselves rather than the vendor speak and there is plenty of precedence in the IETF for asking for that. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Dec 6 07:29:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03020; Mon, 6 Dec 2004 07:29:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbI5x-0001so-1t; Mon, 06 Dec 2004 07:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbHck-00014R-Av; Mon, 06 Dec 2004 07:05:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbHbc-0000fO-7m; Mon, 06 Dec 2004 07:04:40 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28904; Mon, 6 Dec 2004 07:04:37 -0500 (EST) Message-Id: <200412061204.HAA28904@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 06 Dec 2004 07:04:37 -0500 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-analysis-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP-4 Protocol Analysis Author(s) : D. Meyer, K. Patel Filename : draft-ietf-idr-bgp-analysis-07.txt Pages : 20 Date : 2004-12-3 The purpose of this report is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for 'the second report', as described in Section 6.0 of [RFC1264]. In order to fulfill the requirement, this report augments [RFC1774] and summarizes the key features of BGP-4 protocol, and analyzes the protocol with respect to scaling and performance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-07.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-idr-bgp-analysis-07.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-idr-bgp-analysis-07.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: <2004-12-6073300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-analysis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-analysis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-6073300.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Mon Dec 6 12:33:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02564; Mon, 6 Dec 2004 12:33:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbMpt-0001yw-NQ; Mon, 06 Dec 2004 12:39:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbMi8-000654-AT; Mon, 06 Dec 2004 12:31:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbMWs-00039h-0I for idr@megatron.ietf.org; Mon, 06 Dec 2004 12:20:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01415 for ; Mon, 6 Dec 2004 12:20:03 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbMdF-0001hg-BL for idr@ietf.org; Mon, 06 Dec 2004 12:26:42 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id iB6HJT925142 for ; Mon, 6 Dec 2004 09:19:29 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id iB6HJOe67451 for ; Mon, 6 Dec 2004 09:19:24 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200412061719.iB6HJOe67451@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71333.1102353564.1@juniper.net> Date: Mon, 06 Dec 2004 09:19:24 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Idr] draft-ck-bgp-atm-nlri-01.txt as an IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Folks, We receive a request to accept draft-ck-bgp-atm-nlri-01.txt as an IDR WG document. It would be greatly appreciated if folks would read the document and comment on it to the IDR mailing list. In other words, we need "yes, looks good" or "should fix this and that", not just silence. The deadline for comments is Dec 20, 2004 (if this is too short, please speak up, and we'll extend the deadline). Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Dec 10 11:38:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27965; Fri, 10 Dec 2004 11:38:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccntu-00005j-4p; Fri, 10 Dec 2004 11:45:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcnfM-00072S-5J; Fri, 10 Dec 2004 11:30:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcnaQ-0005XG-G0 for idr@megatron.ietf.org; Fri, 10 Dec 2004 11:25:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27141 for ; Fri, 10 Dec 2004 11:25:39 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccnhd-0008HP-4n for idr@ietf.org; Fri, 10 Dec 2004 11:33:10 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id DE7C72D483A for ; Fri, 10 Dec 2004 11:25:05 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04501-05-45 for ; Fri, 10 Dec 2004 11:25:03 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7F2EC2D480C for ; Fri, 10 Dec 2004 11:25:03 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 10 Dec 2004 11:25:03 -0500 Message-ID: Thread-Topic: MInutes for IDR Thread-Index: AcTe1M1W6rWg0MNgQM+kkJPUpeMTcw== From: "Susan Hares" To: X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.6 (/) X-Scan-Signature: ea98052f75c8682673c96267a0eea7de Cc: yakov@juniper.net Subject: [Idr] MInutes for IDR X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0154699101==" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 96ace3b0d55c752b49ad5cebce8c2b2a This is a multi-part message in MIME format. --===============0154699101== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DED4.CD725352" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4DED4.CD725352 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Please send in comments on the minutes for IETF 61. =20 Sue =20 =20 =20 =20 Sue Hares and Yakov Rekhter co-chaired the meeting. Yakov issued an=20 initial OPEN, but a transmission failure of the microphone system=20 caused his transport entity to time out. He retransmitted the OPEN and=20 successfully peered with the attendees. =20 =20 Old Business ------------ =20 Sue reviewed the status of the core BGP documents under revision:=20 =20 - Border Gateway Protocol 4 (BGP-4)=20 - Definitions of Managed Objects for the Fourth Version of=20 Border Gateway Protocol (BGP-4)=20 - BGP-4 Protocol Analysis=20 - BGP Security Vulnerabilities Analysis=20 - Experience with the BGP-4 Protocol=20 - BGP MIB V1 implementation survey=20 - BGP 4 Implementation Report =20 There is no new internal WG progress or action=20 required; these are awaiting IESG review. =20 Also in the approval process are Graceful Restart and Extended=20 Communities, both as Proposed Standards, and Cease Subcodes, to be a=20 Draft Standard. =20 The IESG is waiting for an implementation report on confederations. =20 There was nothing to report on cooperative route filtering, 4-octet AS=20 numbers, AS-based ORF, MIB 2, and AS-wide identifiers. =20 =20 New Business ------------ Equal Cost Multipath (Manav Bhatia, Joel Halpern) ------------------------------------------------- =20 This was a working report on differences, not a final. The problem=20 that the ECMP proposal intends to solve is defining a mechanism by=20 which an implementation that installs equal cost multipath routes, but=20 only advertises one route, can readvertise the multiple routes without=20 breaking policies. Its basic approach is to create synthetic AS-SETS=20 in the readvertisements. =20 Potential benefits of the technique include avoiding certain cases of=20 route reflector oscillation. The technique is consistent with=20 multiprotocol extensions, using the AFI/SAFI relevant to the routes it=20 is advertising: conventional IPv4 or VPN. It is not intended for load=20 splitting across different AS. =20 The consensus was that not enough WG members had read it for consensus. =20 =20 IPv6 over IPv4 MPLS (Francis LeFaucheur, presenter) --------------------------------------------------- The draft presents a technique, which will be coordinated with V6OPS=20 through the ADs, for providing IPv6 service over an existing IPv4 MPLS=20 cloud, without the cloud needing to be V6-aware. The proposed solution=20 is intended to require no protocll extensions (see=20 draft-ietf-l3vpn-bgp-ipv6). It carris labels in MP-BGP. The=20 requiriemens are stated in=20 =20 draft-ietf-v6ops-isp-scenarios-analysis-03.txt. =20 Draft 04 is underway, and will clarify some MUST/SHOULD terminology,=20 expand on the inter-AS cases, and add additional detail on security. Publication of this specification will involve coordinated documents=20 between V6OPS and IDR, consistent where possible and different where=20 necessary. For example, the V6OPS document will carry label SAFI/AFI=20 while the IDR document will carry VPN SAFI/AFI. =20 After the editorial changes are complete, the document will go out for=20 last call and implementation survey. =20 =20 AS Edge Confederations (Sue Hares) ---------------------------------- This was a discussion item; the I-D did not make the cutoff. The=20 technique described is a method for using dynamic capabilities at the=20 edge of AS confederations, with the confederation-AS typically in a=20 ring topology. The example was given of a confederation of=20 satellite-based confederation AS being accessed by an earth station. While the technique both is ad hoc and involves mobility, it is=20 different in applicability from MANET and mobile IP, since its quantum=20 of mobility is the AS, not either subnet or host. =20 This would typically be used in a low-bandwidth applkication where the=20 edge (i.e., non-confederation) AS lose connectivity with one AS in the=20 ring, but transfer connectivity to a differfent confederation-AS,=20 using dynamic capabilities exchange. As operational requirements=20 dictate, the non-confederation AS might switch back to the original=20 upstream AS. Additional security may be required for this=20 application. =20 Discussion followed. =20 John Scudder (): If you expect this change, why wait for dynamic=20 capabilities? Why not configure immediately? =20 Sue: We don't want to drop the associated peers =20 Peter Lothberg: Why not use an IGP? Sue answered that an IGP gives=20 insufficient policy control. =20 John Scudder: Pointed out that you cannot nest confederations,=20 limitiing applicability. Sue reitierated this is neither MANET nor=20 mobile IP. =20 =20 Chandra -- is confederation AS too small a level=20 of granularity? He asked why there could be additional security=20 requirements, and Sue pointed out that TCP neither encrypts nor=20 authenticates, and regular BGP security may be insufficient for some=20 tactical applications. =20 Peter Lothberg: Is the policy for inter-AS links, AS, or AS=20 confederation? WHat is the requirement? Sue replied the policy was=20 for the confederation. =20 Russ White: Suggested avoided the security cookie. He felt it might=20 be too ad hoc, and a general solution would be better. =20 John Scudder: agrees ad hoc may not be desirable -- worried about cloned AS. =20 Parantep (MCI): "neither confirm or deny IGP is aware", agreed to=20 by Sue. Application may involve multiple IGP. =20 Peter Lothberg: Asked Sue to confirm this proposal is to solve a real=20 problem, not just to demonstrate what could be done. =20 =20 Dampening --------- =20 Sue suggested there be WG list discussion of updates. =20 =20 ------_=_NextPart_001_01C4DED4.CD725352 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Please send in comments on the minutes for IETF = 61.

 

Sue

 

 

 

 

Sue Hares and Yakov Rekhter co-chaired the = meeting. Yakov issued an

initial OPEN, but a transmission failure of = the microphone system

caused his transport entity to time out. He retransmitted the OPEN and

successfully peered with the = attendees.

 

 

Old Business

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

 

Sue reviewed the status of the core BGP = documents under revision:

 

 - Border Gateway Protocol 4 (BGP-4) =

 - Definitions of Managed Objects for = the Fourth Version of

   Border Gateway Protocol (BGP-4) =

 - BGP-4 Protocol Analysis =

 - BGP Security Vulnerabilities Analysis =

 - Experience with the BGP-4 Protocol =

 - BGP MIB V1 implementation survey =

 - BGP 4 Implementation = Report

 

There is no new internal WG progress or = action

required; these are awaiting IESG = review.

 

Also in the approval process are Graceful = Restart and Extended

Communities, both as Proposed Standards, and = Cease Subcodes, to be a

Draft Standard.

 

The IESG is waiting for an implementation = report on confederations.

 

There was nothing to report on cooperative = route filtering, 4-octet AS

numbers, AS-based ORF, MIB 2, and AS-wide identifiers.

 

 

New Business

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

Equal Cost Multipath (Manav Bhatia, Joel = Halpern)

-------------------------------------------------=

 

This was a working report on differences, not = a final. The problem

that the ECMP proposal intends to solve is = defining a mechanism by

which an implementation that installs equal = cost multipath routes, but

only advertises one route, can readvertise = the multiple routes without

breaking policies. Its basic approach is to = create synthetic AS-SETS

in the = readvertisements.

 

Potential benefits of the technique include = avoiding certain cases of

route reflector oscillation. The technique is consistent with

multiprotocol extensions, using the AFI/SAFI relevant to the routes it

is advertising: conventional IPv4 or = VPN.  It is not intended for load

splitting across different = AS.

 

The consensus was that not enough WG members = had read it for consensus.

 

 

IPv6 over IPv4 MPLS (Francis LeFaucheur, = presenter)

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

The draft presents a technique, which will be coordinated with V6OPS

through the ADs, for providing IPv6 service = over an existing IPv4 MPLS

cloud, without the cloud needing to be = V6-aware. The proposed solution

is intended to require no protocll extensions = (see

draft-ietf-l3vpn-bgp-ipv6). It carris labels = in MP-BGP.  The

requiriemens are stated in =

 

  = draft-ietf-v6ops-isp-scenarios-analysis-03.txt.<= /p>

 

Draft 04 is underway, and will clarify some MUST/SHOULD terminology,

expand on the inter-AS cases, and add = additional detail on security.

Publication of this specification will = involve coordinated documents

between V6OPS and IDR, consistent where = possible and different where

necessary. For example, the V6OPS document = will carry label SAFI/AFI

while the IDR document will carry VPN = SAFI/AFI.

 

After the editorial changes are complete, the document will go out for

last call and implementation = survey.

 

 

AS Edge Confederations (Sue = Hares)

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

This was a discussion item; the I-D did not = make the cutoff. The

technique described is a method for using = dynamic capabilities at the

edge of AS confederations, with the = confederation-AS typically in a

ring topology. The example was given of a confederation of

satellite-based confederation AS being = accessed by an earth station.

While the technique both is ad hoc and = involves mobility, it is

different in applicability from MANET and = mobile IP, since its quantum

of mobility is the AS, not either subnet or = host.

 

This would typically be used in a = low-bandwidth applkication where the

edge (i.e., non-confederation) AS lose = connectivity with one AS in the

ring, but transfer connectivity to a = differfent confederation-AS,

using dynamic capabilities exchange. As = operational requirements

dictate, the non-confederation AS might = switch back to the original

upstream AS.  Additional security may be = required for this

application.

 

Discussion = followed.

 

John Scudder ():  If you expect this = change, why wait for dynamic

           &= nbsp;      capabilities? Why not configure immediately?

 

Sue: We don't want to drop the associated = peers

 

Peter Lothberg: Why not use an IGP? Sue = answered that an IGP gives

           &= nbsp;    insufficient policy = control.

 

John Scudder:  Pointed out that you = cannot nest confederations,

           &= nbsp;   limitiing applicability. Sue reitierated this is neither MANET nor

           &= nbsp;   mobile IP.

 

 

Chandra -- is confederation AS too small a = level

      of = granularity? He asked why there could be additional security

      requirements, = and Sue pointed out that TCP neither encrypts nor

      authenticates, = and regular BGP security may be insufficient for some

      tactical = applications.

 

Peter Lothberg:  Is the policy for = inter-AS links, AS, or AS

           &= nbsp;     confederation? WHat is the requirement?  Sue replied the policy was =

           &= nbsp;     for the = confederation.

 

Russ White:  Suggested avoided the = security  cookie. He felt it might

           &= nbsp; be too ad hoc, and a general solution would be better.

 

John Scudder: agrees ad hoc may not be = desirable -- worried about cloned AS.

 

Parantep (MCI): "neither confirm or deny = IGP is aware", agreed to

           &= nbsp;       by Sue. Application may = involve multiple IGP.

 

Peter Lothberg:  Asked Sue to confirm = this proposal is to solve a real

           &= nbsp;     problem, not just to demonstrate what could be done.

 

 

Dampening

---------

 

Sue suggested there be WG list discussion of updates.

 

 

------_=_NextPart_001_01C4DED4.CD725352-- --===============0154699101== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============0154699101==-- From idr-bounces@ietf.org Mon Dec 13 01:58:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18103; Mon, 13 Dec 2004 01:58:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdkII-0004ia-IL; Mon, 13 Dec 2004 02:06:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdk7r-00078K-At; Mon, 13 Dec 2004 01:56:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdk3l-0005oY-Ne for idr@megatron.ietf.org; Mon, 13 Dec 2004 01:51:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17443 for ; Mon, 13 Dec 2004 01:51:52 -0500 (EST) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdkBV-0004YG-Rb for idr@ietf.org; Mon, 13 Dec 2004 01:59:54 -0500 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id WAA21433; Sun, 12 Dec 2004 22:51:17 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 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: [Idr] MInutes for IDR Date: Sun, 12 Dec 2004 22:49:22 -0800 Message-ID: <7549C475A1F3CF47ABCA660BF44738B329C155@legolas.rs.riverstonenet.com> Thread-Topic: MInutes for IDR Thread-Index: AcTe1M1W6rWg0MNgQM+kkJPUpeMTcwCCxOAM From: "Bhatia, Manav" To: "Susan Hares" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: yakov@juniper.net X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Hi, There is a correction: > Equal Cost Multipath (Manav Bhatia, Joel Halpern) [clipped] > is advertising: conventional IPv4 or VPN. It is not intended for load = > splitting across different AS. This is incorrect. It *is* intended for load splitting across different = ASes. Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Dec 13 03:00:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07348; Mon, 13 Dec 2004 03:00:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdlGL-000641-6r; Mon, 13 Dec 2004 03:08:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdkzC-0003Ym-Ba; Mon, 13 Dec 2004 02:51:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdkuG-0002CO-Ad for idr@megatron.ietf.org; Mon, 13 Dec 2004 02:46:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06364 for ; Mon, 13 Dec 2004 02:46:07 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdl1x-0005iW-Dd for idr@ietf.org; Mon, 13 Dec 2004 02:54:10 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBD7jGb10708; Mon, 13 Dec 2004 09:45:22 +0200 Date: Mon, 13 Dec 2004 09:45:16 +0200 (EET) From: Pekka Savola To: Curtis Villamizar Subject: Re: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? In-Reply-To: <200412032151.iB3LpnSM004497@workhorse.faster-light.net> Message-ID: References: <200412032151.iB3LpnSM004497@workhorse.faster-light.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 On Fri, 3 Dec 2004, Curtis Villamizar wrote: > Anything that is not a WG item and is being considered for a WG item > is by definition new work for the WG and therefore it should be > determined that there is a requirement for it. I think those several > service providers should speak up for themselves if they are > interested in seeing this work progress. > > Having been on the provider side of this business in the past I know > that at times a vendor will approach a service provider with an idea > and if they provider doesn't bodily throw them out the door the vendor > counts them as "possibly interested" for the purpose of discussions > such as this. Therefore I'd like to see the providers speak for > themselves rather than the vendor speak and there is plenty of > precedence in the IETF for asking for that. I'll echo Curtis's concern. ATM has gone out so long time ago that I'd expect that the vast majority of serious SPs have already solved this problem without a real need for this mechanism. I'm not sure we want to add ATM hacks to BGP as well.. A couple of particular comments on the applicability text of the draft: To avoid manual provisioning of addresses, operators could provision point-to-point pseudo-wires between the ATM switches that directly connect to the MPLS core, and run PNNI routing and signaling on these pseudo-wires. ==> exactly, I'd suspect this has been done and continue to be done, and requires no special support at all. However, for several reasons that might be undesirable. Firstly, the ATM network islands may belong to different administrative domains. ==> this is an identical problem with the existing ATM cloud, i.e., introducing MPLS does not make it any worse. As it is, you'll already have to use static ATM routes or run them in a single ATM cloud. Secondly, even within one administrative domain, an operator might not want to create one single, large ATM network because of scaleability concerns. ==> again, this already applies to the existing ATM network, or you'll have to do the same manual config. Thirdly, the introduction of an MPLS core creates a topological challenge that does not exist in traditional ATM networks. The overlay approach results in a full mesh of O(N*N) PNNI routing adjacencies, where N is the number of ATM switches that directly connect to the MPLS core. Each ATM switch that is directly connected to the MPLS core has to deal with O(N) adjacencies, where N can be quite large, thereby imposing a scaling burden on its ATM control plane. ==> is the number of ATM clouds connected over MPLS really that great? If you are bothered by this scalability concern, you could also deploy a couple of ATM switches to keep down the number of adjacencies (similar to BGP route reflectors are used with BGP). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Dec 13 04:29:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15162; Mon, 13 Dec 2004 04:29:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdmdu-0008Mx-Db; Mon, 13 Dec 2004 04:37:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdmOs-0002ii-Ev; Mon, 13 Dec 2004 04:21:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdmEd-0007ru-SX for idr@megatron.ietf.org; Mon, 13 Dec 2004 04:11:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12760 for ; Mon, 13 Dec 2004 04:11:14 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdmMP-0007u2-8D for idr@ietf.org; Mon, 13 Dec 2004 04:19:18 -0500 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iBD9BCeY028526 for ; Mon, 13 Dec 2004 03:11:12 -0600 (CST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 13 Dec 2004 04:11:11 -0500 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'Pekka Savola'" , Curtis Villamizar Subject: RE: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? Date: Mon, 13 Dec 2004 04:10:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Pekka Savola wrote: > On Fri, 3 Dec 2004, Curtis Villamizar wrote: >> Anything that is not a WG item and is being considered for a WG item >> is by definition new work for the WG and therefore it should be >> determined that there is a requirement for it. I think those several >> service providers should speak up for themselves if they are >> interested in seeing this work progress. >> >> Having been on the provider side of this business in the past I know >> that at times a vendor will approach a service provider with an idea >> and if they provider doesn't bodily throw them out the door the >> vendor counts them as "possibly interested" for the purpose of >> discussions such as this. Therefore I'd like to see the providers >> speak for themselves rather than the vendor speak and there is >> plenty of precedence in the IETF for asking for that. > > I'll echo Curtis's concern. > > ATM has gone out so long time ago that I'd expect that the vast > majority of serious SPs have already solved this problem without a > real need for this mechanism. I'm not sure we want to add ATM hacks to > BGP as well.. I object against the use of the word "ATM hack". The draft represents a straightforward application of Multi-Protocol extensions for BGP. Draft-ietf-idr-rfc2858bis-06.txt says: "This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols". Now that we propose to use this to carry ATM routing information, it is suddenly a hack?? [snipped] _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Dec 13 06:00:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22126; Mon, 13 Dec 2004 06:00:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdo4L-0001sl-Iy; Mon, 13 Dec 2004 06:08:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdntJ-0005oT-Pi; Mon, 13 Dec 2004 05:57:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdns5-0005eX-RK for idr@megatron.ietf.org; Mon, 13 Dec 2004 05:56:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21800 for ; Mon, 13 Dec 2004 05:56:03 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdnzr-0001ns-77 for idr@ietf.org; Mon, 13 Dec 2004 06:04:09 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBDAtLA14786; Mon, 13 Dec 2004 12:55:21 +0200 Date: Mon, 13 Dec 2004 12:55:21 +0200 (EET) From: Pekka Savola To: "Busschbach, Peter B (Peter)" Subject: RE: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Mon, 13 Dec 2004, Busschbach, Peter B (Peter) wrote: > I object against the use of the word "ATM hack". The draft > represents a straightforward application of Multi-Protocol > extensions for BGP. Draft-ietf-idr-rfc2858bis-06.txt says: "This > document defines extensions to BGP-4 to enable it to carry routing > information for multiple Network Layer protocols". Now that we > propose to use this to carry ATM routing information, it is suddenly > a hack?? Depends on what you call 'Network layer', I guess :). Network layer typically refers to the layer of "IP". From the perspective of IP, ATM routing information is at the link-layer. This would seem the similar to propagating Ethernet MAC addresses of VPLSs (for example) in NLRIs. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Dec 13 06:47:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26280; Mon, 13 Dec 2004 06:47:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdoo7-0002wm-Rp; Mon, 13 Dec 2004 06:56:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdoeZ-0000mJ-Na; Mon, 13 Dec 2004 06:46:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdobX-00007o-UO for idr@megatron.ietf.org; Mon, 13 Dec 2004 06:43:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25864 for ; Mon, 13 Dec 2004 06:43:01 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdojK-0002pX-Gj for idr@ietf.org; Mon, 13 Dec 2004 06:51:08 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 13 Dec 2004 12:49:57 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBDBgQGb004211; Mon, 13 Dec 2004 12:42:27 +0100 (MET) Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Dec 2004 12:42:26 +0100 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: [Idr] MInutes for IDR Date: Mon, 13 Dec 2004 12:38:52 +0100 Message-ID: Thread-Topic: [Idr] MInutes for IDR Thread-Index: AcTe1M1W6rWg0MNgQM+kkJPUpeMTcwCKb+IA From: "Francois Le Faucheur \(flefauch\)" To: "Susan Hares" X-OriginalArrivalTime: 13 Dec 2004 11:42:26.0705 (UTC) FILETIME=[D1AE1010:01C4E108] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: yakov@juniper.net, "Francois Le Faucheur \(flefauch\)" , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Hi Sue, =20 Comments on the minutes re bgp-tunnel: IPv6 over IPv4 MPLS (Francis LeFaucheur, presenter) --------------------------------------------------- Right spelling for my name is "Francois Le Faucheur" I suggest listing the draft being discussed (draft-ooms-v6ops-bgp-tunnel-04.txt) The draft presents a technique, which will be coordinated with V6OPS=20 s/which will be/which has been/ through the ADs, for providing IPv6 service over an existing IPv4 MPLS=20 cloud, without the cloud needing to be V6-aware. The proposed solution=20 is intended to require no protocll extensions (see=20 s/is intented to require no/does not require any/ draft-ietf-l3vpn-bgp-ipv6). It carris labels in MP-BGP. The=20 Please remove the reference to draft-ietf-l3vpn-bgp-ipv6 above. The stamement about not requiring protocol extensions in bgp-tunnel has nothing to do with l3vpn-bgp-ipv6. requiriemens are stated in=20 =20 draft-ietf-v6ops-isp-scenarios-analysis-03.txt. =20 Draft 04 is underway, and will clarify some MUST/SHOULD terminology,=20 expand on the inter-AS cases, and add additional detail on security. There is some confusion here. The 03-->04 changes related to the bgp-tunnel draft (not to isp-scenario). These changes have already been done in bgp-tunnel-04.=20 So the above should read: "bgp-tunnel-04 includes the following changes over the previous version: clarify some MUST/SHOULD terminology, expand on the inter-AS cases, and add additional detail on security." Publication of this specification will involve coordinated documents=20 between V6OPS and IDR, consistent where possible and different where=20 necessary. For example, the V6OPS document will carry label SAFI/AFI=20 while the IDR document will carry VPN SAFI/AFI. This paragraph mixes everything up. It should read: "draft-ooms-v6ops-bgp-tunnel-04.txt specifies support for global IPv6 reachability services while draft-ietf-l3vpn-bgp-ipv6-03.txt specifies support for IPv6 VPN services. The two documents are consistent wherever they can be and are only different where needed (eg bgp-tunnel uses "labeled IPv6" AFI/SAFI while l3vpn-bgp-ipv6 uses "VPN-IPv6" AFI/SAFI). =20 After the editorial changes are complete, the document will go out for=20 last call and implementation survey. =20 I believe what was agreed was that the document was ready for Last Call and the Last Call was going to be issued right after Wash IETF. So I suggest replacing previous paragraph with something like: "The document will go out for Last Call after this meeting". Thank you Francois _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Dec 13 09:20:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12487; Mon, 13 Dec 2004 09:20:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdrC6-0007GZ-QM; Mon, 13 Dec 2004 09:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdqlP-00055i-TQ; Mon, 13 Dec 2004 09:01:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdqan-0000Ke-1K for idr@megatron.ietf.org; Mon, 13 Dec 2004 08:50:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09078 for ; Mon, 13 Dec 2004 08:50:23 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdqiY-0006EB-Vk for idr@ietf.org; Mon, 13 Dec 2004 08:58:30 -0500 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iBDDoJZb026404 for ; Mon, 13 Dec 2004 07:50:19 -0600 (CST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 13 Dec 2004 08:50:19 -0500 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'Pekka Savola'" Subject: RE: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? Date: Mon, 13 Dec 2004 08:50:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Pekka Savola wrote: > On Mon, 13 Dec 2004, Busschbach, Peter B (Peter) wrote: >> I object against the use of the word "ATM hack". The draft >> represents a straightforward application of Multi-Protocol >> extensions for BGP. Draft-ietf-idr-rfc2858bis-06.txt says: "This >> document defines extensions to BGP-4 to enable it to carry routing >> information for multiple Network Layer protocols". Now that we >> propose to use this to carry ATM routing information, it is suddenly >> a hack?? > > Depends on what you call 'Network layer', I guess :). Network layer > typically refers to the layer of "IP". It is not the first time that I notice that IETF members use the word "multi-service" when in fact they are only interested in IP. It always reminds me of the American habit to call the winner of a national sports championship the "world champion" :-) ATM is both a link layer and a network layer protocol. ATM uses routing protocols that are very similar to IP routing protocols. The main difference between IP and ATM is that IP is connectionless and ATM is connection-oriented. > From the perspective of IP, > ATM routing information is at the link-layer. This would seem the > similar to propagating Ethernet MAC addresses of VPLSs (for example) > in NLRIs. Yes, it would be similar, if Ethernet would use routing protocols to advertise MAC addresses. However, Ethernet uses learning bridges in a loop-free topology and is in that respect different from both IP and ATM. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Dec 13 12:57:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03705; Mon, 13 Dec 2004 12:57:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdua8-0004vY-Kq; Mon, 13 Dec 2004 13:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CduQE-0005Jv-QU; Mon, 13 Dec 2004 12:55:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CduEM-0008VX-Bx for idr@megatron.ietf.org; Mon, 13 Dec 2004 12:43:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01795 for ; Mon, 13 Dec 2004 12:43:27 -0500 (EST) Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CduM3-0004Mv-6I for idr@ietf.org; Mon, 13 Dec 2004 12:51:37 -0500 Received: (qmail 90680 invoked from network); 13 Dec 2004 17:43:17 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 13 Dec 2004 17:43:17 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iBDHh538008624; Mon, 13 Dec 2004 12:43:05 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200412131743.iBDHh538008624@workhorse.faster-light.net> To: "Busschbach, Peter B (Peter)" Subject: Re: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? In-reply-to: Your message of "Mon, 13 Dec 2004 08:50:10 EST." Date: Mon, 13 Dec 2004 12:43:05 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: idr@ietf.org, "'Pekka Savola'" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da In message "Busschbach, Peter B (Peter)" writes: > > Pekka Savola wrote: > > On Mon, 13 Dec 2004, Busschbach, Peter B (Peter) wrote: > >> I object against the use of the word "ATM hack". The draft > >> represents a straightforward application of Multi-Protocol > >> extensions for BGP. Draft-ietf-idr-rfc2858bis-06.txt says: "This > >> document defines extensions to BGP-4 to enable it to carry routing > >> information for multiple Network Layer protocols". Now that we > >> propose to use this to carry ATM routing information, it is suddenly > >> a hack?? > > > > Depends on what you call 'Network layer', I guess :). Network layer > > typically refers to the layer of "IP". > > It is not the first time that I notice that IETF members use the word > "multi-service" when in fact they are only interested in IP. It always > reminds me of the American habit to call the winner of a national > sports championship the "world champion" :-) > > ATM is both a link layer and a network layer protocol. ATM uses > routing protocols that are very similar to IP routing protocols. The > main difference between IP and ATM is that IP is connectionless and > ATM is connection-oriented. > > > From the perspective of IP, > > ATM routing information is at the link-layer. This would seem the > > similar to propagating Ethernet MAC addresses of VPLSs (for example) > > in NLRIs. > > Yes, it would be similar, if Ethernet would use routing protocols to > advertise MAC addresses. However, Ethernet uses learning bridges in a > loop-free topology and is in that respect different from both IP and > ATM. We heard that ATM would dominate the world in 1993 and end-user TCP would just have to learn to work over ATM. We heard that all IP would run over ATM in the mid-1990s. None of this came from IP providers, mostly from ATM vendors with some sort of credibility attached to it through statements passed through the ATM Forum. I haven't seen a single message from a provider supporting this. I don't think I've seen a single message from a non-author supporting this as a WG item. Yes, in principal PNNI is like an IP IGP and BGP could be its exterior routing protocol. ATM itself is end-to-end connection oriented and ATM SVC service has never been offerred by any major provider so arguments of scaling due to not having an exterior routing protocol completely fall apart. It is not unreasonable for an IETF WG to demand strong indication that there is a clear requirement for anything that the WG is asked to consider as a WG work item. We've asked and there has been no indication from any provider of any need for this. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Dec 13 13:42:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07483; Mon, 13 Dec 2004 13:42:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdvGu-0005xK-2D; Mon, 13 Dec 2004 13:50:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdv2O-000082-MZ; Mon, 13 Dec 2004 13:35:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CduuN-0007A8-R0 for idr@megatron.ietf.org; Mon, 13 Dec 2004 13:26:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06309 for ; Mon, 13 Dec 2004 13:26:52 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdv2D-0005cf-ST for idr@ietf.org; Mon, 13 Dec 2004 13:35:03 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 13 Dec 2004 10:26:26 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBDIQCm4013448; Mon, 13 Dec 2004 10:26:13 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AZT76940; Mon, 13 Dec 2004 10:35:47 -0800 (PST) Message-Id: <6.2.0.14.2.20041213092620.06b790e8@mira-sjc5-b.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 13 Dec 2004 10:05:28 -0800 To: Pekka Savola From: Fred Baker Subject: RE: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 At 12:55 PM 12/13/04 +0200, Pekka Savola wrote: >Depends on what you call 'Network layer', I guess :). Network layer >typically refers to the layer of "IP". From the perspective of IP, ATM >routing information is at the link-layer. This would seem the similar to >propagating Ethernet MAC addresses of VPLSs (for example) in NLRIs. I agree that this terminology is generally used, but it is in fact incorrect. Lets take an aside into the definitions and meanings of words. Going back to the definitions of the terms, a "Link" is a physical connection between two Nodes on a network, and the Link Layer is the communications layer that provides for the reliable transfer of information across a Link. Both of those definitions, I believe, derive from Stallings, 1991, and reflect the preoccupation of the time with reliability at the link layer. In other words, the physical layer is something you can touch or otherwise describe in terms of physics and includes the mechanism for encoding data (often binary but not necessarily; see QPSK), and the link layer separates the exchanged data into noise and signals exchanged between physically connected systems. The network layer is by definition a layer which creates virtual connectivity (circuits or connectionless routes as appropriate) out of a sequence of zero or more link layer connections between nodes in the graph. IP is called the "Internet Protocol" because it connects networks (think for a moment about what "inter" and "network" mean etymologically). These networks may be pure IP networks, but (surprise) may be switched LANs over which IP data is flowing, ATM networks, Frame Relay Networks, or a long list of other kinds of networks. You'll ask why we call these "link layer networks". Well, there are two reasons. One is that ballpark 1979 the Internet community decided to switch from BBN 1822 to X.25 as an access technology into the ARPANET, and observed (correctly) that X.25 described what happened at a user-to-network (UNI) or network-to-network (NNI) interface, but did not describe what happened in the network itself. As such, they had trouble thinking of it as a real communication layer, but rather wanted to treat it only as the UNI or NNI. They therefore (tweaking noses in CCITT immensely) relegated it to a layer beneath them. Five years later, IEEE wanted to define Ethernet and Token Ring Bridging (as "switching" was then called), and (since the network layer belonged to ANSI by prior agreement) called theirs a "link layer network". It did, after all, use the link layer header... But trust me, an ATM network is a network, and by definition belongs in what I call the "Intranet" sublayer of the Network Layer of the OSI Reference Model. What distinguishes the various technologies at this sublayer as much as anything is that they are designed to connect things that ought to be connected, and are operated by a single administration. The Internet Protocol connects disparate such networks and the hosts in them end to end, and is operated by disparate administrations with disparate intents and policies. The Internet is a network of networks, and many of those networks are not fundamentally IP networks, but only carry IP as an overlay. Which is why we can deploy a different Internet protocol over the same network... _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Dec 14 12:38:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24664; Tue, 14 Dec 2004 12:38:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeGl5-0008MC-0L; Tue, 14 Dec 2004 12:46:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeGSL-0008I2-8H; Tue, 14 Dec 2004 12:27:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeGD4-0002g0-E3 for idr@megatron.ietf.org; Tue, 14 Dec 2004 12:11:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22498 for ; Tue, 14 Dec 2004 12:11:36 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeGL6-0007d6-E1 for idr@ietf.org; Tue, 14 Dec 2004 12:19:58 -0500 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id iBEHB2XJ023053 for ; Tue, 14 Dec 2004 11:11:03 -0600 (CST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 14 Dec 2004 12:11:02 -0500 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'curtis@faster-light.net'" Subject: RE: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? Date: Tue, 14 Dec 2004 12:10:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: idr@ietf.org, "'Pekka Savola'" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Curtis Villamizar wrote: [snipped] > Yes, in principal PNNI is like an IP IGP and BGP could be its exterior > routing protocol. ATM itself is end-to-end connection oriented and > ATM SVC service has never been offerred by any major provider so > arguments of scaling due to not having an exterior routing protocol > completely fall apart. This has nothing to do with SVCs. The draft proposes to solve routing issues that might arise when an MPLS network is used to interconnect previously independent ATM islands. Signaling (whether it is to set up SVCs or, as is much more common, SPVCs) has its own issues, but is not necessarily impacted by the use of an MPLS core network and is completely independent of the routing protocols used. > > It is not unreasonable for an IETF WG to demand strong indication that > there is a clear requirement for anything that the WG is asked to > consider as a WG work item. We've asked and there has been no > indication from any provider of any need for this. I too am anxiously waiting for Service Providers who might benefit from the solution to speak up. It should be noted, though, that the people who run ATM networks usually don't subscribe to the IDR mailing list and therefore might not as readily respond as one would hope. > > Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Dec 14 13:20:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01021; Tue, 14 Dec 2004 13:20:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeHQ8-0001Fn-87; Tue, 14 Dec 2004 13:29:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeHEe-0003Tv-U2; Tue, 14 Dec 2004 13:17:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeH9Q-0002hT-6B for idr@megatron.ietf.org; Tue, 14 Dec 2004 13:11:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28701 for ; Tue, 14 Dec 2004 13:11:53 -0500 (EST) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CeHHR-00010H-HD for idr@ietf.org; Tue, 14 Dec 2004 13:20:16 -0500 Received: (qmail 93124 invoked from network); 14 Dec 2004 18:11:49 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 14 Dec 2004 18:11:49 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iBEIBNw2012589; Tue, 14 Dec 2004 13:11:23 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200412141811.iBEIBNw2012589@workhorse.faster-light.net> To: "Busschbach, Peter B (Peter)" Subject: Re: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? In-reply-to: Your message of "Tue, 14 Dec 2004 12:10:51 EST." Date: Tue, 14 Dec 2004 13:11:23 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: idr@ietf.org, "'Pekka Savola'" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 In message "Busschbach, Peter B (Peter)" writes: > > Curtis Villamizar wrote: > [snipped] > > > Yes, in principal PNNI is like an IP IGP and BGP could be its exterior > > routing protocol. ATM itself is end-to-end connection oriented and > > ATM SVC service has never been offerred by any major provider so > > arguments of scaling due to not having an exterior routing protocol > > completely fall apart. > > This has nothing to do with SVCs. The draft proposes to solve routing > issues that might arise when an MPLS network is used to interconnect > previously independent ATM islands. Signaling (whether it is to set up > SVCs or, as is much more common, SPVCs) has its own issues, but is not > necessarily impacted by the use of an MPLS core network and is > completely independent of the routing protocols used. My point was that scaling is terrible if you need PVCs because you must either settle for partial connectivity or an unscalable full mesh. If partial connectivity is the goal, then ATM becomes just a VPN technology. > > It is not unreasonable for an IETF WG to demand strong indication that > > there is a clear requirement for anything that the WG is asked to > > consider as a WG work item. We've asked and there has been no > > indication from any provider of any need for this. > > > I too am anxiously waiting for Service Providers who might benefit > from the solution to speak up. It should be noted, though, that the > people who run ATM networks usually don't subscribe to the IDR mailing > list and therefore might not as readily respond as one would hope. And they are all too clueless to figure out how to subscribe? If a provider intending to use this does exist, you might want to mention that this probably won't happen in the IETF if they remain silent. The argument that demand exists but the providers are too shy doesn't count for anything. Nor does the argument that they really need this but they don't yet really know that they really need this. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Dec 17 01:57:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01760; Fri, 17 Dec 2004 01:57:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfCBW-0001qR-9j; Fri, 17 Dec 2004 02:05:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfC0u-0004h8-KA; Fri, 17 Dec 2004 01:54:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfBzW-0004JE-Rb for idr@megatron.ietf.org; Fri, 17 Dec 2004 01:53:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01386 for ; Fri, 17 Dec 2004 01:53:29 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfC87-0001jY-9U for idr@ietf.org; Fri, 17 Dec 2004 02:02:23 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id iBH6qubr005559 for ; Fri, 17 Dec 2004 00:52:57 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 17 Dec 2004 12:22:55 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D20C1078BD@ii0015exch002u.iprc.lucent.com> From: "P, Sridhar (Sridhar)" To: "'idr@ietf.org'" Date: Fri, 17 Dec 2004 12:22:50 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [Idr] ORGIN priority & and Routing Protocol priority.. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1568141344==" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1568141344== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E404.702516DC" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4E404.702516DC Content-Type: text/plain; charset="iso-8859-1" orgin : the priority in assinging the orgin of the route entry is IGP EGP and INCOMPLETE. the preference among the routing protocols are EGP IGP .. it is contridicting...like (AS-X)------(AS-1)------(AS-2) Net A is adv from AS-X to AS-1 as a ebgp route. i have Net A learned as igp in AS-1 (via IGP) so while updating into bgp it updates as IGP orgin because of orgin priority.... and if packet comes to AS-1 to reach AS-X it prefers AS-x path because of route protocol priority... so both are contridicting...can someone explain this.... Sridhar P * Lucent Technologies MultiService Switching * 91-80-51191190 * sridharp@lucent.com ------_=_NextPart_001_01C4E404.702516DC Content-Type: text/html; charset="iso-8859-1"
orgin :
the priority in assinging the orgin of the route entry is
IGP
EGP
and INCOMPLETE.
 
the preference among the routing protocols are
EGP
IGP ..
 

it is contridicting...like

(AS-X)------(AS-1)------(AS-2)

Net A is adv from AS-X to AS-1 as a ebgp route.
i have Net A learned as igp in AS-1 (via IGP) so  while updating into bgp it updates as IGP orgin because of orgin priority....
and if packet comes to AS-1 to reach AS-X it prefers AS-x path because of route protocol priority...
so both are contridicting...can someone explain this....
 
Sridhar P
m Lucent Technologies MultiService Switching
( 91-80-51191190
* sridharp@lucent.com
 
------_=_NextPart_001_01C4E404.702516DC-- --===============1568141344== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============1568141344==-- From idr-bounces@ietf.org Fri Dec 17 10:40:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28975; Fri, 17 Dec 2004 10:39:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfKLh-0000B8-UR; Fri, 17 Dec 2004 10:48:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfK8w-0006Ky-0t; Fri, 17 Dec 2004 10:35:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfJvw-00027V-T2 for idr@megatron.ietf.org; Fri, 17 Dec 2004 10:22:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27214 for ; Fri, 17 Dec 2004 10:22:18 -0500 (EST) From: nabil.n.bitar@verizon.com Received: from irvmail2.bdi.gte.com ([192.76.80.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfK4Z-000856-R4 for idr@ietf.org; Fri, 17 Dec 2004 10:31:17 -0500 Received: from smtpftw.interwan.gte.com ([138.83.130.53]) by irvmail2.bdi.gte.com (8.12.10/8.12.10) with ESMTP id iBHFLhZb009406; Fri, 17 Dec 2004 10:21:44 -0500 (EST) Received: from usinftwiccmms03.ent.verizon.com (ftwmms03a.interwan.gte.com [138.83.138.66]) by smtpftw.interwan.gte.com (8.12.10/8.12.10) with ESMTP id iBHFLbYq012114; Fri, 17 Dec 2004 10:21:37 -0500 (EST) Received: from 138.83.34.22 by usinftwiccmms03.ent.verizon.com with ESMTP (SMTP Relay); Fri, 17 Dec 2004 10:21:32 -0500 X-Server-Uuid: 2F91DA65-DB13-41BC-8809-D657BCBC59D7 Received: from dwsmtp01.core.verizon.com (dwmail21.interwan.gte.com [138.83.36.17]) by coregate1.interwan.gte.com (8.12.10/8.12.10) with ESMTP id iBHFLVfQ023066; Fri, 17 Dec 2004 09:21:31 -0600 (CST) To: ck@juniper.net, busschbach@lucent.com, chmetz@cisco.com X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Fri, 17 Dec 2004 10:21:29 -0500 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.0.2CF2|July 23, 2003) at 12/17/2004 09:21:30 MIME-Version: 1.0 X-WSS-ID: 6DDC26F62A41205902-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: [Idr] draft-ck-bgp-atm-nlri-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Hi, The draft looks good. I just have few comments: - "the introduction of an MPLS core creates a topological challenge that does not exist in traditional ATM networks. The overlay approach results in a full mesh of O(N*N) PNNI routing adjacencies, where N is the number of ATM switches that directly connect to the MPLS core. Each ATM switch that is directly connected to the MPLS core has to deal with O(N) adjacencies, where N can be quite large, thereby imposing a scaling burden on its ATM control plane." This is not necesarily required. You can have a partial mesh of PNNI trunks over MPLS PWs, However, this will lead to having the ATM switches terminating these PNNI trunnks to become transit That is they will have to do MPLS PW-ATM- MPLS PW interworking. what is your view on that? However, I do think that PNNI adjacencies in this case (although this is not restricted to PNNI) adjacencies are a scalability factor and if you are interconnecting a large set of ATM clouds and you want to have direct reachability among these clouds without using another cloud or the border of another cloud as transit nodes for various reasons, the number of PNNI adjacencies will become a factor that is cofounded with the size of the network. Having the capability to alleviate this problem by distributing ATM reachability via BGP is and requiring a switch to have one, two or few BGP peering sessions with two or more route reflectors instead of a PNNI adjacency with every other switch is an advantage although this shifts some of this load to the RR. - The next hop address for an NLRI: you mention it can be any IPv4, IPv6 or NSAP address. Do you think that it makes sense to require it to be an IP address only? It seems to me reasonable to do that . Is there is need to have an NSAP address? In addition, it is not stated clearly how the next hop address would be encoded. Wouldn't this be dependent on the address family? - ATM reachability type: doesn't this have to be assigned by IANA? - Site of origin attribute: you leave this ptional. Is it possible to elaborate on the need for it and what is the consequence if not included. - "The RD used by a PE must be unique, and can either be preconfigured or auto-generated based on PE's attributes like configured autonomous system (AS) and IP addresses." RD containing IP address depends on whether the AS is 4 bytes or 2 bytes. Thanks, Nabil _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Dec 17 16:49:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15466; Fri, 17 Dec 2004 16:49:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfQ7P-0007Id-I2; Fri, 17 Dec 2004 16:58:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfPea-0000gY-Hi; Fri, 17 Dec 2004 16:28:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfPFN-0007ae-Rt for idr@megatron.ietf.org; Fri, 17 Dec 2004 16:02:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06071 for ; Fri, 17 Dec 2004 16:02:43 -0500 (EST) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CfPNt-00045y-R7 for idr@ietf.org; Fri, 17 Dec 2004 16:11:45 -0500 Received: (qmail 72935 invoked from network); 17 Dec 2004 21:02:23 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 17 Dec 2004 21:02:23 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iBHL1IqG024330; Fri, 17 Dec 2004 16:01:18 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200412172101.iBHL1IqG024330@workhorse.faster-light.net> To: "P, Sridhar (Sridhar)" Subject: Re: [Idr] ORGIN priority & and Routing Protocol priority.. In-reply-to: Your message of "Fri, 17 Dec 2004 12:22:50 +0530." <6733C768256DEC42A72BAFEFA9CF06D20C1078BD@ii0015exch002u.iprc.lucent.com> Date: Fri, 17 Dec 2004 16:01:18 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "'idr@ietf.org'" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c In message <6733C768256DEC42A72BAFEFA9CF06D20C1078BD@ii0015exch002u.iprc.lucent.com> "P, Sridhar (Sridhar)" writes: > > orgin : > the priority in assinging the orgin of the route entry is > IGP > EGP > and INCOMPLETE. > > the preference among the routing protocols are > EGP > IGP .. > > > it is contridicting...like > > (AS-X)------(AS-1)------(AS-2) > > Net A is adv from AS-X to AS-1 as a ebgp route. > i have Net A learned as igp in AS-1 (via IGP) so while updating into bgp it > updates as IGP orgin because of orgin priority.... > and if packet comes to AS-1 to reach AS-X it prefers AS-x path because of > route protocol priority... > so both are contridicting...can someone explain this.... > > Sridhar P > * Lucent Technologies MultiService Switching > * 91-80-51191190 > * sridharp@lucent.com Your routing policy should be set so that you should never repair an IGP fault with routes learned by BGP. The typical use of the above is if you advertise a single homed customer's route which is a static in your IGP you also announce the same static with BGP communities into IBGP. The border routers should prefer the IBGP route in order to be able to use the BGP communities to make use of BGP export policy based on BGP communities. Announcing an IGP route into IBGP was initially considered an abuse of BGP but it had the practical application of being able to carry BGP communities so the practice stuck. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Dec 20 16:22:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08981; Mon, 20 Dec 2004 16:22:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgV8s-0004zt-Am; Mon, 20 Dec 2004 16:32:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgUjB-0000lo-Be; Mon, 20 Dec 2004 16:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgUWi-0002s3-Bc; Mon, 20 Dec 2004 15:53:08 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03468; Mon, 20 Dec 2004 15:53:06 -0500 (EST) Message-Id: <200412202053.PAA03468@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 20 Dec 2004 15:53:06 -0500 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-avoid-transition-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Avoid BGP Best Path Transitions from One External to Another Author(s) : E. Chen, S. Sangli Filename : draft-ietf-idr-avoid-transition-01.txt Pages : 7 Date : 2004-12-20 In this document we propose a revision to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed revision would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external paths from one router contribute to the churn. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-avoid-transition-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-idr-avoid-transition-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-idr-avoid-transition-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: <2004-12-20154842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-avoid-transition-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-avoid-transition-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-20154842.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Tue Dec 21 16:04:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21565; Tue, 21 Dec 2004 16:04:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgrKP-0008NT-TF; Tue, 21 Dec 2004 16:13:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgqpa-0006uJ-UT; Tue, 21 Dec 2004 15:42:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgqoW-0006TE-PC; Tue, 21 Dec 2004 15:41:00 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17688; Tue, 21 Dec 2004 15:40:58 -0500 (EST) Message-Id: <200412212040.PAA17688@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 21 Dec 2004 15:40:58 -0500 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-as4bytes-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP support for four-octet AS number space Author(s) : Q. Vohra, E. Chen Filename : draft-ietf-idr-as4bytes-09.txt Pages : 9 Date : 2004-12-21 Currently the Autonomous System number is encoded in BGP [BGP] as a two-octets field. This document describes extensions to BGP to carry the Autonomous System number as a four-octets field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-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-idr-as4bytes-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-idr-as4bytes-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: <2004-12-21160844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as4bytes-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-as4bytes-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-21160844.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Tue Dec 21 16:07:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22400; Tue, 21 Dec 2004 16:07:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgrNZ-0000DS-Ul; Tue, 21 Dec 2004 16:17:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgqpd-0006vG-Rr; Tue, 21 Dec 2004 15:42:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgqog-0006Wn-4u; Tue, 21 Dec 2004 15:41:10 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17702; Tue, 21 Dec 2004 15:41:08 -0500 (EST) Message-Id: <200412212041.PAA17702@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 21 Dec 2004 15:41:08 -0500 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-route-filter-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Cooperative Route Filtering Capability for BGP-4 Author(s) : E. Chen, Y. Rekhter Filename : draft-ietf-idr-route-filter-11.txt Pages : 12 Date : 2004-12-21 This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-11.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-idr-route-filter-11.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-idr-route-filter-11.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: <2004-12-21160850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-filter-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-filter-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-21160850.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA07839 for ; Tue, 21 Dec 2004 16:07:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgqpd-0006vG-Pf; Tue, 21 Dec 2004 15:42:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgqog-0006Wn-4u; Tue, 21 Dec 2004 15:41:10 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17702; Tue, 21 Dec 2004 15:41:08 -0500 (EST) Message-Id: <200412212041.PAA17702@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 21 Dec 2004 15:41:08 -0500 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-route-filter-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-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 Inter-Domain Routing Working Group of the IETF. Title : Cooperative Route Filtering Capability for BGP-4 Author(s) : E. Chen, Y. Rekhter Filename : draft-ietf-idr-route-filter-11.txt Pages : 12 Date : 2004-12-21 This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-11.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-idr-route-filter-11.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-idr-route-filter-11.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: <2004-12-21160850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-filter-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-filter-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-21160850.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA07817 for ; Tue, 21 Dec 2004 16:04:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgqpa-0006uJ-RS; Tue, 21 Dec 2004 15:42:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgqoW-0006TE-PC; Tue, 21 Dec 2004 15:41:00 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17688; Tue, 21 Dec 2004 15:40:58 -0500 (EST) Message-Id: <200412212040.PAA17688@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 21 Dec 2004 15:40:58 -0500 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-as4bytes-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-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 Inter-Domain Routing Working Group of the IETF. Title : BGP support for four-octet AS number space Author(s) : Q. Vohra, E. Chen Filename : draft-ietf-idr-as4bytes-09.txt Pages : 9 Date : 2004-12-21 Currently the Autonomous System number is encoded in BGP [BGP] as a two-octets field. This document describes extensions to BGP to carry the Autonomous System number as a four-octets field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-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-idr-as4bytes-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-idr-as4bytes-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: <2004-12-21160844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as4bytes-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-as4bytes-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-21160844.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA24483 for ; Mon, 20 Dec 2004 16:22:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgUjB-0000lo-8B; Mon, 20 Dec 2004 16:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgUWi-0002s3-Bc; Mon, 20 Dec 2004 15:53:08 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03468; Mon, 20 Dec 2004 15:53:06 -0500 (EST) Message-Id: <200412202053.PAA03468@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 20 Dec 2004 15:53:06 -0500 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-avoid-transition-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-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 Inter-Domain Routing Working Group of the IETF. Title : Avoid BGP Best Path Transitions from One External to Another Author(s) : E. Chen, S. Sangli Filename : draft-ietf-idr-avoid-transition-01.txt Pages : 7 Date : 2004-12-20 In this document we propose a revision to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed revision would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external paths from one router contribute to the churn. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-avoid-transition-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-idr-avoid-transition-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-idr-avoid-transition-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: <2004-12-20154842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-avoid-transition-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-avoid-transition-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-20154842.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA11947 for ; Fri, 17 Dec 2004 16:49:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfPea-0000gY-Bz; Fri, 17 Dec 2004 16:28:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfPFN-0007ae-Rt for idr@megatron.ietf.org; Fri, 17 Dec 2004 16:02:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06071 for ; Fri, 17 Dec 2004 16:02:43 -0500 (EST) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CfPNt-00045y-R7 for idr@ietf.org; Fri, 17 Dec 2004 16:11:45 -0500 Received: (qmail 72935 invoked from network); 17 Dec 2004 21:02:23 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 17 Dec 2004 21:02:23 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iBHL1IqG024330; Fri, 17 Dec 2004 16:01:18 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200412172101.iBHL1IqG024330@workhorse.faster-light.net> To: "P, Sridhar (Sridhar)" Subject: Re: [Idr] ORGIN priority & and Routing Protocol priority.. In-reply-to: Your message of "Fri, 17 Dec 2004 12:22:50 +0530." <6733C768256DEC42A72BAFEFA9CF06D20C1078BD@ii0015exch002u.iprc.lucent.com> Date: Fri, 17 Dec 2004 16:01:18 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "'idr@ietf.org'" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org In message <6733C768256DEC42A72BAFEFA9CF06D20C1078BD@ii0015exch002u.iprc.lucent.com> "P, Sridhar (Sridhar)" writes: > > orgin : > the priority in assinging the orgin of the route entry is > IGP > EGP > and INCOMPLETE. > > the preference among the routing protocols are > EGP > IGP .. > > > it is contridicting...like > > (AS-X)------(AS-1)------(AS-2) > > Net A is adv from AS-X to AS-1 as a ebgp route. > i have Net A learned as igp in AS-1 (via IGP) so while updating into bgp it > updates as IGP orgin because of orgin priority.... > and if packet comes to AS-1 to reach AS-X it prefers AS-x path because of > route protocol priority... > so both are contridicting...can someone explain this.... > > Sridhar P > * Lucent Technologies MultiService Switching > * 91-80-51191190 > * sridharp@lucent.com Your routing policy should be set so that you should never repair an IGP fault with routes learned by BGP. The typical use of the above is if you advertise a single homed customer's route which is a static in your IGP you also announce the same static with BGP communities into IBGP. The border routers should prefer the IBGP route in order to be able to use the BGP communities to make use of BGP export policy based on BGP communities. Announcing an IGP route into IBGP was initially considered an abuse of BGP but it had the practical application of being able to carry BGP communities so the practice stuck. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA08758 for ; Fri, 17 Dec 2004 10:39:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfK8v-0006Ky-Tz; Fri, 17 Dec 2004 10:35:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfJvw-00027V-T2 for idr@megatron.ietf.org; Fri, 17 Dec 2004 10:22:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27214 for ; Fri, 17 Dec 2004 10:22:18 -0500 (EST) From: nabil.n.bitar@verizon.com Received: from irvmail2.bdi.gte.com ([192.76.80.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfK4Z-000856-R4 for idr@ietf.org; Fri, 17 Dec 2004 10:31:17 -0500 Received: from smtpftw.interwan.gte.com ([138.83.130.53]) by irvmail2.bdi.gte.com (8.12.10/8.12.10) with ESMTP id iBHFLhZb009406; Fri, 17 Dec 2004 10:21:44 -0500 (EST) Received: from usinftwiccmms03.ent.verizon.com (ftwmms03a.interwan.gte.com [138.83.138.66]) by smtpftw.interwan.gte.com (8.12.10/8.12.10) with ESMTP id iBHFLbYq012114; Fri, 17 Dec 2004 10:21:37 -0500 (EST) Received: from 138.83.34.22 by usinftwiccmms03.ent.verizon.com with ESMTP (SMTP Relay); Fri, 17 Dec 2004 10:21:32 -0500 X-Server-Uuid: 2F91DA65-DB13-41BC-8809-D657BCBC59D7 Received: from dwsmtp01.core.verizon.com (dwmail21.interwan.gte.com [138.83.36.17]) by coregate1.interwan.gte.com (8.12.10/8.12.10) with ESMTP id iBHFLVfQ023066; Fri, 17 Dec 2004 09:21:31 -0600 (CST) To: ck@juniper.net, busschbach@lucent.com, chmetz@cisco.com X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Fri, 17 Dec 2004 10:21:29 -0500 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.0.2CF2|July 23, 2003) at 12/17/2004 09:21:30 MIME-Version: 1.0 X-WSS-ID: 6DDC26F62A41205902-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: [Idr] draft-ck-bgp-atm-nlri-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi, The draft looks good. I just have few comments: - "the introduction of an MPLS core creates a topological challenge that does not exist in traditional ATM networks. The overlay approach results in a full mesh of O(N*N) PNNI routing adjacencies, where N is the number of ATM switches that directly connect to the MPLS core. Each ATM switch that is directly connected to the MPLS core has to deal with O(N) adjacencies, where N can be quite large, thereby imposing a scaling burden on its ATM control plane." This is not necesarily required. You can have a partial mesh of PNNI trunks over MPLS PWs, However, this will lead to having the ATM switches terminating these PNNI trunnks to become transit That is they will have to do MPLS PW-ATM- MPLS PW interworking. what is your view on that? However, I do think that PNNI adjacencies in this case (although this is not restricted to PNNI) adjacencies are a scalability factor and if you are interconnecting a large set of ATM clouds and you want to have direct reachability among these clouds without using another cloud or the border of another cloud as transit nodes for various reasons, the number of PNNI adjacencies will become a factor that is cofounded with the size of the network. Having the capability to alleviate this problem by distributing ATM reachability via BGP is and requiring a switch to have one, two or few BGP peering sessions with two or more route reflectors instead of a PNNI adjacency with every other switch is an advantage although this shifts some of this load to the RR. - The next hop address for an NLRI: you mention it can be any IPv4, IPv6 or NSAP address. Do you think that it makes sense to require it to be an IP address only? It seems to me reasonable to do that . Is there is need to have an NSAP address? In addition, it is not stated clearly how the next hop address would be encoded. Wouldn't this be dependent on the address family? - ATM reachability type: doesn't this have to be assigned by IANA? - Site of origin attribute: you leave this ptional. Is it possible to elaborate on the need for it and what is the consequence if not included. - "The RD used by a PE must be unique, and can either be preconfigured or auto-generated based on PE's attributes like configured autonomous system (AS) and IP addresses." RD containing IP address depends on whether the AS is 4 bytes or 2 bytes. Thanks, Nabil _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA03919 for ; Fri, 17 Dec 2004 01:56:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfC0u-0004h8-FC; Fri, 17 Dec 2004 01:54:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfBzW-0004JE-Rb for idr@megatron.ietf.org; Fri, 17 Dec 2004 01:53:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01386 for ; Fri, 17 Dec 2004 01:53:29 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfC87-0001jY-9U for idr@ietf.org; Fri, 17 Dec 2004 02:02:23 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id iBH6qubr005559 for ; Fri, 17 Dec 2004 00:52:57 -0600 (CST) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 17 Dec 2004 12:22:55 +0530 Message-ID: <6733C768256DEC42A72BAFEFA9CF06D20C1078BD@ii0015exch002u.iprc.lucent.com> From: "P, Sridhar (Sridhar)" To: "'idr@ietf.org'" Date: Fri, 17 Dec 2004 12:22:50 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [Idr] ORGIN priority & and Routing Protocol priority.. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1568141344==" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1568141344== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E404.702516DC" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4E404.702516DC Content-Type: text/plain; charset="iso-8859-1" orgin : the priority in assinging the orgin of the route entry is IGP EGP and INCOMPLETE. the preference among the routing protocols are EGP IGP .. it is contridicting...like (AS-X)------(AS-1)------(AS-2) Net A is adv from AS-X to AS-1 as a ebgp route. i have Net A learned as igp in AS-1 (via IGP) so while updating into bgp it updates as IGP orgin because of orgin priority.... and if packet comes to AS-1 to reach AS-X it prefers AS-x path because of route protocol priority... so both are contridicting...can someone explain this.... Sridhar P * Lucent Technologies MultiService Switching * 91-80-51191190 * sridharp@lucent.com ------_=_NextPart_001_01C4E404.702516DC Content-Type: text/html; charset="iso-8859-1"
orgin :
the priority in assinging the orgin of the route entry is
IGP
EGP
and INCOMPLETE.
 
the preference among the routing protocols are
EGP
IGP ..
 

it is contridicting...like

(AS-X)------(AS-1)------(AS-2)

Net A is adv from AS-X to AS-1 as a ebgp route.
i have Net A learned as igp in AS-1 (via IGP) so  while updating into bgp it updates as IGP orgin because of orgin priority....
and if packet comes to AS-1 to reach AS-X it prefers AS-x path because of route protocol priority...
so both are contridicting...can someone explain this....
 
Sridhar P
m Lucent Technologies MultiService Switching
( 91-80-51191190
* sridharp@lucent.com
 
------_=_NextPart_001_01C4E404.702516DC-- --===============1568141344== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============1568141344==-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA27902 for ; Tue, 14 Dec 2004 13:20:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeHEe-0003Tv-Px; Tue, 14 Dec 2004 13:17:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeH9Q-0002hT-6B for idr@megatron.ietf.org; Tue, 14 Dec 2004 13:11:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28701 for ; Tue, 14 Dec 2004 13:11:53 -0500 (EST) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CeHHR-00010H-HD for idr@ietf.org; Tue, 14 Dec 2004 13:20:16 -0500 Received: (qmail 93124 invoked from network); 14 Dec 2004 18:11:49 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 14 Dec 2004 18:11:49 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iBEIBNw2012589; Tue, 14 Dec 2004 13:11:23 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200412141811.iBEIBNw2012589@workhorse.faster-light.net> To: "Busschbach, Peter B (Peter)" Subject: Re: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? In-reply-to: Your message of "Tue, 14 Dec 2004 12:10:51 EST." Date: Tue, 14 Dec 2004 13:11:23 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: idr@ietf.org, "'Pekka Savola'" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org In message "Busschbach, Peter B (Peter)" writes: > > Curtis Villamizar wrote: > [snipped] > > > Yes, in principal PNNI is like an IP IGP and BGP could be its exterior > > routing protocol. ATM itself is end-to-end connection oriented and > > ATM SVC service has never been offerred by any major provider so > > arguments of scaling due to not having an exterior routing protocol > > completely fall apart. > > This has nothing to do with SVCs. The draft proposes to solve routing > issues that might arise when an MPLS network is used to interconnect > previously independent ATM islands. Signaling (whether it is to set up > SVCs or, as is much more common, SPVCs) has its own issues, but is not > necessarily impacted by the use of an MPLS core network and is > completely independent of the routing protocols used. My point was that scaling is terrible if you need PVCs because you must either settle for partial connectivity or an unscalable full mesh. If partial connectivity is the goal, then ATM becomes just a VPN technology. > > It is not unreasonable for an IETF WG to demand strong indication that > > there is a clear requirement for anything that the WG is asked to > > consider as a WG work item. We've asked and there has been no > > indication from any provider of any need for this. > > > I too am anxiously waiting for Service Providers who might benefit > from the solution to speak up. It should be noted, though, that the > people who run ATM networks usually don't subscribe to the IDR mailing > list and therefore might not as readily respond as one would hope. And they are all too clueless to figure out how to subscribe? If a provider intending to use this does exist, you might want to mention that this probably won't happen in the IETF if they remain silent. The argument that demand exists but the providers are too shy doesn't count for anything. Nor does the argument that they really need this but they don't yet really know that they really need this. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA27489 for ; Tue, 14 Dec 2004 12:37:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeGSL-0008I2-4m; Tue, 14 Dec 2004 12:27:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeGD4-0002g0-E3 for idr@megatron.ietf.org; Tue, 14 Dec 2004 12:11:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22498 for ; Tue, 14 Dec 2004 12:11:36 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeGL6-0007d6-E1 for idr@ietf.org; Tue, 14 Dec 2004 12:19:58 -0500 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id iBEHB2XJ023053 for ; Tue, 14 Dec 2004 11:11:03 -0600 (CST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 14 Dec 2004 12:11:02 -0500 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'curtis@faster-light.net'" Subject: RE: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? Date: Tue, 14 Dec 2004 12:10:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: idr@ietf.org, "'Pekka Savola'" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Curtis Villamizar wrote: [snipped] > Yes, in principal PNNI is like an IP IGP and BGP could be its exterior > routing protocol. ATM itself is end-to-end connection oriented and > ATM SVC service has never been offerred by any major provider so > arguments of scaling due to not having an exterior routing protocol > completely fall apart. This has nothing to do with SVCs. The draft proposes to solve routing issues that might arise when an MPLS network is used to interconnect previously independent ATM islands. Signaling (whether it is to set up SVCs or, as is much more common, SPVCs) has its own issues, but is not necessarily impacted by the use of an MPLS core network and is completely independent of the routing protocols used. > > It is not unreasonable for an IETF WG to demand strong indication that > there is a clear requirement for anything that the WG is asked to > consider as a WG work item. We've asked and there has been no > indication from any provider of any need for this. I too am anxiously waiting for Service Providers who might benefit from the solution to speak up. It should be noted, though, that the people who run ATM networks usually don't subscribe to the IDR mailing list and therefore might not as readily respond as one would hope. > > Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA13576 for ; Mon, 13 Dec 2004 13:41:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdv2O-000082-Jm; Mon, 13 Dec 2004 13:35:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CduuN-0007A8-R0 for idr@megatron.ietf.org; Mon, 13 Dec 2004 13:26:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06309 for ; Mon, 13 Dec 2004 13:26:52 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdv2D-0005cf-ST for idr@ietf.org; Mon, 13 Dec 2004 13:35:03 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 13 Dec 2004 10:26:26 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBDIQCm4013448; Mon, 13 Dec 2004 10:26:13 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AZT76940; Mon, 13 Dec 2004 10:35:47 -0800 (PST) Message-Id: <6.2.0.14.2.20041213092620.06b790e8@mira-sjc5-b.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 13 Dec 2004 10:05:28 -0800 To: Pekka Savola From: Fred Baker Subject: RE: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org At 12:55 PM 12/13/04 +0200, Pekka Savola wrote: >Depends on what you call 'Network layer', I guess :). Network layer >typically refers to the layer of "IP". From the perspective of IP, ATM >routing information is at the link-layer. This would seem the similar to >propagating Ethernet MAC addresses of VPLSs (for example) in NLRIs. I agree that this terminology is generally used, but it is in fact incorrect. Lets take an aside into the definitions and meanings of words. Going back to the definitions of the terms, a "Link" is a physical connection between two Nodes on a network, and the Link Layer is the communications layer that provides for the reliable transfer of information across a Link. Both of those definitions, I believe, derive from Stallings, 1991, and reflect the preoccupation of the time with reliability at the link layer. In other words, the physical layer is something you can touch or otherwise describe in terms of physics and includes the mechanism for encoding data (often binary but not necessarily; see QPSK), and the link layer separates the exchanged data into noise and signals exchanged between physically connected systems. The network layer is by definition a layer which creates virtual connectivity (circuits or connectionless routes as appropriate) out of a sequence of zero or more link layer connections between nodes in the graph. IP is called the "Internet Protocol" because it connects networks (think for a moment about what "inter" and "network" mean etymologically). These networks may be pure IP networks, but (surprise) may be switched LANs over which IP data is flowing, ATM networks, Frame Relay Networks, or a long list of other kinds of networks. You'll ask why we call these "link layer networks". Well, there are two reasons. One is that ballpark 1979 the Internet community decided to switch from BBN 1822 to X.25 as an access technology into the ARPANET, and observed (correctly) that X.25 described what happened at a user-to-network (UNI) or network-to-network (NNI) interface, but did not describe what happened in the network itself. As such, they had trouble thinking of it as a real communication layer, but rather wanted to treat it only as the UNI or NNI. They therefore (tweaking noses in CCITT immensely) relegated it to a layer beneath them. Five years later, IEEE wanted to define Ethernet and Token Ring Bridging (as "switching" was then called), and (since the network layer belonged to ANSI by prior agreement) called theirs a "link layer network". It did, after all, use the link layer header... But trust me, an ATM network is a network, and by definition belongs in what I call the "Intranet" sublayer of the Network Layer of the OSI Reference Model. What distinguishes the various technologies at this sublayer as much as anything is that they are designed to connect things that ought to be connected, and are operated by a single administration. The Internet Protocol connects disparate such networks and the hosts in them end to end, and is operated by disparate administrations with disparate intents and policies. The Internet is a network of networks, and many of those networks are not fundamentally IP networks, but only carry IP as an overlay. Which is why we can deploy a different Internet protocol over the same network... _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA13180 for ; Mon, 13 Dec 2004 12:57:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CduQE-0005Jv-Nm; Mon, 13 Dec 2004 12:55:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CduEM-0008VX-Bx for idr@megatron.ietf.org; Mon, 13 Dec 2004 12:43:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01795 for ; Mon, 13 Dec 2004 12:43:27 -0500 (EST) Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CduM3-0004Mv-6I for idr@ietf.org; Mon, 13 Dec 2004 12:51:37 -0500 Received: (qmail 90680 invoked from network); 13 Dec 2004 17:43:17 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 13 Dec 2004 17:43:17 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iBDHh538008624; Mon, 13 Dec 2004 12:43:05 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200412131743.iBDHh538008624@workhorse.faster-light.net> To: "Busschbach, Peter B (Peter)" Subject: Re: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? In-reply-to: Your message of "Mon, 13 Dec 2004 08:50:10 EST." Date: Mon, 13 Dec 2004 12:43:05 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: idr@ietf.org, "'Pekka Savola'" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org In message "Busschbach, Peter B (Peter)" writes: > > Pekka Savola wrote: > > On Mon, 13 Dec 2004, Busschbach, Peter B (Peter) wrote: > >> I object against the use of the word "ATM hack". The draft > >> represents a straightforward application of Multi-Protocol > >> extensions for BGP. Draft-ietf-idr-rfc2858bis-06.txt says: "This > >> document defines extensions to BGP-4 to enable it to carry routing > >> information for multiple Network Layer protocols". Now that we > >> propose to use this to carry ATM routing information, it is suddenly > >> a hack?? > > > > Depends on what you call 'Network layer', I guess :). Network layer > > typically refers to the layer of "IP". > > It is not the first time that I notice that IETF members use the word > "multi-service" when in fact they are only interested in IP. It always > reminds me of the American habit to call the winner of a national > sports championship the "world champion" :-) > > ATM is both a link layer and a network layer protocol. ATM uses > routing protocols that are very similar to IP routing protocols. The > main difference between IP and ATM is that IP is connectionless and > ATM is connection-oriented. > > > From the perspective of IP, > > ATM routing information is at the link-layer. This would seem the > > similar to propagating Ethernet MAC addresses of VPLSs (for example) > > in NLRIs. > > Yes, it would be similar, if Ethernet would use routing protocols to > advertise MAC addresses. However, Ethernet uses learning bridges in a > loop-free topology and is in that respect different from both IP and > ATM. We heard that ATM would dominate the world in 1993 and end-user TCP would just have to learn to work over ATM. We heard that all IP would run over ATM in the mid-1990s. None of this came from IP providers, mostly from ATM vendors with some sort of credibility attached to it through statements passed through the ATM Forum. I haven't seen a single message from a provider supporting this. I don't think I've seen a single message from a non-author supporting this as a WG item. Yes, in principal PNNI is like an IP IGP and BGP could be its exterior routing protocol. ATM itself is end-to-end connection oriented and ATM SVC service has never been offerred by any major provider so arguments of scaling due to not having an exterior routing protocol completely fall apart. It is not unreasonable for an IETF WG to demand strong indication that there is a clear requirement for anything that the WG is asked to consider as a WG work item. We've asked and there has been no indication from any provider of any need for this. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA11294 for ; Mon, 13 Dec 2004 09:20:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdqlP-00055i-QJ; Mon, 13 Dec 2004 09:01:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdqan-0000Ke-1K for idr@megatron.ietf.org; Mon, 13 Dec 2004 08:50:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09078 for ; Mon, 13 Dec 2004 08:50:23 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdqiY-0006EB-Vk for idr@ietf.org; Mon, 13 Dec 2004 08:58:30 -0500 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iBDDoJZb026404 for ; Mon, 13 Dec 2004 07:50:19 -0600 (CST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 13 Dec 2004 08:50:19 -0500 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'Pekka Savola'" Subject: RE: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? Date: Mon, 13 Dec 2004 08:50:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Pekka Savola wrote: > On Mon, 13 Dec 2004, Busschbach, Peter B (Peter) wrote: >> I object against the use of the word "ATM hack". The draft >> represents a straightforward application of Multi-Protocol >> extensions for BGP. Draft-ietf-idr-rfc2858bis-06.txt says: "This >> document defines extensions to BGP-4 to enable it to carry routing >> information for multiple Network Layer protocols". Now that we >> propose to use this to carry ATM routing information, it is suddenly >> a hack?? > > Depends on what you call 'Network layer', I guess :). Network layer > typically refers to the layer of "IP". It is not the first time that I notice that IETF members use the word "multi-service" when in fact they are only interested in IP. It always reminds me of the American habit to call the winner of a national sports championship the "world champion" :-) ATM is both a link layer and a network layer protocol. ATM uses routing protocols that are very similar to IP routing protocols. The main difference between IP and ATM is that IP is connectionless and ATM is connection-oriented. > From the perspective of IP, > ATM routing information is at the link-layer. This would seem the > similar to propagating Ethernet MAC addresses of VPLSs (for example) > in NLRIs. Yes, it would be similar, if Ethernet would use routing protocols to advertise MAC addresses. However, Ethernet uses learning bridges in a loop-free topology and is in that respect different from both IP and ATM. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA09554 for ; Mon, 13 Dec 2004 06:47:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdoeZ-0000mJ-Ib; Mon, 13 Dec 2004 06:46:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdobX-00007o-UO for idr@megatron.ietf.org; Mon, 13 Dec 2004 06:43:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25864 for ; Mon, 13 Dec 2004 06:43:01 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdojK-0002pX-Gj for idr@ietf.org; Mon, 13 Dec 2004 06:51:08 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 13 Dec 2004 12:49:57 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBDBgQGb004211; Mon, 13 Dec 2004 12:42:27 +0100 (MET) Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Dec 2004 12:42:26 +0100 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" Subject: RE: [Idr] MInutes for IDR Date: Mon, 13 Dec 2004 12:38:52 +0100 Message-ID: Thread-Topic: [Idr] MInutes for IDR Thread-Index: AcTe1M1W6rWg0MNgQM+kkJPUpeMTcwCKb+IA From: "Francois Le Faucheur \(flefauch\)" To: "Susan Hares" X-OriginalArrivalTime: 13 Dec 2004 11:42:26.0705 (UTC) FILETIME=[D1AE1010:01C4E108] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: yakov@juniper.net, "Francois Le Faucheur \(flefauch\)" , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id GAA09554 Hi Sue, Comments on the minutes re bgp-tunnel: IPv6 over IPv4 MPLS (Francis LeFaucheur, presenter) --------------------------------------------------- Right spelling for my name is "Francois Le Faucheur" I suggest listing the draft being discussed (draft-ooms-v6ops-bgp-tunnel-04.txt) The draft presents a technique, which will be coordinated with V6OPS s/which will be/which has been/ through the ADs, for providing IPv6 service over an existing IPv4 MPLS cloud, without the cloud needing to be V6-aware. The proposed solution is intended to require no protocll extensions (see s/is intented to require no/does not require any/ draft-ietf-l3vpn-bgp-ipv6). It carris labels in MP-BGP. The Please remove the reference to draft-ietf-l3vpn-bgp-ipv6 above. The stamement about not requiring protocol extensions in bgp-tunnel has nothing to do with l3vpn-bgp-ipv6. requiriemens are stated in draft-ietf-v6ops-isp-scenarios-analysis-03.txt. Draft 04 is underway, and will clarify some MUST/SHOULD terminology, expand on the inter-AS cases, and add additional detail on security. There is some confusion here. The 03-->04 changes related to the bgp-tunnel draft (not to isp-scenario). These changes have already been done in bgp-tunnel-04. So the above should read: "bgp-tunnel-04 includes the following changes over the previous version: clarify some MUST/SHOULD terminology, expand on the inter-AS cases, and add additional detail on security." Publication of this specification will involve coordinated documents between V6OPS and IDR, consistent where possible and different where necessary. For example, the V6OPS document will carry label SAFI/AFI while the IDR document will carry VPN SAFI/AFI. This paragraph mixes everything up. It should read: "draft-ooms-v6ops-bgp-tunnel-04.txt specifies support for global IPv6 reachability services while draft-ietf-l3vpn-bgp-ipv6-03.txt specifies support for IPv6 VPN services. The two documents are consistent wherever they can be and are only different where needed (eg bgp-tunnel uses "labeled IPv6" AFI/SAFI while l3vpn-bgp-ipv6 uses "VPN-IPv6" AFI/SAFI). After the editorial changes are complete, the document will go out for last call and implementation survey. I believe what was agreed was that the document was ready for Last Call and the Last Call was going to be issued right after Wash IETF. So I suggest replacing previous paragraph with something like: "The document will go out for Last Call after this meeting". Thank you Francois _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA09053 for ; Mon, 13 Dec 2004 05:58:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdntJ-0005oT-N6; Mon, 13 Dec 2004 05:57:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdns5-0005eX-RK for idr@megatron.ietf.org; Mon, 13 Dec 2004 05:56:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21800 for ; Mon, 13 Dec 2004 05:56:03 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdnzr-0001ns-77 for idr@ietf.org; Mon, 13 Dec 2004 06:04:09 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBDAtLA14786; Mon, 13 Dec 2004 12:55:21 +0200 Date: Mon, 13 Dec 2004 12:55:21 +0200 (EET) From: Pekka Savola To: "Busschbach, Peter B (Peter)" Subject: RE: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Mon, 13 Dec 2004, Busschbach, Peter B (Peter) wrote: > I object against the use of the word "ATM hack". The draft > represents a straightforward application of Multi-Protocol > extensions for BGP. Draft-ietf-idr-rfc2858bis-06.txt says: "This > document defines extensions to BGP-4 to enable it to carry routing > information for multiple Network Layer protocols". Now that we > propose to use this to carry ATM routing information, it is suddenly > a hack?? Depends on what you call 'Network layer', I guess :). Network layer typically refers to the layer of "IP". From the perspective of IP, ATM routing information is at the link-layer. This would seem the similar to propagating Ethernet MAC addresses of VPLSs (for example) in NLRIs. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA08064 for ; Mon, 13 Dec 2004 04:27:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdmOs-0002ii-B1; Mon, 13 Dec 2004 04:21:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdmEd-0007ru-SX for idr@megatron.ietf.org; Mon, 13 Dec 2004 04:11:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12760 for ; Mon, 13 Dec 2004 04:11:14 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdmMP-0007u2-8D for idr@ietf.org; Mon, 13 Dec 2004 04:19:18 -0500 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iBD9BCeY028526 for ; Mon, 13 Dec 2004 03:11:12 -0600 (CST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 13 Dec 2004 04:11:11 -0500 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'Pekka Savola'" , Curtis Villamizar Subject: RE: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? Date: Mon, 13 Dec 2004 04:10:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Pekka Savola wrote: > On Fri, 3 Dec 2004, Curtis Villamizar wrote: >> Anything that is not a WG item and is being considered for a WG item >> is by definition new work for the WG and therefore it should be >> determined that there is a requirement for it. I think those several >> service providers should speak up for themselves if they are >> interested in seeing this work progress. >> >> Having been on the provider side of this business in the past I know >> that at times a vendor will approach a service provider with an idea >> and if they provider doesn't bodily throw them out the door the >> vendor counts them as "possibly interested" for the purpose of >> discussions such as this. Therefore I'd like to see the providers >> speak for themselves rather than the vendor speak and there is >> plenty of precedence in the IETF for asking for that. > > I'll echo Curtis's concern. > > ATM has gone out so long time ago that I'd expect that the vast > majority of serious SPs have already solved this problem without a > real need for this mechanism. I'm not sure we want to add ATM hacks to > BGP as well.. I object against the use of the word "ATM hack". The draft represents a straightforward application of Multi-Protocol extensions for BGP. Draft-ietf-idr-rfc2858bis-06.txt says: "This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols". Now that we propose to use this to carry ATM routing information, it is suddenly a hack?? [snipped] _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA06977 for ; Mon, 13 Dec 2004 02:58:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdkzC-0003Ym-6z; Mon, 13 Dec 2004 02:51:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdkuG-0002CO-Ad for idr@megatron.ietf.org; Mon, 13 Dec 2004 02:46:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06364 for ; Mon, 13 Dec 2004 02:46:07 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdl1x-0005iW-Dd for idr@ietf.org; Mon, 13 Dec 2004 02:54:10 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iBD7jGb10708; Mon, 13 Dec 2004 09:45:22 +0200 Date: Mon, 13 Dec 2004 09:45:16 +0200 (EET) From: Pekka Savola To: Curtis Villamizar Subject: Re: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? In-Reply-To: <200412032151.iB3LpnSM004497@workhorse.faster-light.net> Message-ID: References: <200412032151.iB3LpnSM004497@workhorse.faster-light.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Fri, 3 Dec 2004, Curtis Villamizar wrote: > Anything that is not a WG item and is being considered for a WG item > is by definition new work for the WG and therefore it should be > determined that there is a requirement for it. I think those several > service providers should speak up for themselves if they are > interested in seeing this work progress. > > Having been on the provider side of this business in the past I know > that at times a vendor will approach a service provider with an idea > and if they provider doesn't bodily throw them out the door the vendor > counts them as "possibly interested" for the purpose of discussions > such as this. Therefore I'd like to see the providers speak for > themselves rather than the vendor speak and there is plenty of > precedence in the IETF for asking for that. I'll echo Curtis's concern. ATM has gone out so long time ago that I'd expect that the vast majority of serious SPs have already solved this problem without a real need for this mechanism. I'm not sure we want to add ATM hacks to BGP as well.. A couple of particular comments on the applicability text of the draft: To avoid manual provisioning of addresses, operators could provision point-to-point pseudo-wires between the ATM switches that directly connect to the MPLS core, and run PNNI routing and signaling on these pseudo-wires. ==> exactly, I'd suspect this has been done and continue to be done, and requires no special support at all. However, for several reasons that might be undesirable. Firstly, the ATM network islands may belong to different administrative domains. ==> this is an identical problem with the existing ATM cloud, i.e., introducing MPLS does not make it any worse. As it is, you'll already have to use static ATM routes or run them in a single ATM cloud. Secondly, even within one administrative domain, an operator might not want to create one single, large ATM network because of scaleability concerns. ==> again, this already applies to the existing ATM network, or you'll have to do the same manual config. Thirdly, the introduction of an MPLS core creates a topological challenge that does not exist in traditional ATM networks. The overlay approach results in a full mesh of O(N*N) PNNI routing adjacencies, where N is the number of ATM switches that directly connect to the MPLS core. Each ATM switch that is directly connected to the MPLS core has to deal with O(N) adjacencies, where N can be quite large, thereby imposing a scaling burden on its ATM control plane. ==> is the number of ATM clouds connected over MPLS really that great? If you are bothered by this scalability concern, you could also deploy a couple of ATM switches to keep down the number of adjacencies (similar to BGP route reflectors are used with BGP). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA06285 for ; Mon, 13 Dec 2004 01:58:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdk7r-00078K-7T; Mon, 13 Dec 2004 01:56:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdk3l-0005oY-Ne for idr@megatron.ietf.org; Mon, 13 Dec 2004 01:51:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17443 for ; Mon, 13 Dec 2004 01:51:52 -0500 (EST) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdkBV-0004YG-Rb for idr@ietf.org; Mon, 13 Dec 2004 01:59:54 -0500 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id WAA21433; Sun, 12 Dec 2004 22:51:17 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Idr] MInutes for IDR Date: Sun, 12 Dec 2004 22:49:22 -0800 Message-ID: <7549C475A1F3CF47ABCA660BF44738B329C155@legolas.rs.riverstonenet.com> Thread-Topic: MInutes for IDR Thread-Index: AcTe1M1W6rWg0MNgQM+kkJPUpeMTcwCCxOAM From: "Bhatia, Manav" To: "Susan Hares" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: yakov@juniper.net X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id BAA06285 Hi, There is a correction: > Equal Cost Multipath (Manav Bhatia, Joel Halpern) [clipped] > is advertising: conventional IPv4 or VPN. It is not intended for load > splitting across different AS. This is incorrect. It *is* intended for load splitting across different ASes. Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA01096 for ; Fri, 10 Dec 2004 11:38:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcnfL-00072S-SJ; Fri, 10 Dec 2004 11:30:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcnaQ-0005XG-G0 for idr@megatron.ietf.org; Fri, 10 Dec 2004 11:25:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27141 for ; Fri, 10 Dec 2004 11:25:39 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccnhd-0008HP-4n for idr@ietf.org; Fri, 10 Dec 2004 11:33:10 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id DE7C72D483A for ; Fri, 10 Dec 2004 11:25:05 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04501-05-45 for ; Fri, 10 Dec 2004 11:25:03 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7F2EC2D480C for ; Fri, 10 Dec 2004 11:25:03 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 10 Dec 2004 11:25:03 -0500 Message-ID: Thread-Topic: MInutes for IDR Thread-Index: AcTe1M1W6rWg0MNgQM+kkJPUpeMTcw== From: "Susan Hares" To: X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.6 (/) X-Scan-Signature: ea98052f75c8682673c96267a0eea7de Cc: yakov@juniper.net Subject: [Idr] MInutes for IDR X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0154699101==" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --===============0154699101== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DED4.CD725352" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4DED4.CD725352 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Please send in comments on the minutes for IETF 61. =20 Sue =20 =20 =20 =20 Sue Hares and Yakov Rekhter co-chaired the meeting. Yakov issued an=20 initial OPEN, but a transmission failure of the microphone system=20 caused his transport entity to time out. He retransmitted the OPEN and=20 successfully peered with the attendees. =20 =20 Old Business ------------ =20 Sue reviewed the status of the core BGP documents under revision:=20 =20 - Border Gateway Protocol 4 (BGP-4)=20 - Definitions of Managed Objects for the Fourth Version of=20 Border Gateway Protocol (BGP-4)=20 - BGP-4 Protocol Analysis=20 - BGP Security Vulnerabilities Analysis=20 - Experience with the BGP-4 Protocol=20 - BGP MIB V1 implementation survey=20 - BGP 4 Implementation Report =20 There is no new internal WG progress or action=20 required; these are awaiting IESG review. =20 Also in the approval process are Graceful Restart and Extended=20 Communities, both as Proposed Standards, and Cease Subcodes, to be a=20 Draft Standard. =20 The IESG is waiting for an implementation report on confederations. =20 There was nothing to report on cooperative route filtering, 4-octet AS=20 numbers, AS-based ORF, MIB 2, and AS-wide identifiers. =20 =20 New Business ------------ Equal Cost Multipath (Manav Bhatia, Joel Halpern) ------------------------------------------------- =20 This was a working report on differences, not a final. The problem=20 that the ECMP proposal intends to solve is defining a mechanism by=20 which an implementation that installs equal cost multipath routes, but=20 only advertises one route, can readvertise the multiple routes without=20 breaking policies. Its basic approach is to create synthetic AS-SETS=20 in the readvertisements. =20 Potential benefits of the technique include avoiding certain cases of=20 route reflector oscillation. The technique is consistent with=20 multiprotocol extensions, using the AFI/SAFI relevant to the routes it=20 is advertising: conventional IPv4 or VPN. It is not intended for load=20 splitting across different AS. =20 The consensus was that not enough WG members had read it for consensus. =20 =20 IPv6 over IPv4 MPLS (Francis LeFaucheur, presenter) --------------------------------------------------- The draft presents a technique, which will be coordinated with V6OPS=20 through the ADs, for providing IPv6 service over an existing IPv4 MPLS=20 cloud, without the cloud needing to be V6-aware. The proposed solution=20 is intended to require no protocll extensions (see=20 draft-ietf-l3vpn-bgp-ipv6). It carris labels in MP-BGP. The=20 requiriemens are stated in=20 =20 draft-ietf-v6ops-isp-scenarios-analysis-03.txt. =20 Draft 04 is underway, and will clarify some MUST/SHOULD terminology,=20 expand on the inter-AS cases, and add additional detail on security. Publication of this specification will involve coordinated documents=20 between V6OPS and IDR, consistent where possible and different where=20 necessary. For example, the V6OPS document will carry label SAFI/AFI=20 while the IDR document will carry VPN SAFI/AFI. =20 After the editorial changes are complete, the document will go out for=20 last call and implementation survey. =20 =20 AS Edge Confederations (Sue Hares) ---------------------------------- This was a discussion item; the I-D did not make the cutoff. The=20 technique described is a method for using dynamic capabilities at the=20 edge of AS confederations, with the confederation-AS typically in a=20 ring topology. The example was given of a confederation of=20 satellite-based confederation AS being accessed by an earth station. While the technique both is ad hoc and involves mobility, it is=20 different in applicability from MANET and mobile IP, since its quantum=20 of mobility is the AS, not either subnet or host. =20 This would typically be used in a low-bandwidth applkication where the=20 edge (i.e., non-confederation) AS lose connectivity with one AS in the=20 ring, but transfer connectivity to a differfent confederation-AS,=20 using dynamic capabilities exchange. As operational requirements=20 dictate, the non-confederation AS might switch back to the original=20 upstream AS. Additional security may be required for this=20 application. =20 Discussion followed. =20 John Scudder (): If you expect this change, why wait for dynamic=20 capabilities? Why not configure immediately? =20 Sue: We don't want to drop the associated peers =20 Peter Lothberg: Why not use an IGP? Sue answered that an IGP gives=20 insufficient policy control. =20 John Scudder: Pointed out that you cannot nest confederations,=20 limitiing applicability. Sue reitierated this is neither MANET nor=20 mobile IP. =20 =20 Chandra -- is confederation AS too small a level=20 of granularity? He asked why there could be additional security=20 requirements, and Sue pointed out that TCP neither encrypts nor=20 authenticates, and regular BGP security may be insufficient for some=20 tactical applications. =20 Peter Lothberg: Is the policy for inter-AS links, AS, or AS=20 confederation? WHat is the requirement? Sue replied the policy was=20 for the confederation. =20 Russ White: Suggested avoided the security cookie. He felt it might=20 be too ad hoc, and a general solution would be better. =20 John Scudder: agrees ad hoc may not be desirable -- worried about cloned AS. =20 Parantep (MCI): "neither confirm or deny IGP is aware", agreed to=20 by Sue. Application may involve multiple IGP. =20 Peter Lothberg: Asked Sue to confirm this proposal is to solve a real=20 problem, not just to demonstrate what could be done. =20 =20 Dampening --------- =20 Sue suggested there be WG list discussion of updates. =20 =20 ------_=_NextPart_001_01C4DED4.CD725352 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Please send in comments on the minutes for IETF = 61.

 

Sue

 

 

 

 

Sue Hares and Yakov Rekhter co-chaired the = meeting. Yakov issued an

initial OPEN, but a transmission failure of = the microphone system

caused his transport entity to time out. He retransmitted the OPEN and

successfully peered with the = attendees.

 

 

Old Business

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

 

Sue reviewed the status of the core BGP = documents under revision:

 

 - Border Gateway Protocol 4 (BGP-4) =

 - Definitions of Managed Objects for = the Fourth Version of

   Border Gateway Protocol (BGP-4) =

 - BGP-4 Protocol Analysis =

 - BGP Security Vulnerabilities Analysis =

 - Experience with the BGP-4 Protocol =

 - BGP MIB V1 implementation survey =

 - BGP 4 Implementation = Report

 

There is no new internal WG progress or = action

required; these are awaiting IESG = review.

 

Also in the approval process are Graceful = Restart and Extended

Communities, both as Proposed Standards, and = Cease Subcodes, to be a

Draft Standard.

 

The IESG is waiting for an implementation = report on confederations.

 

There was nothing to report on cooperative = route filtering, 4-octet AS

numbers, AS-based ORF, MIB 2, and AS-wide identifiers.

 

 

New Business

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

Equal Cost Multipath (Manav Bhatia, Joel = Halpern)

-------------------------------------------------=

 

This was a working report on differences, not = a final. The problem

that the ECMP proposal intends to solve is = defining a mechanism by

which an implementation that installs equal = cost multipath routes, but

only advertises one route, can readvertise = the multiple routes without

breaking policies. Its basic approach is to = create synthetic AS-SETS

in the = readvertisements.

 

Potential benefits of the technique include = avoiding certain cases of

route reflector oscillation. The technique is consistent with

multiprotocol extensions, using the AFI/SAFI relevant to the routes it

is advertising: conventional IPv4 or = VPN.  It is not intended for load

splitting across different = AS.

 

The consensus was that not enough WG members = had read it for consensus.

 

 

IPv6 over IPv4 MPLS (Francis LeFaucheur, = presenter)

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

The draft presents a technique, which will be coordinated with V6OPS

through the ADs, for providing IPv6 service = over an existing IPv4 MPLS

cloud, without the cloud needing to be = V6-aware. The proposed solution

is intended to require no protocll extensions = (see

draft-ietf-l3vpn-bgp-ipv6). It carris labels = in MP-BGP.  The

requiriemens are stated in =

 

  = draft-ietf-v6ops-isp-scenarios-analysis-03.txt.<= /p>

 

Draft 04 is underway, and will clarify some MUST/SHOULD terminology,

expand on the inter-AS cases, and add = additional detail on security.

Publication of this specification will = involve coordinated documents

between V6OPS and IDR, consistent where = possible and different where

necessary. For example, the V6OPS document = will carry label SAFI/AFI

while the IDR document will carry VPN = SAFI/AFI.

 

After the editorial changes are complete, the document will go out for

last call and implementation = survey.

 

 

AS Edge Confederations (Sue = Hares)

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

This was a discussion item; the I-D did not = make the cutoff. The

technique described is a method for using = dynamic capabilities at the

edge of AS confederations, with the = confederation-AS typically in a

ring topology. The example was given of a confederation of

satellite-based confederation AS being = accessed by an earth station.

While the technique both is ad hoc and = involves mobility, it is

different in applicability from MANET and = mobile IP, since its quantum

of mobility is the AS, not either subnet or = host.

 

This would typically be used in a = low-bandwidth applkication where the

edge (i.e., non-confederation) AS lose = connectivity with one AS in the

ring, but transfer connectivity to a = differfent confederation-AS,

using dynamic capabilities exchange. As = operational requirements

dictate, the non-confederation AS might = switch back to the original

upstream AS.  Additional security may be = required for this

application.

 

Discussion = followed.

 

John Scudder ():  If you expect this = change, why wait for dynamic

           &= nbsp;      capabilities? Why not configure immediately?

 

Sue: We don't want to drop the associated = peers

 

Peter Lothberg: Why not use an IGP? Sue = answered that an IGP gives

           &= nbsp;    insufficient policy = control.

 

John Scudder:  Pointed out that you = cannot nest confederations,

           &= nbsp;   limitiing applicability. Sue reitierated this is neither MANET nor

           &= nbsp;   mobile IP.

 

 

Chandra -- is confederation AS too small a = level

      of = granularity? He asked why there could be additional security

      requirements, = and Sue pointed out that TCP neither encrypts nor

      authenticates, = and regular BGP security may be insufficient for some

      tactical = applications.

 

Peter Lothberg:  Is the policy for = inter-AS links, AS, or AS

           &= nbsp;     confederation? WHat is the requirement?  Sue replied the policy was =

           &= nbsp;     for the = confederation.

 

Russ White:  Suggested avoided the = security  cookie. He felt it might

           &= nbsp; be too ad hoc, and a general solution would be better.

 

John Scudder: agrees ad hoc may not be = desirable -- worried about cloned AS.

 

Parantep (MCI): "neither confirm or deny = IGP is aware", agreed to

           &= nbsp;       by Sue. Application may = involve multiple IGP.

 

Peter Lothberg:  Asked Sue to confirm = this proposal is to solve a real

           &= nbsp;     problem, not just to demonstrate what could be done.

 

 

Dampening

---------

 

Sue suggested there be WG list discussion of updates.

 

 

------_=_NextPart_001_01C4DED4.CD725352-- --===============0154699101== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============0154699101==-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA01351 for ; Mon, 6 Dec 2004 12:33:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbMi8-000654-8P; Mon, 06 Dec 2004 12:31:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbMWs-00039h-0I for idr@megatron.ietf.org; Mon, 06 Dec 2004 12:20:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01415 for ; Mon, 6 Dec 2004 12:20:03 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbMdF-0001hg-BL for idr@ietf.org; Mon, 06 Dec 2004 12:26:42 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id iB6HJT925142 for ; Mon, 6 Dec 2004 09:19:29 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id iB6HJOe67451 for ; Mon, 6 Dec 2004 09:19:24 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200412061719.iB6HJOe67451@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71333.1102353564.1@juniper.net> Date: Mon, 06 Dec 2004 09:19:24 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Idr] draft-ck-bgp-atm-nlri-01.txt as an IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, We receive a request to accept draft-ck-bgp-atm-nlri-01.txt as an IDR WG document. It would be greatly appreciated if folks would read the document and comment on it to the IDR mailing list. In other words, we need "yes, looks good" or "should fix this and that", not just silence. The deadline for comments is Dec 20, 2004 (if this is too short, please speak up, and we'll extend the deadline). Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA26152 for ; Mon, 6 Dec 2004 07:29:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbHck-00014R-7j; Mon, 06 Dec 2004 07:05:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbHbc-0000fO-7m; Mon, 06 Dec 2004 07:04:40 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28904; Mon, 6 Dec 2004 07:04:37 -0500 (EST) Message-Id: <200412061204.HAA28904@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 06 Dec 2004 07:04:37 -0500 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-analysis-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-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 Inter-Domain Routing Working Group of the IETF. Title : BGP-4 Protocol Analysis Author(s) : D. Meyer, K. Patel Filename : draft-ietf-idr-bgp-analysis-07.txt Pages : 20 Date : 2004-12-3 The purpose of this report is to document how the requirements for advancing a routing protocol from Draft Standard to full Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report satisfies the requirement for 'the second report', as described in Section 6.0 of [RFC1264]. In order to fulfill the requirement, this report augments [RFC1774] and summarizes the key features of BGP-4 protocol, and analyzes the protocol with respect to scaling and performance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-07.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-idr-bgp-analysis-07.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-idr-bgp-analysis-07.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: <2004-12-6073300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-analysis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-analysis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-6073300.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA13204 for ; Fri, 3 Dec 2004 17:45:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaLnI-0003dB-12; Fri, 03 Dec 2004 17:20:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaLL4-0000HX-1e for idr@megatron.ietf.org; Fri, 03 Dec 2004 16:51:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09587 for ; Fri, 3 Dec 2004 16:51:39 -0500 (EST) Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CaLQq-0005yP-Qs for idr@ietf.org; Fri, 03 Dec 2004 16:57:42 -0500 Received: (qmail 91758 invoked from network); 3 Dec 2004 21:51:38 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 3 Dec 2004 21:51:38 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iB3LpnSM004497; Fri, 3 Dec 2004 16:51:49 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200412032151.iB3LpnSM004497@workhorse.faster-light.net> To: "Busschbach, Peter B (Peter)" Subject: Re: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? In-reply-to: Your message of "Fri, 03 Dec 2004 15:31:05 EST." Date: Fri, 03 Dec 2004 16:51:49 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org In message "Busschbach, Peter B (Peter)" writes: > > Curtis Villamizar wrote: > >> Is anyone actually interested in deploying this or is it more of an > > intellectual exercise. The routing area has in the past required that > > there be a clear requirement for new work in a work group. > > > > Curtis > > I know of two vendors who are working on implementations and several Service Providers who have expressed interest. > > In addition, the draft hardly qualifies as "new work". It is a straightforward application of MP-BGP. > > Peter Peter, Anything that is not a WG item and is being considered for a WG item is by definition new work for the WG and therefore it should be determined that there is a requirement for it. I think those several service providers should speak up for themselves if they are interested in seeing this work progress. Having been on the provider side of this business in the past I know that at times a vendor will approach a service provider with an idea and if they provider doesn't bodily throw them out the door the vendor counts them as "possibly interested" for the purpose of discussions such as this. Therefore I'd like to see the providers speak for themselves rather than the vendor speak and there is plenty of precedence in the IETF for asking for that. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA11996 for ; Fri, 3 Dec 2004 15:47:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaKCF-0003eH-Sm; Fri, 03 Dec 2004 15:38:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaK5c-0005TG-JY for idr@megatron.ietf.org; Fri, 03 Dec 2004 15:31:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03737 for ; Fri, 3 Dec 2004 15:31:39 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaKBQ-0003tu-9h for idr@ietf.org; Fri, 03 Dec 2004 15:37:40 -0500 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iB3KV7vC018982 for ; Fri, 3 Dec 2004 14:31:08 -0600 (CST) Received: by NJ7460EXCH001H with Internet Mail Service (5.5.2657.72) id <4M3J1P88>; Fri, 3 Dec 2004 15:31:07 -0500 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'curtis@faster-light.net'" Subject: RE: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? Date: Fri, 3 Dec 2004 15:31:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Curtis Villamizar wrote: >> Is anyone actually interested in deploying this or is it more of an > intellectual exercise. The routing area has in the past required that > there be a clear requirement for new work in a work group. > > Curtis I know of two vendors who are working on implementations and several Service Providers who have expressed interest. In addition, the draft hardly qualifies as "new work". It is a straightforward application of MP-BGP. Peter _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA11619 for ; Fri, 3 Dec 2004 15:07:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaJRr-0000zu-0s; Fri, 03 Dec 2004 14:50:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaJ0K-0006pi-PW for idr@megatron.ietf.org; Fri, 03 Dec 2004 14:22:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24273 for ; Fri, 3 Dec 2004 14:22:07 -0500 (EST) Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CaJ67-00012h-QG for idr@ietf.org; Fri, 03 Dec 2004 14:28:08 -0500 Received: (qmail 24775 invoked from network); 3 Dec 2004 19:22:02 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 3 Dec 2004 19:22:02 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id iB3JM9gd004115; Fri, 3 Dec 2004 14:22:10 -0500 (EST) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200412031922.iB3JM9gd004115@workhorse.faster-light.net> To: "Busschbach, Peter B (Peter)" Subject: Re: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? In-reply-to: Your message of "Wed, 01 Dec 2004 10:02:56 EST." Date: Fri, 03 Dec 2004 14:22:09 -0500 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org In message "Busschbach, Peter B (Peter)" writes: > > We recently published a new version of "Carrying ATM reachability information in BGP" > > http://www.ietf.org/internet-drafts/draft-ck-bgp-atm-nlri-01.txt > > The differences with the previous version are minor: > > - A few textual changes in the introduction > > - Clarification of how to map the four-byte ATM Administrative Weight in the corresponding Extended Communities attribute > > - Addition of a paragraph on the use of the Site of Origin attribute > > > > As discussed in the WG meeting in Washington D.C., we would like the working group to accept this draft as a working group document. Please respond to this email with your comments. > > Thanks, > > CK > Chris Metz > Peter Busschbach > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr Is anyone actually interested in deploying this or is it more of an intellectual exercise. The routing area has in the past required that there be a clear requirement for new work in a work group. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA11687 for ; Wed, 1 Dec 2004 12:36:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZXY1-0000LG-0s; Wed, 01 Dec 2004 11:41:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZW1M-0001Pn-62 for idr@megatron.ietf.org; Wed, 01 Dec 2004 10:03:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06967 for ; Wed, 1 Dec 2004 10:03:55 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZW6f-0001sv-V6 for idr@ietf.org; Wed, 01 Dec 2004 10:09:27 -0500 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iB1F300I013303 for ; Wed, 1 Dec 2004 09:03:07 -0600 (CST) Received: by NJ7460EXCH001H with Internet Mail Service (5.5.2657.72) id <4M3JBDBX>; Wed, 1 Dec 2004 10:02:58 -0500 Message-ID: From: "Busschbach, Peter B (Peter)" To: idr@ietf.org Date: Wed, 1 Dec 2004 10:02:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Idr] draft-ck-bgp-atm-nlri-01.txt to become a working group document? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org We recently published a new version of "Carrying ATM reachability information in BGP" http://www.ietf.org/internet-drafts/draft-ck-bgp-atm-nlri-01.txt The differences with the previous version are minor: - A few textual changes in the introduction - Clarification of how to map the four-byte ATM Administrative Weight in the corresponding Extended Communities attribute - Addition of a paragraph on the use of the Site of Origin attribute As discussed in the WG meeting in Washington D.C., we would like the working group to accept this draft as a working group document. Please respond to this email with your comments. Thanks, CK Chris Metz Peter Busschbach _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr