From mailman-bounces@ietf.org Sun Aug 1 07:07:42 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 HAA12119 for ; Sun, 1 Aug 2004 07:07:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrEEW-0001Nn-UJ for idr-archive@ietf.org; Sun, 01 Aug 2004 07:10:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrCXW-0001t4-Ru for idr-archive@ietf.org; Sun, 01 Aug 2004 05:21:58 -0400 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: Sun, 01 Aug 2004 05:05:37 -0400 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 Mon Aug 2 16:39:37 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 QAA04097; Mon, 2 Aug 2004 16:39:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Brjdl-00047L-Np; Mon, 02 Aug 2004 16:42:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrjRr-0005DS-2s; Mon, 02 Aug 2004 16:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrjIY-0000nB-J3 for idr@megatron.ietf.org; Mon, 02 Aug 2004 16:20:42 -0400 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 QAA01806 for ; Mon, 2 Aug 2004 16:20:40 -0400 (EDT) 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 1BrjLT-0003kV-Ek for idr@ietf.org; Mon, 02 Aug 2004 16:23:44 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 21CD02D481B for ; Mon, 2 Aug 2004 16:20:10 -0400 (EDT) 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 24933-03-69 for ; Mon, 2 Aug 2004 16:20:09 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id F14372D4814 for ; Mon, 2 Aug 2004 16:20:09 -0400 (EDT) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Aug 2004 16:20:09 -0400 Message-ID: Thread-Topic: Feedback on the FSM and Dynamic capbility revision Thread-Index: AcR4zfMthK73qK9qQuK2i97tkINn+A== From: "Susan Hares" To: X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Subject: [Idr] Feedback on the FSM and Dynamic capbility revision 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 Content-Transfer-Encoding: quoted-printable Enke: The FSM was limited to the base specification. I believe that the addition of the Dynamic Capability as an addition to the base specification needs an addition to the FSM. I would suggest that text be added to the draft to indicate the FSM additions. Sue Hares _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 5 18:31:12 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 SAA22495; Thu, 5 Aug 2004 18:31:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bsqp6-0006q1-7A; Thu, 05 Aug 2004 18:34:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsqXH-00023T-CU; Thu, 05 Aug 2004 18:16:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsqVA-0000mF-Eg for idr@megatron.ietf.org; Thu, 05 Aug 2004 18:14:21 -0400 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 SAA20701 for ; Thu, 5 Aug 2004 18:14:17 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsqYi-0006LX-IX for idr@ietf.org; Thu, 05 Aug 2004 18:18:02 -0400 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 i75MDj911985; Thu, 5 Aug 2004 15:13:45 -0700 (PDT) (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 i75MDee89497; Thu, 5 Aug 2004 15:13:40 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200408052213.i75MDee89497@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <79508.1091744020.1@juniper.net> Date: Thu, 05 Aug 2004 15:13:40 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: enke@redback.com, skh@nexthop.com Subject: [Idr] draft-chen-bgp-prefix-orf-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.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Folks, There is a consensus to accept draft-chen-bgp-prefix-orf-07.txt as an IDR WG document. I'd like to ask the authors to resubmit it as draft-ietf-idr-bgp-prefix-orf-00.txt. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 11 23:18:30 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 XAA11465; Wed, 11 Aug 2004 23:18:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv6Bj-0001ZT-DP; Wed, 11 Aug 2004 23:23:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv61I-0002cS-Nv; Wed, 11 Aug 2004 23:12:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv60b-0002Tl-RQ for idr@megatron.ietf.org; Wed, 11 Aug 2004 23:12:06 -0400 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 XAA11250 for ; Wed, 11 Aug 2004 23:12:03 -0400 (EDT) Received: from zsc3s004.nortelnetworks.com ([47.81.138.65]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv65S-0001Um-W8 for idr@ietf.org; Wed, 11 Aug 2004 23:17:08 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7C3BSB29606; Wed, 11 Aug 2004 20:11:28 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Aug 2004 20:11:28 -0700 Message-ID: <0A11633F61BD9F40B43ABCC694004F93067EC2FA@zsc3c026.us.nortel.com> From: "Praveen Muley" To: "'Susan Hares'" , idr@ietf.org Date: Wed, 11 Aug 2004 20:11:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Idr] http://ietfreport.isoc.org/ids/draft-muley-hares-idr-orf-order-00 .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: , Content-Type: multipart/mixed; boundary="===============0717536040==" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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. --===============0717536040== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4801A.0F2CE704" 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_01C4801A.0F2CE704 Content-Type: text/plain Hello Pedros, A simple example for Group ORF can be multiple VRFs having different set of prefix filters. In that case say extended community Green for Green VRF and Red extended community for Red VRF with different prefix filters need to be send to the BGP peer. Today there is difficulty in expressing this, while carrying multiple ORF entries as relationship between the ORF entries of one type of ORF to another cannot be expressed ( or rather say its strict) as same ORF types are clubbed together and hence applying granular policy is an issue. Grouping helps in solving this. Regards, Praveen ------_=_NextPart_001_01C4801A.0F2CE704 Content-Type: text/html Content-Transfer-Encoding: quoted-printable http://ietfreport.isoc.org/ids/draft-muley-hares-idr-orf-order-00= .txt

Hello Pedros,
          A = simple example for Group ORF can be multiple VRFs having different set = of prefix filters. In that case say extended community Green for Green = VRF and Red extended community for Red VRF with different prefix = filters need to be send to the BGP peer.

          &nb= sp;           &nb= sp;           &nb= sp;  Today there is difficulty in expressing this, while carrying = multiple ORF entries as relationship between the ORF entries of one = type of ORF to another cannot be expressed ( or rather say its strict) = as same ORF types are clubbed together and hence applying granular = policy is an issue. Grouping helps in solving this. 

          &nb= sp;           &nb= sp; 
Regards,
Praveen
          &nb= sp;           &nb= sp;     

------_=_NextPart_001_01C4801A.0F2CE704-- --===============0717536040== 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 --===============0717536040==-- From idr-bounces@ietf.org Thu Aug 12 13:33: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 NAA17888; Thu, 12 Aug 2004 13:33:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvJXa-0000KS-LO; Thu, 12 Aug 2004 13:39:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvJ8y-0004fL-PY; Thu, 12 Aug 2004 13:13:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvJ1s-0002Jm-Ln for idr@megatron.ietf.org; Thu, 12 Aug 2004 13:06:16 -0400 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 NAA15873 for ; Thu, 12 Aug 2004 13:06:13 -0400 (EDT) Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvJ6r-00088D-ID for idr@ietf.org; Thu, 12 Aug 2004 13:11:26 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i7CH5hPm084207; Thu, 12 Aug 2004 10:05:43 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i7CH5h87084204; Thu, 12 Aug 2004 10:05:43 -0700 (PDT) From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16667.41831.444848.174439@roque-bsd.juniper.net> Date: Thu, 12 Aug 2004 10:05:43 -0700 To: "Praveen Muley" Subject: [Idr] draft-muley-hares-idr-orf-order-00.txt In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93067EC2FA@zsc3c026.us.nortel.com> References: <0A11633F61BD9F40B43ABCC694004F93067EC2FA@zsc3c026.us.nortel.com> X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit 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.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Praveen Muley writes: > Hello Pedros, A simple example for Group ORF can be multiple VRFs > having different set of prefix filters. In that case say extended > community Green for Green VRF and Red extended community for Red VRF > with different prefix filters need to be send to the BGP peer. Praveen, the orf-order draft, as currently specified, does not seem to me to be able to express that problem... i.e. you seem to want to express a set of expressions such as (a && b) || (c && d) || ... it would also be an inneficient way to solve the problem you mention... you do not want to perform a sequential search through the extended community space. But all of these are, imho, quite secondary compared to the question of why would you do this in the first place... I would expect that if you want prefix filters torwards you VRF client that you would want to apply them in the PE-CE routing adjacency... > Today there is difficulty in expressing this, while carrying > multiple ORF entries as relationship between the ORF entries of one > type of ORF to another cannot be expressed ( or rather say its > strict) as same ORF types are clubbed together and hence applying > granular policy is an issue. Grouping helps in solving this. There may be applications that require the ability to combine different filters... but ORF should not become a replacement for a configuration distribution mecanism. imho, ORF should be reserved for situations where there is a clear advantage in performing the filtering outbound *as well as* inbound on a session. I think it is important to define what problems you intend to solve, to demonstrate how you solve the problem and compare with other possible solutions. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 12 22:53:16 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 WAA26291; Thu, 12 Aug 2004 22:53:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvSH3-00045t-RV; Thu, 12 Aug 2004 22:58:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvSA6-0004hR-39; Thu, 12 Aug 2004 22:51:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvS9H-0004Hr-Ky for idr@megatron.ietf.org; Thu, 12 Aug 2004 22:50:31 -0400 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 WAA26214 for ; Thu, 12 Aug 2004 22:50:29 -0400 (EDT) Received: from 193.cust11.sa.dsl.ozemail.com.au ([210.84.234.193] helo=dupy2.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvSEL-00042o-5B for idr@ietf.org; Thu, 12 Aug 2004 22:55:47 -0400 Received: from Dupy2.nosense.org (localhost.localdomain [127.0.0.1]) by dupy2.nosense.org (Postfix) with SMTP id E2E803F019 for ; Fri, 13 Aug 2004 12:19:41 +0930 (CST) Date: Fri, 13 Aug 2004 12:19:41 +0930 From: Mark Smith To: idr@ietf.org Message-Id: <20040813121941.18b5955f.ietf@130c04165a5b40404e4440445758487a.nosense.org> Organization: The No Sense Organisation (http://www.nosense.org) X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Adelaide, Australia Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Subject: [Idr] Worth putting in an RFC ? Use IP / GRE tunnels between EBGP peers 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: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Hi, The idea is to create IP in IP or GRE tunnels between the EBGP routers within the AS, run IBGP over the tunnels, and then also use those tunnels for transit traffic. If this idea has been thought of before, and dismissed, please disregard the rest of this email. I think this idea is similar to the way MPLS can be used to transport traffic across a transit AS, where the MPLS LSPs target the NEXT_HOP attribute. At least that's how I understand how MPLS can be used to optimise BGP within an AS. I originally worked out this idea when I was learning BGP a few years ago, although I haven't had a chance to test it. I was surprised when I started learning MPLS how similar the MPLS solution is. I do think the MPLS solution is better. This solution could be used as a transitional step towards MPLS, or maybe as a contingency if there are issues with the transit routers for some reason (eg. running out of memory for the Internet route table). Here are some advantages. As this solution is similar to the MPLS one, there is quite a lot of overlap. (a) obviously, not having to run BGP to the transit routers within the AS. (b) therefore, internal transit routers don't have to maintain full Internet route tables (c) simpler to deploy than the MPLS solution. MPLS deployment is likely to require software / firmware upgrades in the transit routers. If I understand the MPLS itself, and the MPLS solution correctly, it also requires that all routers between the AS edge routers are MPLS enabled before MPLS can be used. I'd suspect the majority of current AS border routers already contain IP in IP / GRE functionality that just needs to be configured. Transit routers within the AS need no additional configuration at all. (d) If the BGP keep alive timer is set large enough, the tunnel will hide transients in the underlying transit network. Of course, there are some drawbacks. (a) The tunnel header overhead added to the transiting IP packets. This may cause PMTUD to have to discover a new PMTU. (b) A full mesh of tunnels needs to be set up between all the EBGP routers in the AS. While this is simpler than a full IBGP mesh between all AS transit routers, it doesn't scale upwards. At a certain point, other "mesh mitigation" techniques will become more effective. (b) can't really think of any others now, that certainly doesn't mean there aren't any :-) I'm willing to have a go at writing something up if there is enough value in this idea. Thanks, Mark. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 12 23:38:50 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 XAA28851; Thu, 12 Aug 2004 23:38:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvSzA-0004sA-7O; Thu, 12 Aug 2004 23:44:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvSst-0003ma-Tx; Thu, 12 Aug 2004 23:37:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvSpG-0003V9-3P for idr@megatron.ietf.org; Thu, 12 Aug 2004 23:33:54 -0400 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 XAA28678 for ; Thu, 12 Aug 2004 23:33:51 -0400 (EDT) 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 1BvSuK-0004nV-Mf for idr@ietf.org; Thu, 12 Aug 2004 23:39:09 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C072C2D4827; Thu, 12 Aug 2004 23:33:21 -0400 (EDT) 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 89241-02; Thu, 12 Aug 2004 23:33:21 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 183B62D481A; Thu, 12 Aug 2004 23:30:33 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i7D3UW622244; Thu, 12 Aug 2004 23:30:32 -0400 (EDT) Date: Thu, 12 Aug 2004 23:30:32 -0400 From: Jeffrey Haas To: Mark Smith Subject: Re: [Idr] Worth putting in an RFC ? Use IP / GRE tunnels between EBGP peers Message-ID: <20040813033032.GA22219@nexthop.com> References: <20040813121941.18b5955f.ietf@130c04165a5b40404e4440445758487a.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040813121941.18b5955f.ietf@130c04165a5b40404e4440445758487a.nosense.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: 9466e0365fc95844abaf7c3f15a05c7d On Fri, Aug 13, 2004 at 12:19:41PM +0930, Mark Smith wrote: > The idea is to create IP in IP or GRE tunnels between the EBGP > routers within the AS, run IBGP over the tunnels, and then also use those > tunnels for transit traffic. That which was once old is made again new. :-) [RFC 1772, A.2.3] A.2.3 Encapsulation Encapsulation provides the simplest (in terms of the interaction between the IGP and BGP) mechanism for carrying transit traffic across the AS. In this approach, transit traffic is encapsulated within an IP datagram addressed to the exit gateway. The only requirement imposed on the IGP by this approach is that it should be capable of supporting routing between border gateways within the same AS. It is well worth the time for relative newcomers to read the 177x series of documents. They encapsulate a lot of old wisdom. :-) -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 13 00:52:26 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 AAA03328; Fri, 13 Aug 2004 00:52:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvU8P-0006Dm-Ru; Fri, 13 Aug 2004 00:57:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvTyE-0000Cc-Cv; Fri, 13 Aug 2004 00:47:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvTwQ-0008He-2i for idr@megatron.ietf.org; Fri, 13 Aug 2004 00:45:22 -0400 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 AAA03083 for ; Fri, 13 Aug 2004 00:45:19 -0400 (EDT) Received: from 193.cust11.sa.dsl.ozemail.com.au ([210.84.234.193] helo=dupy2.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvU1U-00067N-QD for idr@ietf.org; Fri, 13 Aug 2004 00:50:38 -0400 Received: from Dupy2.nosense.org (localhost.localdomain [127.0.0.1]) by dupy2.nosense.org (Postfix) with SMTP id A327F3F019; Fri, 13 Aug 2004 14:14:46 +0930 (CST) Date: Fri, 13 Aug 2004 14:14:46 +0930 From: Mark Smith To: Jeffrey Haas Subject: Re: [Idr] Worth putting in an RFC ? Use IP / GRE tunnels between EBGP peers Message-Id: <20040813141446.1dea9ed1.ietf@130c04165a5b40404e4440445758487a.nosense.org> In-Reply-To: <20040813033032.GA22219@nexthop.com> References: <20040813121941.18b5955f.ietf@130c04165a5b40404e4440445758487a.nosense.org> <20040813033032.GA22219@nexthop.com> Organization: The No Sense Organisation (http://www.nosense.org) X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Adelaide, Australia Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit 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: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Hi Jeff, Thanks for getting back to me. On Thu, 12 Aug 2004 23:30:32 -0400 Jeffrey Haas wrote: > On Fri, Aug 13, 2004 at 12:19:41PM +0930, Mark Smith wrote: > > The idea is to create IP in IP or GRE tunnels between the EBGP > > routers within the AS, run IBGP over the tunnels, and then also use those > > tunnels for transit traffic. > > That which was once old is made again new. :-) > > [RFC 1772, A.2.3] > A.2.3 Encapsulation > > Encapsulation provides the simplest (in terms of the interaction > between the IGP and BGP) mechanism for carrying transit traffic > across the AS. In this approach, transit traffic is encapsulated > within an IP datagram addressed to the exit gateway. The only > requirement imposed on the IGP by this approach is that it should be > capable of supporting routing between border gateways within the same > AS. > > It is well worth the time for relative newcomers to read the 177x > series of documents. They encapsulate a lot of old wisdom. :-) > I agree. I have glossed through 1771, I haven't got to reading the others :-) It would seem that the authors of the few books I've got on BGP have either read them and forgotten about this, or possibly never read them thoroughly enough either, as I've never come across any mention of this technique. That is why I thought it might be new, at least when it came to using IP/IP or GRE tunnels for this purpose vs. MPLS. Thanks, Mark. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 13 18:16: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 SAA22293; Fri, 13 Aug 2004 18:16:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvkQd-0000iQ-NJ; Fri, 13 Aug 2004 18:21:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvkIc-0007xv-8q; Fri, 13 Aug 2004 18:13:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvkFV-0005w6-OL for idr@megatron.ietf.org; Fri, 13 Aug 2004 18:10:09 -0400 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 SAA21465 for ; Fri, 13 Aug 2004 18:10:06 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.199] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvkKk-0000ay-H0 for idr@ietf.org; Fri, 13 Aug 2004 18:15:35 -0400 Received: by mproxy.gmail.com with SMTP id 73so43389rnl for ; Fri, 13 Aug 2004 15:10:06 -0700 (PDT) Received: by 10.38.59.23 with SMTP id h23mr152676rna; Fri, 13 Aug 2004 15:10:06 -0700 (PDT) Message-ID: <38a0ff0504081315104c47f837@mail.gmail.com> Date: Fri, 13 Aug 2004 15:10:06 -0700 From: Vivek Menezes To: Mark Smith Subject: Re: Re: [Idr] Worth putting in an RFC ? Use IP / GRE tunnels between EBGP peers In-Reply-To: <20040813141446.1dea9ed1.ietf@130c04165a5b40404e4440445758487a.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040813121941.18b5955f.ietf@130c04165a5b40404e4440445758487a.nosense.org> <20040813033032.GA22219@nexthop.com> <20040813141446.1dea9ed1.ietf@130c04165a5b40404e4440445758487a.nosense.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, Jeffrey Haas 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 Content-Transfer-Encoding: 7bit Mark, > > It would seem that the authors of the few books I've got on BGP > have either read them and forgotten about this, or possibly never read them > thoroughly enough either, as I've never come across any mention of this > technique. That is why I thought it might be new, at least when it came to > using IP/IP or GRE tunnels for this purpose vs. MPLS. RFCs should to be written only for protocol compliance between vendors. Having an RFC describe a particular implementation doesn't add much value. You can also use ATM to do what you are suggesting :-) Vivek. > > Thanks, > Mark. > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 13 22:27:39 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 WAA03394; Fri, 13 Aug 2004 22:27:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvoM1-000478-SU; Fri, 13 Aug 2004 22:33:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvoDM-0007T0-JJ; Fri, 13 Aug 2004 22:24:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvoC7-0007De-Ix for idr@megatron.ietf.org; Fri, 13 Aug 2004 22:22:55 -0400 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 WAA03052 for ; Fri, 13 Aug 2004 22:22:53 -0400 (EDT) Received: from 241.cust4.sa.dsl.ozemail.com.au ([210.84.227.241] helo=dupy2.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvoHO-000426-3M for idr@ietf.org; Fri, 13 Aug 2004 22:28:23 -0400 Received: from Dupy2.nosense.org (localhost.localdomain [127.0.0.1]) by dupy2.nosense.org (Postfix) with SMTP id 11C913F019; Sat, 14 Aug 2004 11:52:15 +0930 (CST) Date: Sat, 14 Aug 2004 11:52:15 +0930 From: Mark Smith To: Vivek Menezes Subject: Re: [Idr] Worth putting in an RFC ? Use IP / GRE tunnels between EBGP peers Message-Id: <20040814115215.56edebf3.ietf@130c04165a5b40404e4440445758487a.nosense.org> In-Reply-To: <38a0ff0504081315104c47f837@mail.gmail.com> References: <20040813121941.18b5955f.ietf@130c04165a5b40404e4440445758487a.nosense.org> <20040813033032.GA22219@nexthop.com> <20040813141446.1dea9ed1.ietf@130c04165a5b40404e4440445758487a.nosense.org> <38a0ff0504081315104c47f837@mail.gmail.com> Organization: The No Sense Organisation (http://www.nosense.org) X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Adelaide, Australia Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit 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: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Hi Vivek, On Fri, 13 Aug 2004 15:10:06 -0700 Vivek Menezes wrote: > Mark, > > > > > It would seem that the authors of the few books I've got on BGP > > have either read them and forgotten about this, or possibly never read > > them thoroughly enough either, as I've never come across any mention of > > this technique. That is why I thought it might be new, at least when it > > came to using IP/IP or GRE tunnels for this purpose vs. MPLS. > > RFCs should to be written only for protocol compliance between > vendors. Having an RFC > describe a particular implementation doesn't add much value. I was thinking along the lines of an Informational RFC describing this method. I though that the scope of the IDR working group might also cover Informational RFCs regarding the use of BGP. I've realised that might not be the case. Appologies to everyone if I was wrong. Thanks, Mark. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Aug 14 14:06: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 OAA24204; Sat, 14 Aug 2004 14:06:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bw30I-0008P2-1I; Sat, 14 Aug 2004 14:11:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bw2sg-0007Dt-Ic; Sat, 14 Aug 2004 14:03:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bw2rC-0006zw-VC for idr@megatron.ietf.org; Sat, 14 Aug 2004 14:02:19 -0400 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 OAA24135 for ; Sat, 14 Aug 2004 14:02:17 -0400 (EDT) Received: from relay.pair.com ([209.68.1.20]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bw2wd-0008My-CO for idr@ietf.org; Sat, 14 Aug 2004 14:07:55 -0400 Received: (qmail 22889 invoked from network); 14 Aug 2004 18:02:04 -0000 Received: from dialup-4.156.51.22.dial1.boston1.level3.net (HELO laptoy770.faster-light.net) (4.156.51.22) by relay.pair.com with SMTP; 14 Aug 2004 18:02:04 -0000 X-pair-Authenticated: 4.156.51.22 Received: from laptoy770.faster-light.net (localhost [127.0.0.1]) by laptoy770.faster-light.net (8.12.9p2/8.12.9) with ESMTP id i7EI545f055251; Sat, 14 Aug 2004 14:05:05 -0400 (EDT) (envelope-from curtis@laptoy770.faster-light.net) Message-Id: <200408141805.i7EI545f055251@laptoy770.faster-light.net> To: Mark Smith Subject: Re: [Idr] Worth putting in an RFC ? Use IP / GRE tunnels between EBGP peers In-reply-to: Your message of "Sat, 14 Aug 2004 11:52:15 +0930." <20040814115215.56edebf3.ietf@130c04165a5b40404e4440445758487a.nosense.org> Date: Sat, 14 Aug 2004 14:05:03 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: idr@ietf.org, Vivek Menezes 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.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 In message <20040814115215.56edebf3.ietf@130c04165a5b40404e4440445758487a.nosense.org> Mark Smith writes: > > On Fri, 13 Aug 2004 15:10:06 -0700 > Vivek Menezes wrote: > > > > > > It would seem that the authors of the few books I've got on BGP > > > have either read them and forgotten about this, or possibly never read > > > them thoroughly enough either, as I've never come across any mention of > > > this technique. That is why I thought it might be new, at least when it > > > came to using IP/IP or GRE tunnels for this purpose vs. MPLS. > > > > RFCs should to be written only for protocol compliance between > > vendors. Having an RFC > > describe a particular implementation doesn't add much value. > > I was thinking along the lines of an Informational RFC describing this method. > > I though that the scope of the IDR working group might also cover > Informational RFCs regarding the use of BGP. I've realised that might not be > the case. Appologies to everyone if I was wrong. > > Thanks, > Mark. Mark, 1. This is something already known. 2. It is a trivial observation. 3. It is already documented. 4. This would be a rather pointless exercise. It seems like you want to have your name on an informational RFC and you are fishing for something to write about. This is clearly not something worthy of its own informational RFC. btw- Anyone can submit an individual internet-draft and ask that the IESG consider it directly. If it is deemed by the IESG to fall within or close to the general scope of an existing WG it will be forwarded to that WG. That means that if it is related to BGP it will most likely end up right back here. So far all of the responses are telling you it is not material for an RFC. If you actually knew the pros and cons of a full mesh of BGP over a tunnelled infrastructure then *maybe* it would be worth an RFC. But then it wouldn't be about BGP over GRE. It would be about the early UUNET brief experience with IP over ATM, about the former InterneetMCI's brief experience with full mesh ATM and the IGP problems, and C&W's experience with FR over CCC over MPLS (and anyone else that tried something like this). It would explain why RFC1577 was a non-starter as far as ISPs were concerned in its time and why the "BGP free core" with tunneling can in some cases share the same characteristics that made RFC1577 a non-starter. This would be best writen by someone who was either directly involved or very familiar with the issues in each of these and/or well connected enough to contact people who were directly involved. Even these are somewhat documented if you count such things Dave Katz presentation on IGP scaling at NANOG for which he didn't submit slides and numerous discussion about the motivations for IGP mesh groups and discussions on the now defunct IP over ATM WG, ION, and others. It would also explain the "pros" of running a BGP mesh over some sort of tunneling and how MPLS/RSVP solved these without the cons that came with IP over ATM. Other tunneling with no TE capability just accomplishes a subset of the perceived "pros" which is the trivial observation you've made. Even if someone wrote such a document there would be considerable discussion over exactly how significant each of the pros and cons are. The actual experiences are at least difficult to dispute but provide only a limited set of data points. The extrapolation to today's topologies and technology would be the area of disagreement. You haven't demonstrated in your few brief messages that you have the slightest clue about the existing known issues or what has been written about them in the past and which somewhat significant points have not been clearly documented. If you think you can enlighten us, go for it. If you are just going to point out that it is possible to run BGP over GRE you don't have material for an RFC. Curtis _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 16 05:03: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 FAA19537; Mon, 16 Aug 2004 05:03:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwdV2-0005GP-3x; Mon, 16 Aug 2004 05:09:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwd8H-0008Oa-DL; Mon, 16 Aug 2004 04:46:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwd7S-00085S-Fz for idr@megatron.ietf.org; Mon, 16 Aug 2004 04:45:30 -0400 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 EAA18709 for ; Mon, 16 Aug 2004 04:45:28 -0400 (EDT) Received: from bay17-f33.bay17.hotmail.com ([64.4.43.83] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwdDD-0004wR-Ef for idr@ietf.org; Mon, 16 Aug 2004 04:51:28 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 16 Aug 2004 01:44:58 -0700 Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Mon, 16 Aug 2004 08:44:58 GMT X-Originating-IP: [61.16.170.194] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: idr@ietf.org Subject: RE: [Idr] draft-muley-hares-idr-orf-order-00.txt Date: Mon, 16 Aug 2004 08:44:58 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Aug 2004 08:44:58.0543 (UTC) FILETIME=[4FB93BF0:01C4836D] X-Spam-Score: 0.9 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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.9 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This maybe the wrong working group to ask but this question is somewhat releated to the point Praveen was making, Q. How do I withdraw an LSP using CR-LDP?? :( >From: Pedro Roque Marques >To: "Praveen Muley" >CC: idr@ietf.org >Subject: [Idr] draft-muley-hares-idr-orf-order-00.txt >Date: Thu, 12 Aug 2004 10:05:43 -0700 > >Praveen Muley writes: > > > Hello Pedros, A simple example for Group ORF can be multiple VRFs > > having different set of prefix filters. In that case say extended > > community Green for Green VRF and Red extended community for Red VRF > > with different prefix filters need to be send to the BGP peer. > >Praveen, >the orf-order draft, as currently specified, does not seem to me to be >able to express that problem... > >i.e. you seem to want to express a set of expressions such as > (a && b) || (c && d) || ... > >it would also be an inneficient way to solve the problem you >mention... you do not want to perform a sequential search through the >extended community space. > >But all of these are, imho, quite secondary compared to the >question of why would you do this in the first place... > >I would expect that if you want prefix filters torwards you VRF client >that you would want to apply them in the PE-CE routing adjacency... > > > Today there is difficulty in expressing this, while carrying > > multiple ORF entries as relationship between the ORF entries of one > > type of ORF to another cannot be expressed ( or rather say its > > strict) as same ORF types are clubbed together and hence applying > > granular policy is an issue. Grouping helps in solving this. > >There may be applications that require the ability to combine >different filters... but ORF should not become a replacement for a >configuration distribution mecanism. imho, ORF should be reserved for >situations where there is a clear advantage in performing the >filtering outbound *as well as* inbound on a session. > >I think it is important to define what problems you intend to solve, >to demonstrate how you solve the problem and compare with other >possible solutions. > > Pedro. > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 18 16:22: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 QAA10174; Wed, 18 Aug 2004 16:22:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxX3m-0007Tw-1j; Wed, 18 Aug 2004 16:29:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxW3i-00040q-Bi; Wed, 18 Aug 2004 15:25:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxW1T-0002wK-HD; Wed, 18 Aug 2004 15:22:59 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01337; Wed, 18 Aug 2004 15:22:27 -0400 (EDT) Message-Id: <200408181922.PAA01337@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 18 Aug 2004 15:22:27 -0400 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-dynamic-cap-06.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: 14582b0692e7f70ce7111d04db3781c8 --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 : Dynamic Capability for BGP-4 Author(s) : E. Chen, S. Sangli Filename : draft-ietf-idr-dynamic-cap-06.txt Pages : 8 Date : 2004-8-18 This document defines a new BGP capability termed 'Dynamic Capability', which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-dynamic-cap-06.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-dynamic-cap-06.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-dynamic-cap-06.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-8-18143111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-dynamic-cap-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-dynamic-cap-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-18143111.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 Aug 24 13:36:46 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 NAA26743; Tue, 24 Aug 2004 13:36:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzfEY-0005Ro-NK; Tue, 24 Aug 2004 13:37:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzes2-0006ex-7v; Tue, 24 Aug 2004 13:14:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzeWY-0000tu-UR for idr@megatron.ietf.org; Tue, 24 Aug 2004 12:51:54 -0400 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 MAA21668 for ; Tue, 24 Aug 2004 12:51:46 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzeWy-0004KH-MJ for idr@ietf.org; Tue, 24 Aug 2004 12:52:24 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Aug 2004 09:53:27 -0700 X-BrightmailFiltered: true Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i7OGpBhg013114 for ; Tue, 24 Aug 2004 09:51:12 -0700 (PDT) Received: from [64.101.214.222] (dhcp-64-101-215-163.cisco.com [64.101.215.163]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA13915 for ; Tue, 24 Aug 2004 12:51:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: Date: Tue, 24 Aug 2004 12:51:05 -0400 To: idr@ietf.org From: "John G. Scudder" Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8d68e55b48f2ff3cebd1a6416d9536 Content-Transfer-Encoding: quoted-printable Subject: [Idr] Draft minutes for August 2 meeting 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: 9a0f005dcc96c32c6d659bdf82d519da Content-Transfer-Encoding: quoted-printable Inter-Domain Routing WG (idr) Monday, August 2 at 1300-1500 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D CHAIRS: Susan Hares Yakov Rekhter SCRIBES: Ignas Bagdonas John Scudder David Ward See proceedings=20 (http://www.ietf.org/proceedings/04aug/index.html)=20 for presentation slides. ---- Document Status Update (5 mins) S. Hares, Y. Rekhter Presenter: Yakov =46our new work items accepted since last IETF, good consensus. Other items proposed, not sufficient consensus, not accepted as WG items. IESG review of BGP base spec package is done,=20 comments incorporated (BGP-4, MIB, etc). Will=20 issue further revisions as needed. Submitted 6 docs to IESG to advance since last IETF (GR, extcomm, etc) Confeds -- need to be updated with comments from=20 last call, need implementation report -- once=20 done, to IESG. No new progress until >=3D 2 impls: - ORF - 4-octet ASN - AS path ORF - MIB - AS wide unique identifier Questions/Comments: Susan Harris: Just to clarify - which document was reclassified to historic? Yakov: RFC 1863. ---- Dynamic Capability for BGP-4 (10 mins) draft-ietf-idr-dynamic-cap-05.txt Enke Chen, Srihari R. Sangli Presenter: Enke Additions to support capabilities which affect Update encoding: - Ack request - Ack - Sequence number What capabilities need ack? - 4-byte AS - Multipath - Address Family (probably) Ack is optional so need not be used for capabilities that don't require it. Unfortunately ack is not backward compatible.=20 Want to reuse current code point (fine if=20 little/no deployment w/ prev spec version) or get=20 new code point? Questions/Comments: Yakov: Get a new code point, we have hundreds of 'em, no need to economize. Martin Djernaes: Why not increase capability=20 number space to 16 bits, also length to 16 bits? Chandra Appanna: Agreed, increase sizes. Chandra: What impact on the state machine? Enke: Little or none, session is already established. Chandra: Really? What about when you send a=20 capability which changes something you negotiated=20 at OPEN time? Tony Li: Reserve one value "for future extensions" Enke: Does anyone really need more length than 255? Many: Yes. (Out of time, move to mailing list) ---- Advertisement of the Group Best Paths in BGP (15 mins) draft-chen-bgp-group-path-update-01.txt E. Chen, N. Chen Presenter: Enke Why? Persistent oscillation issues -- RR or confederation. Observations: - Full mesh is free of oscillations - Route selection groups paths based on neighbor AS. Two approaches: - Advertise group-best (i.e. best path from each=20 neighbor AS) -- eliminates MED oscillation, still=20 vulnerable to topology-based issues, still=20 reduces info vs. full mesh. Paths adv'd =3D=3D=20 number of neighbor ASes. Topology issues means=20 that IGP constraints still apply -- intra-cluster=20 links must have smaller metrics than=20 inter-cluster links. - Advertise group multi-path -- adv all paths=20 that survive MED comparison -- effectively makes=20 RR advertisements independent of IGP metrics.=20 However, virtually as much state as full mesh.=20 Suggestions: accept MED, reduces number of routes=20 that survive MED step =3D=3D> fewer routes advertised. Encoding: - must be changed (pfx, neighbor_as) for=20 group-best, (pfx, originator_id) for=20 group-multipath - no encoding change for reachable routes=20 (because neighbor_as, orig_id already in update) - need new encoding for w/draw - therefore need new capability to indicate=20 ability to parse new w/draw and all, also=20 advertises which mode to be used (best only,=20 group best, multi) Implementation/deployment: - only RR/confed BR need to advertise multiple paths - non-RR need only to Rx, not Tx -- Rx is easy recommendation: - Use group-best, incremental deployment.=20 group-multi solves more problems but too many=20 paths Questions/Comments: Pedro Marques: We could use the route server doc=20 we just moved to historical for this instead of=20 using this encoding. One reason I would like to=20 use a new path attribute is because some non RR=20 might like to do this, in which case originator=20 ID won't work. Since there's no backward=20 compatibility anyway, why try to reuse existing=20 semantics? Enke: I think Orig_ID is a good fit. Yakov: Neighbor AS hack won't work with AS set. Enke: When advertising, you must create AS=20 sequence, this is in base specification. John Scudder: I agree w/ Pedro. If defining a=20 capability, then use a new encoding. Most=20 important contribution of this draft is not=20 encoding, what is most important is ruleset of=20 what to advert and when. Enke: Yakov: There is little value to send the same information in the same messag= e twice. Pedro: What about non-RR? You have to have the=20 exit point (external box) to be able to do this.=20 The originator_id only works for RR server. John: If define a way to solve multi-path in BGP,=20 please solve the general case and not just the=20 oscillation case. Enke: There are a lot of issues if we generalize and I don't know any exampl= es. (Out of time, move to mailing list) ---- Graceful Shutdown of BGP Sessions (15 mins) draft-dubois-bgp-planned-maintenance-00.txt N. Dubois, B. Decraene, B. Fondeviole Presenter: Nicolas Why? - Want no packet loss during maintenance=A0 - Current is break paths and then inform peers - Want make-before-break NOTE: not always useful for single IBGP session Observed behavior: - in small network test, router shutdown goes from 20s traffic loss to 0s - w/ 100k routes 20ms loss vs 4 sec loss - timer should be between 30 and 60s draft was too conservative w/ 300s Questions/Comments: Tony Li: What happens if the router undergoing=20 maintenance simply withdraws in an orderly fashion Nicolas: Yes, that is exactly what the draft proposes John Scudder: No changes to BGP? Can you do this with a route map? Nicolas: No changes to BGP state machine. Can=20 be done w/ route-map -- did that for testing.=20 But, too hard for ops people. ---- Group Cooperative Route Filtering Capability for BGP-4 (10 mins) draft-muley-hares-idr-orf-order-00.txt Praveen Muley, Susan Hares, Keyur Patel Presenter: Sue Problem: There is a whole bunch of ORF types, may not have efficient policy together. Multiple policies but no grouping. Solution: Apply in order by putting a Group_id wrapper Process: Add group apply in grouping order Uses: VPN policies Global routing Questions/Comments: Enke Chen: Using this approach you can apply one policy before some other. Sue: This is to group them - ORF type or entry based Enke: Now tied to type and group as structure vs type and entry Enke: What does this accomplish? This is a=20 location implementation problem. Currently you=20 decide what order to send them in. Sue: Different ordering than base spec defines. Enke: Type based or entry based? If you have=20 prefix and AS_PATH list, can you group them=20 together? Sue Hares: Yes. Enke Chen: What is grouping granularity? Sue Hares: Any is possible. Enke: I'm still confused about what it=20 accomplishes. Local implementation will do=20 ordering anyway. I don't know what else it does.=20 Is there anything? Sue: Gives a different ordering. Enke: I need to read it and then we can discuss further. Pedro Marques: What difference does it make which=20 I apply first? The only action is to accept=20 therefore, what does the ordering matter? A&&B=20 =3D=3D B&&A. Sue: Efficiency of statement of process, some=20 ORFs have permit/deny which gets you to an AND Pedro: I don't think so. Chandra Appanna: Who are you trying to define=20 'efficiency' for? Sender or receiver? How do you=20 guarantee what is efficient for receiver? Sue: The one doing the filtering Chandra: How can the guy advertising it, know=20 what's efficient for the guy on the other end? Sue: Getting back to Pedro's example, with permit and deny ordering matters. Pedro: No. Chandra: Why scramble the order? Enke: If we're talking about efficiency, this is=20 an implementation detail -- each implementation=20 may want to optimize itself differently. Not=20 sure this needs to be standardized. Sue: Thanks for your feedback. Praveen (co-author): order matters per VPN: ext comm/AS w/in VPN. Pedro: Please send a detailed example to the mailing list. Praveen: OK Jeff Haas: The ORFs we have today are very coarse=20 (AND) ... instead add sequencing and AND them=20 together John Scudder: If you are trying to build=20 route-map semantics the draft doesn't express it=20 clearly. Missed OR'ing, AND'ing instead focused=20 on 'efficiency' Sue: We can update it. Chandra Appanna: If all policy is ANDed there's no issue. Pedro: With your encoding, the ordering w/in a=20 group is now independent but, between groups you=20 are still left w/ the AND'ing problem. Sue: Sequence DOES matter. (Out of time, move to mailing list) ---- Carrying ATM reachability information in BGP (15 mins) draft-ck-bgp-atm-nlri-00.txt Chaitanya Kodeboyina, Chris Metz, Peter Busschbach Presenter: CK Want to make MPLS network transparent to STM routing/signalling. - PNNI tunneling through MPLS doesn't scale - Instead do something almost exactly like 2547 but for PNNI - Why BGP? Same reasons as for 2547 -- Solves=20 adjacency problem, fits existing carrier=20 infrastructure, can use RR, solves interdomain=20 problem. - "We use BGP to carry everything else so why not=20 ATM reachability information?" Solution: BGP carries ATM info, passes to ATM route=20 selector(ATM topo db) and signaled to/from PNNI Define new AF/SAF Use Route Distinguishers between ATM switches in different domains New extcomm values: ATM admin weight (~=3D PNNI metric) Use RT to manage independent ATM networks over single core Note, also presented to L2VPN WG Questions/Comments: Yakov: whole proposal is really L2VPN, only=20 peripherally IDR WG. Should wait to see if L2VPN=20 accepts, then if accepted look at it in IDR MDT SAFI and Connector Attribute (10 mins) draft-nalawade-idr-mdt-safi-01.txt Gargi Nalawade, Arjun Sreekantiah Presenter: Gargi Two proposals -- MDT SAFI, Connector attribute.=20 Could be split to two documents as needed. Problem: Multicast VPNs is incongruent w/ unicast topology What is a Multicast Domain? set of PE routers connected by a mcast tunnel MD per mcast-enabled VPN a default MDT (multicast distribution tree) connects all PEs Autodiscovery: MDT setup by PIM-SM, Bidir PIM or PIM SSM =46or SSM each PE needs to know the src addr of=20 each of the other PEs in the same MD Therefore need autodisc of src addr of each of PEs in the same MD Therefore use new MDT SAFI RD - assigned to one mcast domain IPaddr - dest addr (PE) MDT - addr of given MD RTs in the ext comm attr and/or the RD used to associate w/ the correct VRF Why connector attr? If use NHself then originating PE is overridden Need original original NH of VPNv4 update to find which tunnel to use Called Connector because it connects a VPNv4=20 prefix's update w/ the MDT safi. (Suggestions=20 for better name solicited.) Indicates the correlation and depnd between the 2=20 safi's and/or carries NGH value by an originating=20 BGP speaker More discussion @ L3VPN WG Questions/Comments: Yakov: Part of a larger work that is in L3VPN WG=20 (mcast 2547) but, BGP specific part depends on=20 whole solution by L3VPN WG. Therefore, don't=20 spend time talking about this work but, the L3VPN=20 WG. (Didn't get name, from Cisco): If other WG=20 accepts pkg, does that mean IDR is supposed to=20 accept it? Yakov: no, it means if other WG doesn't accept=20 it, there's no point in us even spending time Alex: I agree with Yakov unless you (IDR) see a showstopper in this proposal Yakov: well it's not broken so don't worry about that Yakov: please hold other questions until after Rahul's talk ---- Preserving BGP Next-Hops (10 mins) draft-raggarwa-bgp-nexthop-rewrite-00.txt Rahul Aggarwal, Chaitanya Kodeboyina Presenter: Rahul Applications: - MVPN 2547 inter-AS option B - Others possible BGP NH of unicast routes are rewritten in option B... PIM RPF fails Address of multicast source must be preserved Solution: Preserve original Next Hop Carried as optional/transitive attribute Address family inferred from length of attribute Compared to "Connector": - Connector doesn't have well-defined semantics (inferred from AFI/SAFI) - This attribute has specific semantics Questions/Comments (for previous two presentations): Gargi: disagree w/ statement that connector=20 semantics are not well-defined. it is just a=20 matter of listing out other uses. Also, not just=20 bit-bucket but, types define what is to be carried Pedro Marques: MDT safi - on one slide the RD can identify the=20 VRF, or the RT can identify the VRF: can have=20 more than one RD per VPN. The RT model is always=20 used to leak between VPN. Please stick to using=20 just RT. Gargi: OK. Yakov: Then RT model will be consistent for unicast Gargi: We can talk. John Scudder: To Rahul ... were you serious about inferring the=20 AF/SAF from length of attr? ... there may be=20 other AF in the future (ATM, IPV9) in which you=20 cannot infer Rahul: Not solving hypothetical problems..... Yakov: What happens when something has the wrong=20 length. The semantics of the value are directly=20 stated as type V6 and length is 128 bits Eric Rosen: I don't see that semantics is=20 undefined here. The two proposals appear to be=20 just about the same. Any claims for lack of=20 definition are by further type setting. The BGP=20 NH or connector attr must be able to specify. The=20 issue is only if you think that you don't need=20 MDT attr. Rahul: difference comes down to non-congruent=20 topologies, we should discuss that in L3VPN WG Eric: The incongruent topology is to have MDT=20 and BGP NH/connector attr. Otherwise, these=20 drafts are extremely close. Someone from Cisco: There are implementations out=20 there that don't use BGP NH for VPN addresses.=20 Therefore, we have to specify this. Eric Rosen: if we work out non-congruent stuff in=20 L3VPN, shoudn't these converge? Rahul: quite likely Yakov: who control the type space for MDT/connector? Gargi: IANA or IDR Yakov: IDR doesn't control type space Everyone: IANA Someone from Alcatel: Don't need RD ... only need=20 group mcast addr as global unicast addr must be=20 local IP addr. Gargi: Think of it like an VPN NRLI (MDT in this=20 case like a label) .... kept RD to understand one=20 NLRI from the other. Allows addr overlap. Yakov: is the combination of ip addr (loopback) and group addr globally uniq= ue? Gargi: not necessarily, could be shared by number=20 of PEs. Why RD is there? Look at L3VPN proposal:=20 join to the group from another signaling manner Yakov: When won't it? Gargi: (Something about two PE's having the same loopback address) Yakov: In that case unicast wouldn't work. Gargi: OK then the PE addrs must be unique. Yakov: Well then is the combination unique? Gargi: Yes. Yakov: Well that was the other guy's point. Enke Chen: here is another application -=20 eliminating route oscillation: make it TLV based=20 so can include multiple original nexthops and=20 also carry AF/SAF. I agree with John about=20 AF/SAF. Enke: Also you can carry ASN with nexthop, carry multiple. Rahul: Very interesting. CK: draft actually says that orig_NH has same=20 type as the normal NH type, it's not implied by=20 length at all Pedro (to Enke): Just because the encoding is=20 convenient doesn't mean it's OK -- still have=20 same amount of scaling issues from carrying extra=20 data. Enke: I don't care about encoding efficiency,=20 it's to let MED be derived from orig NH while=20 still allowing RR to rewrite NH. Rahul: I have another application for it but I haven't thought it out well y= et. Someone from Juniper: Type of original NH is not=20 from length but, apply the rule that is used to=20 derive from the NRLI that is passed Eric Rosen: There is no rule that NH passed is=20 same AF/SAF as NRLI. Therefore, cannot rely on=20 the packet type to derive the NH. CK: deriving AFI and SAFI of nexthop is hard, but=20 that's independent of this draft. Yakov : we are in the weeds of details that should be in L3VPN WG Someone from Cisco: Question to chairs, isn't one=20 draft a subset of the other? can the chairs=20 suggest a way to resolve this? Yakov: we aren't going to progress any of them=20 until we have guidance from L3VPN. Rahul: I don't agree the one is a subset of the other. Sue: We're not doing anything until L3VPN does something. Bill Fenner: specific problem or generalizing to=20 something bigger? It's a continuum. Sue: Thank you. ---- Wrap up: Sue: We are requested to review MPLS BGP GR and=20 private LAN service doc. I need reviewers to=20 volunteer. You need to read doc, see if it fits=20 with existing IDR practice/implementation. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 24 15:08: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 PAA03666; Tue, 24 Aug 2004 15:08:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzgf7-0007Bn-Oa; Tue, 24 Aug 2004 15:08:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzgDd-0000zO-5u; Tue, 24 Aug 2004 14:40:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzg2D-0006e9-9F for idr@megatron.ietf.org; Tue, 24 Aug 2004 14:28:42 -0400 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 OAA00770 for ; Tue, 24 Aug 2004 14:28:34 -0400 (EDT) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzg2f-0006Rs-PW for idr@ietf.org; Tue, 24 Aug 2004 14:29:11 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i7OIS2Bm007717; Tue, 24 Aug 2004 11:28:02 -0700 (PDT) (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 i7OIS1e73074; Tue, 24 Aug 2004 11:28:01 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200408241828.i7OIS1e73074@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <73472.1093372081.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Aug 2004 11:28:01 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 419681661a5a61835a9a79996a04e3e9 Content-Transfer-Encoding: quoted-printable Cc: skh@nexthop.com Subject: [Idr] Draft minutes 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: a3962d9f28f80f517c050a4675f65235 Content-Transfer-Encoding: quoted-printable Folks, Please review the minutes (see attached) for correctness. The deadline = for review is August 31, 2004. Yakov. ------- Forwarded Message Date: Tue, 24 Aug 2004 12:51:05 -0400 From: "John G. Scudder" To: idr@ietf.org Subject: [Idr] Draft minutes for August 2 meeting Inter-Domain Routing WG (idr) Monday, August 2 at 1300-1500 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D CHAIRS: Susan Hares Yakov Rekhter SCRIBES: Ignas Bagdonas John Scudder David Ward See proceedings = (http://www.ietf.org/proceedings/04aug/index.html) = for presentation slides. - ---- Document Status Update (5 mins) S. Hares, Y. Rekhter Presenter: Yakov Four new work items accepted since last IETF, good consensus. Other items proposed, not sufficient consensus, not accepted as WG items. IESG review of BGP base spec package is done, = comments incorporated (BGP-4, MIB, etc). Will = issue further revisions as needed. Submitted 6 docs to IESG to advance since last IETF (GR, extcomm, etc) Confeds -- need to be updated with comments from = last call, need implementation report -- once = done, to IESG. No new progress until >=3D 2 impls: - - ORF - - 4-octet ASN - - AS path ORF - - MIB - - AS wide unique identifier Questions/Comments: Susan Harris: Just to clarify - which document was reclassified to histori= c? Yakov: RFC 1863. - ---- Dynamic Capability for BGP-4 (10 mins) draft-ietf-idr-dynamic-cap-05.txt Enke Chen, Srihari R. Sangli Presenter: Enke Additions to support capabilities which affect Update encoding: - - Ack request - - Ack - - Sequence number What capabilities need ack? - - 4-byte AS - - Multipath - - Address Family (probably) Ack is optional so need not be used for capabilities that don't require it= . Unfortunately ack is not backward compatible. = Want to reuse current code point (fine if = little/no deployment w/ prev spec version) or get = new code point? Questions/Comments: Yakov: Get a new code point, we have hundreds of 'em, no need to economize= . Martin Djernaes: Why not increase capability = number space to 16 bits, also length to 16 bits? Chandra Appanna: Agreed, increase sizes. Chandra: What impact on the state machine? Enke: Little or none, session is already established. Chandra: Really? What about when you send a = capability which changes something you negotiated = at OPEN time? Tony Li: Reserve one value "for future extensions" Enke: Does anyone really need more length than 255? Many: Yes. (Out of time, move to mailing list) - ---- Advertisement of the Group Best Paths in BGP (15 mins) draft-chen-bgp-group-path-update-01.txt E. Chen, N. Chen Presenter: Enke Why? Persistent oscillation issues -- RR or confederation. Observations: - - Full mesh is free of oscillations - - Route selection groups paths based on neighbor AS. Two approaches: - - Advertise group-best (i.e. best path from each = neighbor AS) -- eliminates MED oscillation, still = vulnerable to topology-based issues, still = reduces info vs. full mesh. Paths adv'd =3D=3D = number of neighbor ASes. Topology issues means = that IGP constraints still apply -- intra-cluster = links must have smaller metrics than = inter-cluster links. - - Advertise group multi-path -- adv all paths = that survive MED comparison -- effectively makes = RR advertisements independent of IGP metrics. = However, virtually as much state as full mesh. = Suggestions: accept MED, reduces number of routes = that survive MED step =3D=3D> fewer routes advertised. Encoding: - - must be changed (pfx, neighbor_as) for = group-best, (pfx, originator_id) for = group-multipath - - no encoding change for reachable routes = (because neighbor_as, orig_id already in update) - - need new encoding for w/draw - - therefore need new capability to indicate = ability to parse new w/draw and all, also = advertises which mode to be used (best only, = group best, multi) Implementation/deployment: - - only RR/confed BR need to advertise multiple paths - - non-RR need only to Rx, not Tx -- Rx is easy recommendation: - - Use group-best, incremental deployment. = group-multi solves more problems but too many = paths Questions/Comments: Pedro Marques: We could use the route server doc = we just moved to historical for this instead of = using this encoding. One reason I would like to = use a new path attribute is because some non RR = might like to do this, in which case originator = ID won't work. Since there's no backward = compatibility anyway, why try to reuse existing = semantics? Enke: I think Orig_ID is a good fit. Yakov: Neighbor AS hack won't work with AS set. Enke: When advertising, you must create AS = sequence, this is in base specification. John Scudder: I agree w/ Pedro. If defining a = capability, then use a new encoding. Most = important contribution of this draft is not = encoding, what is most important is ruleset of = what to advert and when. Enke: Yakov: There is little value to send the same information in the same mess= age twice. Pedro: What about non-RR? You have to have the = exit point (external box) to be able to do this. = The originator_id only works for RR server. John: If define a way to solve multi-path in BGP, = please solve the general case and not just the = oscillation case. Enke: There are a lot of issues if we generalize and I don't know any exam= ples. (Out of time, move to mailing list) - ---- Graceful Shutdown of BGP Sessions (15 mins) draft-dubois-bgp-planned-maintenance-00.txt N. Dubois, B. Decraene, B. Fondeviole Presenter: Nicolas Why? - - Want no packet loss during maintenance=A0 - - Current is break paths and then inform peers - - Want make-before-break NOTE: not always useful for single IBGP session Observed behavior: - - in small network test, router shutdown goes from 20s traffic loss to 0= s - - w/ 100k routes 20ms loss vs 4 sec loss - - timer should be between 30 and 60s draft was too conservative w/ 300s Questions/Comments: Tony Li: What happens if the router undergoing = maintenance simply withdraws in an orderly fashion Nicolas: Yes, that is exactly what the draft proposes John Scudder: No changes to BGP? Can you do this with a route map? Nicolas: No changes to BGP state machine. Can = be done w/ route-map -- did that for testing. = But, too hard for ops people. - ---- Group Cooperative Route Filtering Capability for BGP-4 (10 mins) draft-muley-hares-idr-orf-order-00.txt Praveen Muley, Susan Hares, Keyur Patel Presenter: Sue Problem: There is a whole bunch of ORF types, may not have efficient policy togethe= r. Multiple policies but no grouping. Solution: Apply in order by putting a Group_id wrapper Process: Add group apply in grouping order Uses: VPN policies Global routing Questions/Comments: Enke Chen: Using this approach you can apply one policy before some other. Sue: This is to group them - ORF type or entry based Enke: Now tied to type and group as structure vs type and entry Enke: What does this accomplish? This is a = location implementation problem. Currently you = decide what order to send them in. Sue: Different ordering than base spec defines. Enke: Type based or entry based? If you have = prefix and AS_PATH list, can you group them = together? Sue Hares: Yes. Enke Chen: What is grouping granularity? Sue Hares: Any is possible. Enke: I'm still confused about what it = accomplishes. Local implementation will do = ordering anyway. I don't know what else it does. = Is there anything? Sue: Gives a different ordering. Enke: I need to read it and then we can discuss further. Pedro Marques: What difference does it make which = I apply first? The only action is to accept = therefore, what does the ordering matter? A&&B = =3D=3D B&&A. Sue: Efficiency of statement of process, some = ORFs have permit/deny which gets you to an AND Pedro: I don't think so. Chandra Appanna: Who are you trying to define = 'efficiency' for? Sender or receiver? How do you = guarantee what is efficient for receiver? Sue: The one doing the filtering Chandra: How can the guy advertising it, know = what's efficient for the guy on the other end? Sue: Getting back to Pedro's example, with permit and deny ordering matter= s. Pedro: No. Chandra: Why scramble the order? Enke: If we're talking about efficiency, this is = an implementation detail -- each implementation = may want to optimize itself differently. Not = sure this needs to be standardized. Sue: Thanks for your feedback. Praveen (co-author): order matters per VPN: ext comm/AS w/in VPN. Pedro: Please send a detailed example to the mailing list. Praveen: OK Jeff Haas: The ORFs we have today are very coarse = (AND) ... instead add sequencing and AND them = together John Scudder: If you are trying to build = route-map semantics the draft doesn't express it = clearly. Missed OR'ing, AND'ing instead focused = on 'efficiency' Sue: We can update it. Chandra Appanna: If all policy is ANDed there's no issue. Pedro: With your encoding, the ordering w/in a = group is now independent but, between groups you = are still left w/ the AND'ing problem. Sue: Sequence DOES matter. (Out of time, move to mailing list) - ---- Carrying ATM reachability information in BGP (15 mins) draft-ck-bgp-atm-nlri-00.txt Chaitanya Kodeboyina, Chris Metz, Peter Busschbach Presenter: CK Want to make MPLS network transparent to STM routing/signalling. - - PNNI tunneling through MPLS doesn't scale - - Instead do something almost exactly like 2547 but for PNNI - - Why BGP? Same reasons as for 2547 -- Solves = adjacency problem, fits existing carrier = infrastructure, can use RR, solves interdomain = problem. - - "We use BGP to carry everything else so why not = ATM reachability information?" Solution: BGP carries ATM info, passes to ATM route = selector(ATM topo db) and signaled to/from PNNI Define new AF/SAF Use Route Distinguishers between ATM switches in different domains New extcomm values: ATM admin weight (~=3D PNNI metric) Use RT to manage independent ATM networks over single core Note, also presented to L2VPN WG Questions/Comments: Yakov: whole proposal is really L2VPN, only = peripherally IDR WG. Should wait to see if L2VPN = accepts, then if accepted look at it in IDR MDT SAFI and Connector Attribute (10 mins) draft-nalawade-idr-mdt-safi-01.txt Gargi Nalawade, Arjun Sreekantiah Presenter: Gargi Two proposals -- MDT SAFI, Connector attribute. = Could be split to two documents as needed. Problem: Multicast VPNs is incongruent w/ unicast topology What is a Multicast Domain? set of PE routers connected by a mcast tunnel MD per mcast-enabled VPN a default MDT (multicast distribution tree) connects all PEs Autodiscovery: MDT setup by PIM-SM, Bidir PIM or PIM SSM For SSM each PE needs to know the src addr of = each of the other PEs in the same MD Therefore need autodisc of src addr of each of PEs in the same MD Therefore use new MDT SAFI RD - assigned to one mcast domain IPaddr - dest addr (PE) MDT - addr of given MD RTs in the ext comm attr and/or the RD used to associate w/ the correct VR= F Why connector attr? If use NHself then originating PE is overridden Need original original NH of VPNv4 update to find which tunnel to use Called Connector because it connects a VPNv4 = prefix's update w/ the MDT safi. (Suggestions = for better name solicited.) Indicates the correlation and depnd between the 2 = safi's and/or carries NGH value by an originating = BGP speaker More discussion @ L3VPN WG Questions/Comments: Yakov: Part of a larger work that is in L3VPN WG = (mcast 2547) but, BGP specific part depends on = whole solution by L3VPN WG. Therefore, don't = spend time talking about this work but, the L3VPN = WG. (Didn't get name, from Cisco): If other WG = accepts pkg, does that mean IDR is supposed to = accept it? Yakov: no, it means if other WG doesn't accept = it, there's no point in us even spending time Alex: I agree with Yakov unless you (IDR) see a showstopper in this propos= al Yakov: well it's not broken so don't worry about that Yakov: please hold other questions until after Rahul's talk - ---- Preserving BGP Next-Hops (10 mins) draft-raggarwa-bgp-nexthop-rewrite-00.txt Rahul Aggarwal, Chaitanya Kodeboyina Presenter: Rahul Applications: - - MVPN 2547 inter-AS option B - - Others possible BGP NH of unicast routes are rewritten in option B... PIM RPF fails Address of multicast source must be preserved Solution: Preserve original Next Hop Carried as optional/transitive attribute Address family inferred from length of attribute Compared to "Connector": - - Connector doesn't have well-defined semantics (inferred from AFI/SAFI) - - This attribute has specific semantics Questions/Comments (for previous two presentations): Gargi: disagree w/ statement that connector = semantics are not well-defined. it is just a = matter of listing out other uses. Also, not just = bit-bucket but, types define what is to be carried Pedro Marques: MDT safi - on one slide the RD can identify the = VRF, or the RT can identify the VRF: can have = more than one RD per VPN. The RT model is always = used to leak between VPN. Please stick to using = just RT. Gargi: OK. Yakov: Then RT model will be consistent for unicast Gargi: We can talk. John Scudder: To Rahul ... were you serious about inferring the = AF/SAF from length of attr? ... there may be = other AF in the future (ATM, IPV9) in which you = cannot infer Rahul: Not solving hypothetical problems..... Yakov: What happens when something has the wrong = length. The semantics of the value are directly = stated as type V6 and length is 128 bits Eric Rosen: I don't see that semantics is = undefined here. The two proposals appear to be = just about the same. Any claims for lack of = definition are by further type setting. The BGP = NH or connector attr must be able to specify. The = issue is only if you think that you don't need = MDT attr. Rahul: difference comes down to non-congruent = topologies, we should discuss that in L3VPN WG Eric: The incongruent topology is to have MDT = and BGP NH/connector attr. Otherwise, these = drafts are extremely close. Someone from Cisco: There are implementations out = there that don't use BGP NH for VPN addresses. = Therefore, we have to specify this. Eric Rosen: if we work out non-congruent stuff in = L3VPN, shoudn't these converge? Rahul: quite likely Yakov: who control the type space for MDT/connector? Gargi: IANA or IDR Yakov: IDR doesn't control type space Everyone: IANA Someone from Alcatel: Don't need RD ... only need = group mcast addr as global unicast addr must be = local IP addr. Gargi: Think of it like an VPN NRLI (MDT in this = case like a label) .... kept RD to understand one = NLRI from the other. Allows addr overlap. Yakov: is the combination of ip addr (loopback) and group addr globally un= ique? Gargi: not necessarily, could be shared by number = of PEs. Why RD is there? Look at L3VPN proposal: = join to the group from another signaling manner Yakov: When won't it? Gargi: (Something about two PE's having the same loopback address) Yakov: In that case unicast wouldn't work. Gargi: OK then the PE addrs must be unique. Yakov: Well then is the combination unique? Gargi: Yes. Yakov: Well that was the other guy's point. Enke Chen: here is another application - = eliminating route oscillation: make it TLV based = so can include multiple original nexthops and = also carry AF/SAF. I agree with John about = AF/SAF. Enke: Also you can carry ASN with nexthop, carry multiple. Rahul: Very interesting. CK: draft actually says that orig_NH has same = type as the normal NH type, it's not implied by = length at all Pedro (to Enke): Just because the encoding is = convenient doesn't mean it's OK -- still have = same amount of scaling issues from carrying extra = data. Enke: I don't care about encoding efficiency, = it's to let MED be derived from orig NH while = still allowing RR to rewrite NH. Rahul: I have another application for it but I haven't thought it out well= yet. Someone from Juniper: Type of original NH is not = from length but, apply the rule that is used to = derive from the NRLI that is passed Eric Rosen: There is no rule that NH passed is = same AF/SAF as NRLI. Therefore, cannot rely on = the packet type to derive the NH. CK: deriving AFI and SAFI of nexthop is hard, but = that's independent of this draft. Yakov : we are in the weeds of details that should be in L3VPN WG Someone from Cisco: Question to chairs, isn't one = draft a subset of the other? can the chairs = suggest a way to resolve this? Yakov: we aren't going to progress any of them = until we have guidance from L3VPN. Rahul: I don't agree the one is a subset of the other. Sue: We're not doing anything until L3VPN does something. Bill Fenner: specific problem or generalizing to = something bigger? It's a continuum. Sue: Thank you. - ---- Wrap up: Sue: We are requested to review MPLS BGP GR and = private LAN service doc. I need reviewers to = volunteer. You need to read doc, see if it fits = with existing IDR practice/implementation. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 30 16:31:28 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 QAA26765; Mon, 30 Aug 2004 16:31:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1sqD-00061i-7T; Mon, 30 Aug 2004 16:33:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1sH6-0000l1-99; Mon, 30 Aug 2004 15:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1sCU-0006g7-33; Mon, 30 Aug 2004 15:52:22 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21493; Mon, 30 Aug 2004 15:52:20 -0400 (EDT) Message-Id: <200408301952.PAA21493@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, 30 Aug 2004 15:52:19 -0400 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-prefix-orf-00.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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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 : Address Prefix Based Outbound Route Filter for BGP-4 Author(s) : E. Chen, S. Sangli Filename : draft-ietf-idr-bgp-prefix-orf-00.txt Pages : 5 Date : 2004-8-30 This document defines a new Outbound Router Filter type for BGP, termed "Address Prefix Outbound Route Filter", that can be used to perform address prefix based route filtering. This ORF-type supports prefix length or range based matching, wild-card based address prefix matching, as well as the exact address prefix matching for address families. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-prefix-orf-00.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-prefix-orf-00.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-prefix-orf-00.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-8-30153556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-prefix-orf-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-prefix-orf-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-30153556.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 Aug 30 16:37:46 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 QAA27769; Mon, 30 Aug 2004 16:37:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1swI-0006Kq-NZ; Mon, 30 Aug 2004 16:39:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1sH9-0000m4-1i; Mon, 30 Aug 2004 15:57:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1sCc-0006m9-7J; Mon, 30 Aug 2004 15:52:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21506; Mon, 30 Aug 2004 15:52:28 -0400 (EDT) Message-Id: <200408301952.PAA21506@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, 30 Aug 2004 15:52:28 -0400 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-analysis-06.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: e1b0e72ff1bbd457ceef31828f216a86 --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-06.txt Pages : 20 Date : 2004-8-30 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 RFC 1264 [RFC1264]. In order to fulfill the requirement, this report augments RFC 1774 [RFC1774] and summarizes the key features of BGP 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-06.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-06.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-06.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-8-30153603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-analysis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-analysis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-30153603.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 Aug 31 11:25: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 LAA25197; Tue, 31 Aug 2004 11:25:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2AXp-0005q4-FQ; Tue, 31 Aug 2004 11:27:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2AUF-0003Tp-95; Tue, 31 Aug 2004 11:23:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ATF-00039o-FD for idr@megatron.ietf.org; Tue, 31 Aug 2004 11:22:53 -0400 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 LAA24848 for ; Tue, 31 Aug 2004 11:22:51 -0400 (EDT) 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 1C2AVE-0005lJ-Dk for idr@ietf.org; Tue, 31 Aug 2004 11:24:57 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 0562C2D488E for ; Tue, 31 Aug 2004 11:22:18 -0400 (EDT) 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 12963-01-29 for ; Tue, 31 Aug 2004 11:22:17 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id BC1BC2D4848 for ; Tue, 31 Aug 2004 11:22:17 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i7VFMCY26708 for idr@ietf.org; Tue, 31 Aug 2004 11:22:12 -0400 (EDT) Date: Tue, 31 Aug 2004 11:22:12 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20040831152212.GA26694@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Idr] draft-ietf-idr-bgp4-mib-15.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.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 IDR WG, draft-ietf-idr-bgp4-mib-15.txt has just been submitted to Internet-Drafts. This addresses all IESG last call comments. Notable changes include: o Small changes in the abstract text o Add REFERENCEs to most objects pointing to the places in the upcoming BGP-4 RFC where the object came from. o Add UNITS clauses o Corrected text with regards to the status of Atomic Aggregate o Correct status of bgp 7 (trap) objects o Add a NULL IANA considerations section -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 31 16:03:10 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 QAA23948; Tue, 31 Aug 2004 16:03:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2EsY-0005rn-TR; Tue, 31 Aug 2004 16:05:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ESb-0001f6-2K; Tue, 31 Aug 2004 15:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ELk-0006hB-QX; Tue, 31 Aug 2004 15:31:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20068; Tue, 31 Aug 2004 15:31:23 -0400 (EDT) Message-Id: <200408311931.PAA20068@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, 31 Aug 2004 15:31:23 -0400 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-mib-15.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: 8de5f93cb2b4e3bee75302e9eacc33db --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 : Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4) Author(s) : J. Haas, S. Hares Filename : draft-ietf-idr-bgp4-mib-15.txt Pages : 37 Date : 2004-8-31 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-15.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-bgp4-mib-15.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-bgp4-mib-15.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-8-31154104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-mib-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-mib-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-31154104.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 QAA10449 for ; Tue, 31 Aug 2004 16:03:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ESa-0001f6-Vv; Tue, 31 Aug 2004 15:38:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ELk-0006hB-QX; Tue, 31 Aug 2004 15:31:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20068; Tue, 31 Aug 2004 15:31:23 -0400 (EDT) Message-Id: <200408311931.PAA20068@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, 31 Aug 2004 15:31:23 -0400 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-mib-15.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 : Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4) Author(s) : J. Haas, S. Hares Filename : draft-ietf-idr-bgp4-mib-15.txt Pages : 37 Date : 2004-8-31 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-15.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-bgp4-mib-15.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-bgp4-mib-15.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-8-31154104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-mib-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-mib-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-31154104.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 LAA08320 for ; Tue, 31 Aug 2004 11:25:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2AUF-0003Tp-6f; Tue, 31 Aug 2004 11:23:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ATF-00039o-FD for idr@megatron.ietf.org; Tue, 31 Aug 2004 11:22:53 -0400 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 LAA24848 for ; Tue, 31 Aug 2004 11:22:51 -0400 (EDT) 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 1C2AVE-0005lJ-Dk for idr@ietf.org; Tue, 31 Aug 2004 11:24:57 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 0562C2D488E for ; Tue, 31 Aug 2004 11:22:18 -0400 (EDT) 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 12963-01-29 for ; Tue, 31 Aug 2004 11:22:17 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id BC1BC2D4848 for ; Tue, 31 Aug 2004 11:22:17 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i7VFMCY26708 for idr@ietf.org; Tue, 31 Aug 2004 11:22:12 -0400 (EDT) Date: Tue, 31 Aug 2004 11:22:12 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20040831152212.GA26694@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Idr] draft-ietf-idr-bgp4-mib-15.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 IDR WG, draft-ietf-idr-bgp4-mib-15.txt has just been submitted to Internet-Drafts. This addresses all IESG last call comments. Notable changes include: o Small changes in the abstract text o Add REFERENCEs to most objects pointing to the places in the upcoming BGP-4 RFC where the object came from. o Add UNITS clauses o Corrected text with regards to the status of Atomic Aggregate o Correct status of bgp 7 (trap) objects o Add a NULL IANA considerations section -- Jeff Haas NextHop Technologies _______________________________________________ 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 QAA29086 for ; Mon, 30 Aug 2004 16:36:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1sH8-0000m4-Ve; Mon, 30 Aug 2004 15:57:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1sCc-0006m9-7J; Mon, 30 Aug 2004 15:52:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21506; Mon, 30 Aug 2004 15:52:28 -0400 (EDT) Message-Id: <200408301952.PAA21506@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, 30 Aug 2004 15:52:28 -0400 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-analysis-06.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-06.txt Pages : 20 Date : 2004-8-30 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 RFC 1264 [RFC1264]. In order to fulfill the requirement, this report augments RFC 1774 [RFC1774] and summarizes the key features of BGP 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-06.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-06.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-06.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-8-30153603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-analysis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-analysis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-30153603.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 QAA29063 for ; Mon, 30 Aug 2004 16:31:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1sH6-0000l1-6x; Mon, 30 Aug 2004 15:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1sCU-0006g7-33; Mon, 30 Aug 2004 15:52:22 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21493; Mon, 30 Aug 2004 15:52:20 -0400 (EDT) Message-Id: <200408301952.PAA21493@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, 30 Aug 2004 15:52:19 -0400 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-prefix-orf-00.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 : Address Prefix Based Outbound Route Filter for BGP-4 Author(s) : E. Chen, S. Sangli Filename : draft-ietf-idr-bgp-prefix-orf-00.txt Pages : 5 Date : 2004-8-30 This document defines a new Outbound Router Filter type for BGP, termed "Address Prefix Outbound Route Filter", that can be used to perform address prefix based route filtering. This ORF-type supports prefix length or range based matching, wild-card based address prefix matching, as well as the exact address prefix matching for address families. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-prefix-orf-00.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-prefix-orf-00.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-prefix-orf-00.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-8-30153556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-prefix-orf-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-prefix-orf-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-30153556.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 PAA19766 for ; Tue, 24 Aug 2004 15:05:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzgDc-0000zO-6H; Tue, 24 Aug 2004 14:40:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzg2D-0006e9-9F for idr@megatron.ietf.org; Tue, 24 Aug 2004 14:28:42 -0400 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 OAA00770 for ; Tue, 24 Aug 2004 14:28:34 -0400 (EDT) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bzg2f-0006Rs-PW for idr@ietf.org; Tue, 24 Aug 2004 14:29:11 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i7OIS2Bm007717; Tue, 24 Aug 2004 11:28:02 -0700 (PDT) (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 i7OIS1e73074; Tue, 24 Aug 2004 11:28:01 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200408241828.i7OIS1e73074@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <73472.1093372081.1@juniper.net> Date: Tue, 24 Aug 2004 11:28:01 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 419681661a5a61835a9a79996a04e3e9 Cc: skh@nexthop.com Subject: [Idr] Draft minutes 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 PAA19766 Folks, Please review the minutes (see attached) for correctness. The deadline for review is August 31, 2004. Yakov. ------- Forwarded Message Date: Tue, 24 Aug 2004 12:51:05 -0400 From: "John G. Scudder" To: idr@ietf.org Subject: [Idr] Draft minutes for August 2 meeting Inter-Domain Routing WG (idr) Monday, August 2 at 1300-1500 ============================= CHAIRS: Susan Hares Yakov Rekhter SCRIBES: Ignas Bagdonas John Scudder David Ward See proceedings (http://www.ietf.org/proceedings/04aug/index.html) for presentation slides. - ---- Document Status Update (5 mins) S. Hares, Y. Rekhter Presenter: Yakov Four new work items accepted since last IETF, good consensus. Other items proposed, not sufficient consensus, not accepted as WG items. IESG review of BGP base spec package is done, comments incorporated (BGP-4, MIB, etc). Will issue further revisions as needed. Submitted 6 docs to IESG to advance since last IETF (GR, extcomm, etc) Confeds -- need to be updated with comments from last call, need implementation report -- once done, to IESG. No new progress until >= 2 impls: - - ORF - - 4-octet ASN - - AS path ORF - - MIB - - AS wide unique identifier Questions/Comments: Susan Harris: Just to clarify - which document was reclassified to historic? Yakov: RFC 1863. - ---- Dynamic Capability for BGP-4 (10 mins) draft-ietf-idr-dynamic-cap-05.txt Enke Chen, Srihari R. Sangli Presenter: Enke Additions to support capabilities which affect Update encoding: - - Ack request - - Ack - - Sequence number What capabilities need ack? - - 4-byte AS - - Multipath - - Address Family (probably) Ack is optional so need not be used for capabilities that don't require it. Unfortunately ack is not backward compatible. Want to reuse current code point (fine if little/no deployment w/ prev spec version) or get new code point? Questions/Comments: Yakov: Get a new code point, we have hundreds of 'em, no need to economize. Martin Djernaes: Why not increase capability number space to 16 bits, also length to 16 bits? Chandra Appanna: Agreed, increase sizes. Chandra: What impact on the state machine? Enke: Little or none, session is already established. Chandra: Really? What about when you send a capability which changes something you negotiated at OPEN time? Tony Li: Reserve one value "for future extensions" Enke: Does anyone really need more length than 255? Many: Yes. (Out of time, move to mailing list) - ---- Advertisement of the Group Best Paths in BGP (15 mins) draft-chen-bgp-group-path-update-01.txt E. Chen, N. Chen Presenter: Enke Why? Persistent oscillation issues -- RR or confederation. Observations: - - Full mesh is free of oscillations - - Route selection groups paths based on neighbor AS. Two approaches: - - Advertise group-best (i.e. best path from each neighbor AS) -- eliminates MED oscillation, still vulnerable to topology-based issues, still reduces info vs. full mesh. Paths adv'd == number of neighbor ASes. Topology issues means that IGP constraints still apply -- intra-cluster links must have smaller metrics than inter-cluster links. - - Advertise group multi-path -- adv all paths that survive MED comparison -- effectively makes RR advertisements independent of IGP metrics. However, virtually as much state as full mesh. Suggestions: accept MED, reduces number of routes that survive MED step ==> fewer routes advertised. Encoding: - - must be changed (pfx, neighbor_as) for group-best, (pfx, originator_id) for group-multipath - - no encoding change for reachable routes (because neighbor_as, orig_id already in update) - - need new encoding for w/draw - - therefore need new capability to indicate ability to parse new w/draw and all, also advertises which mode to be used (best only, group best, multi) Implementation/deployment: - - only RR/confed BR need to advertise multiple paths - - non-RR need only to Rx, not Tx -- Rx is easy recommendation: - - Use group-best, incremental deployment. group-multi solves more problems but too many paths Questions/Comments: Pedro Marques: We could use the route server doc we just moved to historical for this instead of using this encoding. One reason I would like to use a new path attribute is because some non RR might like to do this, in which case originator ID won't work. Since there's no backward compatibility anyway, why try to reuse existing semantics? Enke: I think Orig_ID is a good fit. Yakov: Neighbor AS hack won't work with AS set. Enke: When advertising, you must create AS sequence, this is in base specification. John Scudder: I agree w/ Pedro. If defining a capability, then use a new encoding. Most important contribution of this draft is not encoding, what is most important is ruleset of what to advert and when. Enke: Yakov: There is little value to send the same information in the same message twice. Pedro: What about non-RR? You have to have the exit point (external box) to be able to do this. The originator_id only works for RR server. John: If define a way to solve multi-path in BGP, please solve the general case and not just the oscillation case. Enke: There are a lot of issues if we generalize and I don't know any examples. (Out of time, move to mailing list) - ---- Graceful Shutdown of BGP Sessions (15 mins) draft-dubois-bgp-planned-maintenance-00.txt N. Dubois, B. Decraene, B. Fondeviole Presenter: Nicolas Why? - - Want no packet loss during maintenance  - - Current is break paths and then inform peers - - Want make-before-break NOTE: not always useful for single IBGP session Observed behavior: - - in small network test, router shutdown goes from 20s traffic loss to 0s - - w/ 100k routes 20ms loss vs 4 sec loss - - timer should be between 30 and 60s draft was too conservative w/ 300s Questions/Comments: Tony Li: What happens if the router undergoing maintenance simply withdraws in an orderly fashion Nicolas: Yes, that is exactly what the draft proposes John Scudder: No changes to BGP? Can you do this with a route map? Nicolas: No changes to BGP state machine. Can be done w/ route-map -- did that for testing. But, too hard for ops people. - ---- Group Cooperative Route Filtering Capability for BGP-4 (10 mins) draft-muley-hares-idr-orf-order-00.txt Praveen Muley, Susan Hares, Keyur Patel Presenter: Sue Problem: There is a whole bunch of ORF types, may not have efficient policy together. Multiple policies but no grouping. Solution: Apply in order by putting a Group_id wrapper Process: Add group apply in grouping order Uses: VPN policies Global routing Questions/Comments: Enke Chen: Using this approach you can apply one policy before some other. Sue: This is to group them - ORF type or entry based Enke: Now tied to type and group as structure vs type and entry Enke: What does this accomplish? This is a location implementation problem. Currently you decide what order to send them in. Sue: Different ordering than base spec defines. Enke: Type based or entry based? If you have prefix and AS_PATH list, can you group them together? Sue Hares: Yes. Enke Chen: What is grouping granularity? Sue Hares: Any is possible. Enke: I'm still confused about what it accomplishes. Local implementation will do ordering anyway. I don't know what else it does. Is there anything? Sue: Gives a different ordering. Enke: I need to read it and then we can discuss further. Pedro Marques: What difference does it make which I apply first? The only action is to accept therefore, what does the ordering matter? A&&B == B&&A. Sue: Efficiency of statement of process, some ORFs have permit/deny which gets you to an AND Pedro: I don't think so. Chandra Appanna: Who are you trying to define 'efficiency' for? Sender or receiver? How do you guarantee what is efficient for receiver? Sue: The one doing the filtering Chandra: How can the guy advertising it, know what's efficient for the guy on the other end? Sue: Getting back to Pedro's example, with permit and deny ordering matters. Pedro: No. Chandra: Why scramble the order? Enke: If we're talking about efficiency, this is an implementation detail -- each implementation may want to optimize itself differently. Not sure this needs to be standardized. Sue: Thanks for your feedback. Praveen (co-author): order matters per VPN: ext comm/AS w/in VPN. Pedro: Please send a detailed example to the mailing list. Praveen: OK Jeff Haas: The ORFs we have today are very coarse (AND) ... instead add sequencing and AND them together John Scudder: If you are trying to build route-map semantics the draft doesn't express it clearly. Missed OR'ing, AND'ing instead focused on 'efficiency' Sue: We can update it. Chandra Appanna: If all policy is ANDed there's no issue. Pedro: With your encoding, the ordering w/in a group is now independent but, between groups you are still left w/ the AND'ing problem. Sue: Sequence DOES matter. (Out of time, move to mailing list) - ---- Carrying ATM reachability information in BGP (15 mins) draft-ck-bgp-atm-nlri-00.txt Chaitanya Kodeboyina, Chris Metz, Peter Busschbach Presenter: CK Want to make MPLS network transparent to STM routing/signalling. - - PNNI tunneling through MPLS doesn't scale - - Instead do something almost exactly like 2547 but for PNNI - - Why BGP? Same reasons as for 2547 -- Solves adjacency problem, fits existing carrier infrastructure, can use RR, solves interdomain problem. - - "We use BGP to carry everything else so why not ATM reachability information?" Solution: BGP carries ATM info, passes to ATM route selector(ATM topo db) and signaled to/from PNNI Define new AF/SAF Use Route Distinguishers between ATM switches in different domains New extcomm values: ATM admin weight (~= PNNI metric) Use RT to manage independent ATM networks over single core Note, also presented to L2VPN WG Questions/Comments: Yakov: whole proposal is really L2VPN, only peripherally IDR WG. Should wait to see if L2VPN accepts, then if accepted look at it in IDR MDT SAFI and Connector Attribute (10 mins) draft-nalawade-idr-mdt-safi-01.txt Gargi Nalawade, Arjun Sreekantiah Presenter: Gargi Two proposals -- MDT SAFI, Connector attribute. Could be split to two documents as needed. Problem: Multicast VPNs is incongruent w/ unicast topology What is a Multicast Domain? set of PE routers connected by a mcast tunnel MD per mcast-enabled VPN a default MDT (multicast distribution tree) connects all PEs Autodiscovery: MDT setup by PIM-SM, Bidir PIM or PIM SSM For SSM each PE needs to know the src addr of each of the other PEs in the same MD Therefore need autodisc of src addr of each of PEs in the same MD Therefore use new MDT SAFI RD - assigned to one mcast domain IPaddr - dest addr (PE) MDT - addr of given MD RTs in the ext comm attr and/or the RD used to associate w/ the correct VRF Why connector attr? If use NHself then originating PE is overridden Need original original NH of VPNv4 update to find which tunnel to use Called Connector because it connects a VPNv4 prefix's update w/ the MDT safi. (Suggestions for better name solicited.) Indicates the correlation and depnd between the 2 safi's and/or carries NGH value by an originating BGP speaker More discussion @ L3VPN WG Questions/Comments: Yakov: Part of a larger work that is in L3VPN WG (mcast 2547) but, BGP specific part depends on whole solution by L3VPN WG. Therefore, don't spend time talking about this work but, the L3VPN WG. (Didn't get name, from Cisco): If other WG accepts pkg, does that mean IDR is supposed to accept it? Yakov: no, it means if other WG doesn't accept it, there's no point in us even spending time Alex: I agree with Yakov unless you (IDR) see a showstopper in this proposal Yakov: well it's not broken so don't worry about that Yakov: please hold other questions until after Rahul's talk - ---- Preserving BGP Next-Hops (10 mins) draft-raggarwa-bgp-nexthop-rewrite-00.txt Rahul Aggarwal, Chaitanya Kodeboyina Presenter: Rahul Applications: - - MVPN 2547 inter-AS option B - - Others possible BGP NH of unicast routes are rewritten in option B... PIM RPF fails Address of multicast source must be preserved Solution: Preserve original Next Hop Carried as optional/transitive attribute Address family inferred from length of attribute Compared to "Connector": - - Connector doesn't have well-defined semantics (inferred from AFI/SAFI) - - This attribute has specific semantics Questions/Comments (for previous two presentations): Gargi: disagree w/ statement that connector semantics are not well-defined. it is just a matter of listing out other uses. Also, not just bit-bucket but, types define what is to be carried Pedro Marques: MDT safi - on one slide the RD can identify the VRF, or the RT can identify the VRF: can have more than one RD per VPN. The RT model is always used to leak between VPN. Please stick to using just RT. Gargi: OK. Yakov: Then RT model will be consistent for unicast Gargi: We can talk. John Scudder: To Rahul ... were you serious about inferring the AF/SAF from length of attr? ... there may be other AF in the future (ATM, IPV9) in which you cannot infer Rahul: Not solving hypothetical problems..... Yakov: What happens when something has the wrong length. The semantics of the value are directly stated as type V6 and length is 128 bits Eric Rosen: I don't see that semantics is undefined here. The two proposals appear to be just about the same. Any claims for lack of definition are by further type setting. The BGP NH or connector attr must be able to specify. The issue is only if you think that you don't need MDT attr. Rahul: difference comes down to non-congruent topologies, we should discuss that in L3VPN WG Eric: The incongruent topology is to have MDT and BGP NH/connector attr. Otherwise, these drafts are extremely close. Someone from Cisco: There are implementations out there that don't use BGP NH for VPN addresses. Therefore, we have to specify this. Eric Rosen: if we work out non-congruent stuff in L3VPN, shoudn't these converge? Rahul: quite likely Yakov: who control the type space for MDT/connector? Gargi: IANA or IDR Yakov: IDR doesn't control type space Everyone: IANA Someone from Alcatel: Don't need RD ... only need group mcast addr as global unicast addr must be local IP addr. Gargi: Think of it like an VPN NRLI (MDT in this case like a label) .... kept RD to understand one NLRI from the other. Allows addr overlap. Yakov: is the combination of ip addr (loopback) and group addr globally unique? Gargi: not necessarily, could be shared by number of PEs. Why RD is there? Look at L3VPN proposal: join to the group from another signaling manner Yakov: When won't it? Gargi: (Something about two PE's having the same loopback address) Yakov: In that case unicast wouldn't work. Gargi: OK then the PE addrs must be unique. Yakov: Well then is the combination unique? Gargi: Yes. Yakov: Well that was the other guy's point. Enke Chen: here is another application - eliminating route oscillation: make it TLV based so can include multiple original nexthops and also carry AF/SAF. I agree with John about AF/SAF. Enke: Also you can carry ASN with nexthop, carry multiple. Rahul: Very interesting. CK: draft actually says that orig_NH has same type as the normal NH type, it's not implied by length at all Pedro (to Enke): Just because the encoding is convenient doesn't mean it's OK -- still have same amount of scaling issues from carrying extra data. Enke: I don't care about encoding efficiency, it's to let MED be derived from orig NH while still allowing RR to rewrite NH. Rahul: I have another application for it but I haven't thought it out well yet. Someone from Juniper: Type of original NH is not from length but, apply the rule that is used to derive from the NRLI that is passed Eric Rosen: There is no rule that NH passed is same AF/SAF as NRLI. Therefore, cannot rely on the packet type to derive the NH. CK: deriving AFI and SAFI of nexthop is hard, but that's independent of this draft. Yakov : we are in the weeds of details that should be in L3VPN WG Someone from Cisco: Question to chairs, isn't one draft a subset of the other? can the chairs suggest a way to resolve this? Yakov: we aren't going to progress any of them until we have guidance from L3VPN. Rahul: I don't agree the one is a subset of the other. Sue: We're not doing anything until L3VPN does something. Bill Fenner: specific problem or generalizing to something bigger? It's a continuum. Sue: Thank you. - ---- Wrap up: Sue: We are requested to review MPLS BGP GR and private LAN service doc. I need reviewers to volunteer. You need to read doc, see if it fits with existing IDR practice/implementation. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ 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 NAA19023 for ; Tue, 24 Aug 2004 13:28:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bzes2-0006ex-5d; Tue, 24 Aug 2004 13:14:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzeWY-0000tu-UR for idr@megatron.ietf.org; Tue, 24 Aug 2004 12:51:54 -0400 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 MAA21668 for ; Tue, 24 Aug 2004 12:51:46 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzeWy-0004KH-MJ for idr@ietf.org; Tue, 24 Aug 2004 12:52:24 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Aug 2004 09:53:27 -0700 X-BrightmailFiltered: true Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i7OGpBhg013114 for ; Tue, 24 Aug 2004 09:51:12 -0700 (PDT) Received: from [64.101.214.222] (dhcp-64-101-215-163.cisco.com [64.101.215.163]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA13915 for ; Tue, 24 Aug 2004 12:51:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: Date: Tue, 24 Aug 2004 12:51:05 -0400 To: idr@ietf.org From: "John G. Scudder" Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8d68e55b48f2ff3cebd1a6416d9536 Subject: [Idr] Draft minutes for August 2 meeting 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 NAA19023 Inter-Domain Routing WG (idr) Monday, August 2 at 1300-1500 ============================= CHAIRS: Susan Hares Yakov Rekhter SCRIBES: Ignas Bagdonas John Scudder David Ward See proceedings (http://www.ietf.org/proceedings/04aug/index.html) for presentation slides. ---- Document Status Update (5 mins) S. Hares, Y. Rekhter Presenter: Yakov Four new work items accepted since last IETF, good consensus. Other items proposed, not sufficient consensus, not accepted as WG items. IESG review of BGP base spec package is done, comments incorporated (BGP-4, MIB, etc). Will issue further revisions as needed. Submitted 6 docs to IESG to advance since last IETF (GR, extcomm, etc) Confeds -- need to be updated with comments from last call, need implementation report -- once done, to IESG. No new progress until >= 2 impls: - ORF - 4-octet ASN - AS path ORF - MIB - AS wide unique identifier Questions/Comments: Susan Harris: Just to clarify - which document was reclassified to historic? Yakov: RFC 1863. ---- Dynamic Capability for BGP-4 (10 mins) draft-ietf-idr-dynamic-cap-05.txt Enke Chen, Srihari R. Sangli Presenter: Enke Additions to support capabilities which affect Update encoding: - Ack request - Ack - Sequence number What capabilities need ack? - 4-byte AS - Multipath - Address Family (probably) Ack is optional so need not be used for capabilities that don't require it. Unfortunately ack is not backward compatible. Want to reuse current code point (fine if little/no deployment w/ prev spec version) or get new code point? Questions/Comments: Yakov: Get a new code point, we have hundreds of 'em, no need to economize. Martin Djernaes: Why not increase capability number space to 16 bits, also length to 16 bits? Chandra Appanna: Agreed, increase sizes. Chandra: What impact on the state machine? Enke: Little or none, session is already established. Chandra: Really? What about when you send a capability which changes something you negotiated at OPEN time? Tony Li: Reserve one value "for future extensions" Enke: Does anyone really need more length than 255? Many: Yes. (Out of time, move to mailing list) ---- Advertisement of the Group Best Paths in BGP (15 mins) draft-chen-bgp-group-path-update-01.txt E. Chen, N. Chen Presenter: Enke Why? Persistent oscillation issues -- RR or confederation. Observations: - Full mesh is free of oscillations - Route selection groups paths based on neighbor AS. Two approaches: - Advertise group-best (i.e. best path from each neighbor AS) -- eliminates MED oscillation, still vulnerable to topology-based issues, still reduces info vs. full mesh. Paths adv'd == number of neighbor ASes. Topology issues means that IGP constraints still apply -- intra-cluster links must have smaller metrics than inter-cluster links. - Advertise group multi-path -- adv all paths that survive MED comparison -- effectively makes RR advertisements independent of IGP metrics. However, virtually as much state as full mesh. Suggestions: accept MED, reduces number of routes that survive MED step ==> fewer routes advertised. Encoding: - must be changed (pfx, neighbor_as) for group-best, (pfx, originator_id) for group-multipath - no encoding change for reachable routes (because neighbor_as, orig_id already in update) - need new encoding for w/draw - therefore need new capability to indicate ability to parse new w/draw and all, also advertises which mode to be used (best only, group best, multi) Implementation/deployment: - only RR/confed BR need to advertise multiple paths - non-RR need only to Rx, not Tx -- Rx is easy recommendation: - Use group-best, incremental deployment. group-multi solves more problems but too many paths Questions/Comments: Pedro Marques: We could use the route server doc we just moved to historical for this instead of using this encoding. One reason I would like to use a new path attribute is because some non RR might like to do this, in which case originator ID won't work. Since there's no backward compatibility anyway, why try to reuse existing semantics? Enke: I think Orig_ID is a good fit. Yakov: Neighbor AS hack won't work with AS set. Enke: When advertising, you must create AS sequence, this is in base specification. John Scudder: I agree w/ Pedro. If defining a capability, then use a new encoding. Most important contribution of this draft is not encoding, what is most important is ruleset of what to advert and when. Enke: Yakov: There is little value to send the same information in the same message twice. Pedro: What about non-RR? You have to have the exit point (external box) to be able to do this. The originator_id only works for RR server. John: If define a way to solve multi-path in BGP, please solve the general case and not just the oscillation case. Enke: There are a lot of issues if we generalize and I don't know any examples. (Out of time, move to mailing list) ---- Graceful Shutdown of BGP Sessions (15 mins) draft-dubois-bgp-planned-maintenance-00.txt N. Dubois, B. Decraene, B. Fondeviole Presenter: Nicolas Why? - Want no packet loss during maintenance  - Current is break paths and then inform peers - Want make-before-break NOTE: not always useful for single IBGP session Observed behavior: - in small network test, router shutdown goes from 20s traffic loss to 0s - w/ 100k routes 20ms loss vs 4 sec loss - timer should be between 30 and 60s draft was too conservative w/ 300s Questions/Comments: Tony Li: What happens if the router undergoing maintenance simply withdraws in an orderly fashion Nicolas: Yes, that is exactly what the draft proposes John Scudder: No changes to BGP? Can you do this with a route map? Nicolas: No changes to BGP state machine. Can be done w/ route-map -- did that for testing. But, too hard for ops people. ---- Group Cooperative Route Filtering Capability for BGP-4 (10 mins) draft-muley-hares-idr-orf-order-00.txt Praveen Muley, Susan Hares, Keyur Patel Presenter: Sue Problem: There is a whole bunch of ORF types, may not have efficient policy together. Multiple policies but no grouping. Solution: Apply in order by putting a Group_id wrapper Process: Add group apply in grouping order Uses: VPN policies Global routing Questions/Comments: Enke Chen: Using this approach you can apply one policy before some other. Sue: This is to group them - ORF type or entry based Enke: Now tied to type and group as structure vs type and entry Enke: What does this accomplish? This is a location implementation problem. Currently you decide what order to send them in. Sue: Different ordering than base spec defines. Enke: Type based or entry based? If you have prefix and AS_PATH list, can you group them together? Sue Hares: Yes. Enke Chen: What is grouping granularity? Sue Hares: Any is possible. Enke: I'm still confused about what it accomplishes. Local implementation will do ordering anyway. I don't know what else it does. Is there anything? Sue: Gives a different ordering. Enke: I need to read it and then we can discuss further. Pedro Marques: What difference does it make which I apply first? The only action is to accept therefore, what does the ordering matter? A&&B == B&&A. Sue: Efficiency of statement of process, some ORFs have permit/deny which gets you to an AND Pedro: I don't think so. Chandra Appanna: Who are you trying to define 'efficiency' for? Sender or receiver? How do you guarantee what is efficient for receiver? Sue: The one doing the filtering Chandra: How can the guy advertising it, know what's efficient for the guy on the other end? Sue: Getting back to Pedro's example, with permit and deny ordering matters. Pedro: No. Chandra: Why scramble the order? Enke: If we're talking about efficiency, this is an implementation detail -- each implementation may want to optimize itself differently. Not sure this needs to be standardized. Sue: Thanks for your feedback. Praveen (co-author): order matters per VPN: ext comm/AS w/in VPN. Pedro: Please send a detailed example to the mailing list. Praveen: OK Jeff Haas: The ORFs we have today are very coarse (AND) ... instead add sequencing and AND them together John Scudder: If you are trying to build route-map semantics the draft doesn't express it clearly. Missed OR'ing, AND'ing instead focused on 'efficiency' Sue: We can update it. Chandra Appanna: If all policy is ANDed there's no issue. Pedro: With your encoding, the ordering w/in a group is now independent but, between groups you are still left w/ the AND'ing problem. Sue: Sequence DOES matter. (Out of time, move to mailing list) ---- Carrying ATM reachability information in BGP (15 mins) draft-ck-bgp-atm-nlri-00.txt Chaitanya Kodeboyina, Chris Metz, Peter Busschbach Presenter: CK Want to make MPLS network transparent to STM routing/signalling. - PNNI tunneling through MPLS doesn't scale - Instead do something almost exactly like 2547 but for PNNI - Why BGP? Same reasons as for 2547 -- Solves adjacency problem, fits existing carrier infrastructure, can use RR, solves interdomain problem. - "We use BGP to carry everything else so why not ATM reachability information?" Solution: BGP carries ATM info, passes to ATM route selector(ATM topo db) and signaled to/from PNNI Define new AF/SAF Use Route Distinguishers between ATM switches in different domains New extcomm values: ATM admin weight (~= PNNI metric) Use RT to manage independent ATM networks over single core Note, also presented to L2VPN WG Questions/Comments: Yakov: whole proposal is really L2VPN, only peripherally IDR WG. Should wait to see if L2VPN accepts, then if accepted look at it in IDR MDT SAFI and Connector Attribute (10 mins) draft-nalawade-idr-mdt-safi-01.txt Gargi Nalawade, Arjun Sreekantiah Presenter: Gargi Two proposals -- MDT SAFI, Connector attribute. Could be split to two documents as needed. Problem: Multicast VPNs is incongruent w/ unicast topology What is a Multicast Domain? set of PE routers connected by a mcast tunnel MD per mcast-enabled VPN a default MDT (multicast distribution tree) connects all PEs Autodiscovery: MDT setup by PIM-SM, Bidir PIM or PIM SSM For SSM each PE needs to know the src addr of each of the other PEs in the same MD Therefore need autodisc of src addr of each of PEs in the same MD Therefore use new MDT SAFI RD - assigned to one mcast domain IPaddr - dest addr (PE) MDT - addr of given MD RTs in the ext comm attr and/or the RD used to associate w/ the correct VRF Why connector attr? If use NHself then originating PE is overridden Need original original NH of VPNv4 update to find which tunnel to use Called Connector because it connects a VPNv4 prefix's update w/ the MDT safi. (Suggestions for better name solicited.) Indicates the correlation and depnd between the 2 safi's and/or carries NGH value by an originating BGP speaker More discussion @ L3VPN WG Questions/Comments: Yakov: Part of a larger work that is in L3VPN WG (mcast 2547) but, BGP specific part depends on whole solution by L3VPN WG. Therefore, don't spend time talking about this work but, the L3VPN WG. (Didn't get name, from Cisco): If other WG accepts pkg, does that mean IDR is supposed to accept it? Yakov: no, it means if other WG doesn't accept it, there's no point in us even spending time Alex: I agree with Yakov unless you (IDR) see a showstopper in this proposal Yakov: well it's not broken so don't worry about that Yakov: please hold other questions until after Rahul's talk ---- Preserving BGP Next-Hops (10 mins) draft-raggarwa-bgp-nexthop-rewrite-00.txt Rahul Aggarwal, Chaitanya Kodeboyina Presenter: Rahul Applications: - MVPN 2547 inter-AS option B - Others possible BGP NH of unicast routes are rewritten in option B... PIM RPF fails Address of multicast source must be preserved Solution: Preserve original Next Hop Carried as optional/transitive attribute Address family inferred from length of attribute Compared to "Connector": - Connector doesn't have well-defined semantics (inferred from AFI/SAFI) - This attribute has specific semantics Questions/Comments (for previous two presentations): Gargi: disagree w/ statement that connector semantics are not well-defined. it is just a matter of listing out other uses. Also, not just bit-bucket but, types define what is to be carried Pedro Marques: MDT safi - on one slide the RD can identify the VRF, or the RT can identify the VRF: can have more than one RD per VPN. The RT model is always used to leak between VPN. Please stick to using just RT. Gargi: OK. Yakov: Then RT model will be consistent for unicast Gargi: We can talk. John Scudder: To Rahul ... were you serious about inferring the AF/SAF from length of attr? ... there may be other AF in the future (ATM, IPV9) in which you cannot infer Rahul: Not solving hypothetical problems..... Yakov: What happens when something has the wrong length. The semantics of the value are directly stated as type V6 and length is 128 bits Eric Rosen: I don't see that semantics is undefined here. The two proposals appear to be just about the same. Any claims for lack of definition are by further type setting. The BGP NH or connector attr must be able to specify. The issue is only if you think that you don't need MDT attr. Rahul: difference comes down to non-congruent topologies, we should discuss that in L3VPN WG Eric: The incongruent topology is to have MDT and BGP NH/connector attr. Otherwise, these drafts are extremely close. Someone from Cisco: There are implementations out there that don't use BGP NH for VPN addresses. Therefore, we have to specify this. Eric Rosen: if we work out non-congruent stuff in L3VPN, shoudn't these converge? Rahul: quite likely Yakov: who control the type space for MDT/connector? Gargi: IANA or IDR Yakov: IDR doesn't control type space Everyone: IANA Someone from Alcatel: Don't need RD ... only need group mcast addr as global unicast addr must be local IP addr. Gargi: Think of it like an VPN NRLI (MDT in this case like a label) .... kept RD to understand one NLRI from the other. Allows addr overlap. Yakov: is the combination of ip addr (loopback) and group addr globally unique? Gargi: not necessarily, could be shared by number of PEs. Why RD is there? Look at L3VPN proposal: join to the group from another signaling manner Yakov: When won't it? Gargi: (Something about two PE's having the same loopback address) Yakov: In that case unicast wouldn't work. Gargi: OK then the PE addrs must be unique. Yakov: Well then is the combination unique? Gargi: Yes. Yakov: Well that was the other guy's point. Enke Chen: here is another application - eliminating route oscillation: make it TLV based so can include multiple original nexthops and also carry AF/SAF. I agree with John about AF/SAF. Enke: Also you can carry ASN with nexthop, carry multiple. Rahul: Very interesting. CK: draft actually says that orig_NH has same type as the normal NH type, it's not implied by length at all Pedro (to Enke): Just because the encoding is convenient doesn't mean it's OK -- still have same amount of scaling issues from carrying extra data. Enke: I don't care about encoding efficiency, it's to let MED be derived from orig NH while still allowing RR to rewrite NH. Rahul: I have another application for it but I haven't thought it out well yet. Someone from Juniper: Type of original NH is not from length but, apply the rule that is used to derive from the NRLI that is passed Eric Rosen: There is no rule that NH passed is same AF/SAF as NRLI. Therefore, cannot rely on the packet type to derive the NH. CK: deriving AFI and SAFI of nexthop is hard, but that's independent of this draft. Yakov : we are in the weeds of details that should be in L3VPN WG Someone from Cisco: Question to chairs, isn't one draft a subset of the other? can the chairs suggest a way to resolve this? Yakov: we aren't going to progress any of them until we have guidance from L3VPN. Rahul: I don't agree the one is a subset of the other. Sue: We're not doing anything until L3VPN does something. Bill Fenner: specific problem or generalizing to something bigger? It's a continuum. Sue: Thank you. ---- Wrap up: Sue: We are requested to review MPLS BGP GR and private LAN service doc. I need reviewers to volunteer. You need to read doc, see if it fits with existing IDR practice/implementation. _______________________________________________ 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 QAA11164 for ; Wed, 18 Aug 2004 16:22:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxW3i-00040q-8v; Wed, 18 Aug 2004 15:25:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxW1T-0002wK-HD; Wed, 18 Aug 2004 15:22:59 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01337; Wed, 18 Aug 2004 15:22:27 -0400 (EDT) Message-Id: <200408181922.PAA01337@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 18 Aug 2004 15:22:27 -0400 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-dynamic-cap-06.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 : Dynamic Capability for BGP-4 Author(s) : E. Chen, S. Sangli Filename : draft-ietf-idr-dynamic-cap-06.txt Pages : 8 Date : 2004-8-18 This document defines a new BGP capability termed 'Dynamic Capability', which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-dynamic-cap-06.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-dynamic-cap-06.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-dynamic-cap-06.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-8-18143111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-dynamic-cap-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-dynamic-cap-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-18143111.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 FAA12790 for ; Mon, 16 Aug 2004 05:03:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwd8H-0008Oa-Aa; Mon, 16 Aug 2004 04:46:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwd7S-00085S-Fz for idr@megatron.ietf.org; Mon, 16 Aug 2004 04:45:30 -0400 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 EAA18709 for ; Mon, 16 Aug 2004 04:45:28 -0400 (EDT) Received: from bay17-f33.bay17.hotmail.com ([64.4.43.83] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwdDD-0004wR-Ef for idr@ietf.org; Mon, 16 Aug 2004 04:51:28 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 16 Aug 2004 01:44:58 -0700 Received: from 61.16.170.194 by by17fd.bay17.hotmail.msn.com with HTTP; Mon, 16 Aug 2004 08:44:58 GMT X-Originating-IP: [61.16.170.194] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com From: "john smith" To: idr@ietf.org Subject: RE: [Idr] draft-muley-hares-idr-orf-order-00.txt Date: Mon, 16 Aug 2004 08:44:58 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Aug 2004 08:44:58.0543 (UTC) FILETIME=[4FB93BF0:01C4836D] X-Spam-Score: 0.9 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 This maybe the wrong working group to ask but this question is somewhat releated to the point Praveen was making, Q. How do I withdraw an LSP using CR-LDP?? :( >From: Pedro Roque Marques >To: "Praveen Muley" >CC: idr@ietf.org >Subject: [Idr] draft-muley-hares-idr-orf-order-00.txt >Date: Thu, 12 Aug 2004 10:05:43 -0700 > >Praveen Muley writes: > > > Hello Pedros, A simple example for Group ORF can be multiple VRFs > > having different set of prefix filters. In that case say extended > > community Green for Green VRF and Red extended community for Red VRF > > with different prefix filters need to be send to the BGP peer. > >Praveen, >the orf-order draft, as currently specified, does not seem to me to be >able to express that problem... > >i.e. you seem to want to express a set of expressions such as > (a && b) || (c && d) || ... > >it would also be an inneficient way to solve the problem you >mention... you do not want to perform a sequential search through the >extended community space. > >But all of these are, imho, quite secondary compared to the >question of why would you do this in the first place... > >I would expect that if you want prefix filters torwards you VRF client >that you would want to apply them in the PE-CE routing adjacency... > > > Today there is difficulty in expressing this, while carrying > > multiple ORF entries as relationship between the ORF entries of one > > type of ORF to another cannot be expressed ( or rather say its > > strict) as same ORF types are clubbed together and hence applying > > granular policy is an issue. Grouping helps in solving this. > >There may be applications that require the ability to combine >different filters... but ORF should not become a replacement for a >configuration distribution mecanism. imho, ORF should be reserved for >situations where there is a clear advantage in performing the >filtering outbound *as well as* inbound on a session. > >I think it is important to define what problems you intend to solve, >to demonstrate how you solve the problem and compare with other >possible solutions. > > Pedro. > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ 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 OAA24401 for ; Sat, 14 Aug 2004 14:05:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bw2sg-0007Dt-GT; Sat, 14 Aug 2004 14:03:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bw2rC-0006zw-VC for idr@megatron.ietf.org; Sat, 14 Aug 2004 14:02:19 -0400 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 OAA24135 for ; Sat, 14 Aug 2004 14:02:17 -0400 (EDT) Received: from relay.pair.com ([209.68.1.20]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Bw2wd-0008My-CO for idr@ietf.org; Sat, 14 Aug 2004 14:07:55 -0400 Received: (qmail 22889 invoked from network); 14 Aug 2004 18:02:04 -0000 Received: from dialup-4.156.51.22.dial1.boston1.level3.net (HELO laptoy770.faster-light.net) (4.156.51.22) by relay.pair.com with SMTP; 14 Aug 2004 18:02:04 -0000 X-pair-Authenticated: 4.156.51.22 Received: from laptoy770.faster-light.net (localhost [127.0.0.1]) by laptoy770.faster-light.net (8.12.9p2/8.12.9) with ESMTP id i7EI545f055251; Sat, 14 Aug 2004 14:05:05 -0400 (EDT) (envelope-from curtis@laptoy770.faster-light.net) Message-Id: <200408141805.i7EI545f055251@laptoy770.faster-light.net> To: Mark Smith Subject: Re: [Idr] Worth putting in an RFC ? Use IP / GRE tunnels between EBGP peers In-reply-to: Your message of "Sat, 14 Aug 2004 11:52:15 +0930." <20040814115215.56edebf3.ietf@130c04165a5b40404e4440445758487a.nosense.org> Date: Sat, 14 Aug 2004 14:05:03 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: idr@ietf.org, Vivek Menezes 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 <20040814115215.56edebf3.ietf@130c04165a5b40404e4440445758487a.nosense.org> Mark Smith writes: > > On Fri, 13 Aug 2004 15:10:06 -0700 > Vivek Menezes wrote: > > > > > > It would seem that the authors of the few books I've got on BGP > > > have either read them and forgotten about this, or possibly never read > > > them thoroughly enough either, as I've never come across any mention of > > > this technique. That is why I thought it might be new, at least when it > > > came to using IP/IP or GRE tunnels for this purpose vs. MPLS. > > > > RFCs should to be written only for protocol compliance between > > vendors. Having an RFC > > describe a particular implementation doesn't add much value. > > I was thinking along the lines of an Informational RFC describing this method. > > I though that the scope of the IDR working group might also cover > Informational RFCs regarding the use of BGP. I've realised that might not be > the case. Appologies to everyone if I was wrong. > > Thanks, > Mark. Mark, 1. This is something already known. 2. It is a trivial observation. 3. It is already documented. 4. This would be a rather pointless exercise. It seems like you want to have your name on an informational RFC and you are fishing for something to write about. This is clearly not something worthy of its own informational RFC. btw- Anyone can submit an individual internet-draft and ask that the IESG consider it directly. If it is deemed by the IESG to fall within or close to the general scope of an existing WG it will be forwarded to that WG. That means that if it is related to BGP it will most likely end up right back here. So far all of the responses are telling you it is not material for an RFC. If you actually knew the pros and cons of a full mesh of BGP over a tunnelled infrastructure then *maybe* it would be worth an RFC. But then it wouldn't be about BGP over GRE. It would be about the early UUNET brief experience with IP over ATM, about the former InterneetMCI's brief experience with full mesh ATM and the IGP problems, and C&W's experience with FR over CCC over MPLS (and anyone else that tried something like this). It would explain why RFC1577 was a non-starter as far as ISPs were concerned in its time and why the "BGP free core" with tunneling can in some cases share the same characteristics that made RFC1577 a non-starter. This would be best writen by someone who was either directly involved or very familiar with the issues in each of these and/or well connected enough to contact people who were directly involved. Even these are somewhat documented if you count such things Dave Katz presentation on IGP scaling at NANOG for which he didn't submit slides and numerous discussion about the motivations for IGP mesh groups and discussions on the now defunct IP over ATM WG, ION, and others. It would also explain the "pros" of running a BGP mesh over some sort of tunneling and how MPLS/RSVP solved these without the cons that came with IP over ATM. Other tunneling with no TE capability just accomplishes a subset of the perceived "pros" which is the trivial observation you've made. Even if someone wrote such a document there would be considerable discussion over exactly how significant each of the pros and cons are. The actual experiences are at least difficult to dispute but provide only a limited set of data points. The extrapolation to today's topologies and technology would be the area of disagreement. You haven't demonstrated in your few brief messages that you have the slightest clue about the existing known issues or what has been written about them in the past and which somewhat significant points have not been clearly documented. If you think you can enlighten us, go for it. If you are just going to point out that it is possible to run BGP over GRE you don't have material for an RFC. 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 WAA17342 for ; Fri, 13 Aug 2004 22:26:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvoDM-0007T0-HB; Fri, 13 Aug 2004 22:24:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvoC7-0007De-Ix for idr@megatron.ietf.org; Fri, 13 Aug 2004 22:22:55 -0400 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 WAA03052 for ; Fri, 13 Aug 2004 22:22:53 -0400 (EDT) Received: from 241.cust4.sa.dsl.ozemail.com.au ([210.84.227.241] helo=dupy2.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvoHO-000426-3M for idr@ietf.org; Fri, 13 Aug 2004 22:28:23 -0400 Received: from Dupy2.nosense.org (localhost.localdomain [127.0.0.1]) by dupy2.nosense.org (Postfix) with SMTP id 11C913F019; Sat, 14 Aug 2004 11:52:15 +0930 (CST) Date: Sat, 14 Aug 2004 11:52:15 +0930 From: Mark Smith To: Vivek Menezes Subject: Re: [Idr] Worth putting in an RFC ? Use IP / GRE tunnels between EBGP peers Message-Id: <20040814115215.56edebf3.ietf@130c04165a5b40404e4440445758487a.nosense.org> In-Reply-To: <38a0ff0504081315104c47f837@mail.gmail.com> References: <20040813121941.18b5955f.ietf@130c04165a5b40404e4440445758487a.nosense.org> <20040813033032.GA22219@nexthop.com> <20040813141446.1dea9ed1.ietf@130c04165a5b40404e4440445758487a.nosense.org> <38a0ff0504081315104c47f837@mail.gmail.com> Organization: The No Sense Organisation (http://www.nosense.org) X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Adelaide, Australia Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit 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 Hi Vivek, On Fri, 13 Aug 2004 15:10:06 -0700 Vivek Menezes wrote: > Mark, > > > > > It would seem that the authors of the few books I've got on BGP > > have either read them and forgotten about this, or possibly never read > > them thoroughly enough either, as I've never come across any mention of > > this technique. That is why I thought it might be new, at least when it > > came to using IP/IP or GRE tunnels for this purpose vs. MPLS. > > RFCs should to be written only for protocol compliance between > vendors. Having an RFC > describe a particular implementation doesn't add much value. I was thinking along the lines of an Informational RFC describing this method. I though that the scope of the IDR working group might also cover Informational RFCs regarding the use of BGP. I've realised that might not be the case. Appologies to everyone if I was wrong. Thanks, Mark. _______________________________________________ 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 SAA15418 for ; Fri, 13 Aug 2004 18:15:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvkIc-0007xv-5N; Fri, 13 Aug 2004 18:13:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvkFV-0005w6-OL for idr@megatron.ietf.org; Fri, 13 Aug 2004 18:10:09 -0400 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 SAA21465 for ; Fri, 13 Aug 2004 18:10:06 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.199] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvkKk-0000ay-H0 for idr@ietf.org; Fri, 13 Aug 2004 18:15:35 -0400 Received: by mproxy.gmail.com with SMTP id 73so43389rnl for ; Fri, 13 Aug 2004 15:10:06 -0700 (PDT) Received: by 10.38.59.23 with SMTP id h23mr152676rna; Fri, 13 Aug 2004 15:10:06 -0700 (PDT) Message-ID: <38a0ff0504081315104c47f837@mail.gmail.com> Date: Fri, 13 Aug 2004 15:10:06 -0700 From: Vivek Menezes To: Mark Smith Subject: Re: Re: [Idr] Worth putting in an RFC ? Use IP / GRE tunnels between EBGP peers In-Reply-To: <20040813141446.1dea9ed1.ietf@130c04165a5b40404e4440445758487a.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040813121941.18b5955f.ietf@130c04165a5b40404e4440445758487a.nosense.org> <20040813033032.GA22219@nexthop.com> <20040813141446.1dea9ed1.ietf@130c04165a5b40404e4440445758487a.nosense.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, Jeffrey Haas 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 Mark, > > It would seem that the authors of the few books I've got on BGP > have either read them and forgotten about this, or possibly never read them > thoroughly enough either, as I've never come across any mention of this > technique. That is why I thought it might be new, at least when it came to > using IP/IP or GRE tunnels for this purpose vs. MPLS. RFCs should to be written only for protocol compliance between vendors. Having an RFC describe a particular implementation doesn't add much value. You can also use ATM to do what you are suggesting :-) Vivek. > > Thanks, > Mark. > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ 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 AAA07041 for ; Fri, 13 Aug 2004 00:52:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvTyE-0000Cc-9j; Fri, 13 Aug 2004 00:47:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvTwQ-0008He-2i for idr@megatron.ietf.org; Fri, 13 Aug 2004 00:45:22 -0400 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 AAA03083 for ; Fri, 13 Aug 2004 00:45:19 -0400 (EDT) Received: from 193.cust11.sa.dsl.ozemail.com.au ([210.84.234.193] helo=dupy2.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvU1U-00067N-QD for idr@ietf.org; Fri, 13 Aug 2004 00:50:38 -0400 Received: from Dupy2.nosense.org (localhost.localdomain [127.0.0.1]) by dupy2.nosense.org (Postfix) with SMTP id A327F3F019; Fri, 13 Aug 2004 14:14:46 +0930 (CST) Date: Fri, 13 Aug 2004 14:14:46 +0930 From: Mark Smith To: Jeffrey Haas Subject: Re: [Idr] Worth putting in an RFC ? Use IP / GRE tunnels between EBGP peers Message-Id: <20040813141446.1dea9ed1.ietf@130c04165a5b40404e4440445758487a.nosense.org> In-Reply-To: <20040813033032.GA22219@nexthop.com> References: <20040813121941.18b5955f.ietf@130c04165a5b40404e4440445758487a.nosense.org> <20040813033032.GA22219@nexthop.com> Organization: The No Sense Organisation (http://www.nosense.org) X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Adelaide, Australia Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit 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 Hi Jeff, Thanks for getting back to me. On Thu, 12 Aug 2004 23:30:32 -0400 Jeffrey Haas wrote: > On Fri, Aug 13, 2004 at 12:19:41PM +0930, Mark Smith wrote: > > The idea is to create IP in IP or GRE tunnels between the EBGP > > routers within the AS, run IBGP over the tunnels, and then also use those > > tunnels for transit traffic. > > That which was once old is made again new. :-) > > [RFC 1772, A.2.3] > A.2.3 Encapsulation > > Encapsulation provides the simplest (in terms of the interaction > between the IGP and BGP) mechanism for carrying transit traffic > across the AS. In this approach, transit traffic is encapsulated > within an IP datagram addressed to the exit gateway. The only > requirement imposed on the IGP by this approach is that it should be > capable of supporting routing between border gateways within the same > AS. > > It is well worth the time for relative newcomers to read the 177x > series of documents. They encapsulate a lot of old wisdom. :-) > I agree. I have glossed through 1771, I haven't got to reading the others :-) It would seem that the authors of the few books I've got on BGP have either read them and forgotten about this, or possibly never read them thoroughly enough either, as I've never come across any mention of this technique. That is why I thought it might be new, at least when it came to using IP/IP or GRE tunnels for this purpose vs. MPLS. Thanks, Mark. _______________________________________________ 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 XAA06317 for ; Thu, 12 Aug 2004 23:38:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvSst-0003ma-MI; Thu, 12 Aug 2004 23:37:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvSpG-0003V9-3P for idr@megatron.ietf.org; Thu, 12 Aug 2004 23:33:54 -0400 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 XAA28678 for ; Thu, 12 Aug 2004 23:33:51 -0400 (EDT) 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 1BvSuK-0004nV-Mf for idr@ietf.org; Thu, 12 Aug 2004 23:39:09 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C072C2D4827; Thu, 12 Aug 2004 23:33:21 -0400 (EDT) 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 89241-02; Thu, 12 Aug 2004 23:33:21 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 183B62D481A; Thu, 12 Aug 2004 23:30:33 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i7D3UW622244; Thu, 12 Aug 2004 23:30:32 -0400 (EDT) Date: Thu, 12 Aug 2004 23:30:32 -0400 From: Jeffrey Haas To: Mark Smith Subject: Re: [Idr] Worth putting in an RFC ? Use IP / GRE tunnels between EBGP peers Message-ID: <20040813033032.GA22219@nexthop.com> References: <20040813121941.18b5955f.ietf@130c04165a5b40404e4440445758487a.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040813121941.18b5955f.ietf@130c04165a5b40404e4440445758487a.nosense.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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, Aug 13, 2004 at 12:19:41PM +0930, Mark Smith wrote: > The idea is to create IP in IP or GRE tunnels between the EBGP > routers within the AS, run IBGP over the tunnels, and then also use those > tunnels for transit traffic. That which was once old is made again new. :-) [RFC 1772, A.2.3] A.2.3 Encapsulation Encapsulation provides the simplest (in terms of the interaction between the IGP and BGP) mechanism for carrying transit traffic across the AS. In this approach, transit traffic is encapsulated within an IP datagram addressed to the exit gateway. The only requirement imposed on the IGP by this approach is that it should be capable of supporting routing between border gateways within the same AS. It is well worth the time for relative newcomers to read the 177x series of documents. They encapsulate a lot of old wisdom. :-) -- Jeff Haas NextHop Technologies _______________________________________________ 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 WAA05881 for ; Thu, 12 Aug 2004 22:53:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvSA5-0004hR-Vu; Thu, 12 Aug 2004 22:51:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvS9H-0004Hr-Ky for idr@megatron.ietf.org; Thu, 12 Aug 2004 22:50:31 -0400 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 WAA26214 for ; Thu, 12 Aug 2004 22:50:29 -0400 (EDT) Received: from 193.cust11.sa.dsl.ozemail.com.au ([210.84.234.193] helo=dupy2.nosense.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvSEL-00042o-5B for idr@ietf.org; Thu, 12 Aug 2004 22:55:47 -0400 Received: from Dupy2.nosense.org (localhost.localdomain [127.0.0.1]) by dupy2.nosense.org (Postfix) with SMTP id E2E803F019 for ; Fri, 13 Aug 2004 12:19:41 +0930 (CST) Date: Fri, 13 Aug 2004 12:19:41 +0930 From: Mark Smith To: idr@ietf.org Message-Id: <20040813121941.18b5955f.ietf@130c04165a5b40404e4440445758487a.nosense.org> Organization: The No Sense Organisation (http://www.nosense.org) X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Location: Adelaide, Australia Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Subject: [Idr] Worth putting in an RFC ? Use IP / GRE tunnels between EBGP peers 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 idea is to create IP in IP or GRE tunnels between the EBGP routers within the AS, run IBGP over the tunnels, and then also use those tunnels for transit traffic. If this idea has been thought of before, and dismissed, please disregard the rest of this email. I think this idea is similar to the way MPLS can be used to transport traffic across a transit AS, where the MPLS LSPs target the NEXT_HOP attribute. At least that's how I understand how MPLS can be used to optimise BGP within an AS. I originally worked out this idea when I was learning BGP a few years ago, although I haven't had a chance to test it. I was surprised when I started learning MPLS how similar the MPLS solution is. I do think the MPLS solution is better. This solution could be used as a transitional step towards MPLS, or maybe as a contingency if there are issues with the transit routers for some reason (eg. running out of memory for the Internet route table). Here are some advantages. As this solution is similar to the MPLS one, there is quite a lot of overlap. (a) obviously, not having to run BGP to the transit routers within the AS. (b) therefore, internal transit routers don't have to maintain full Internet route tables (c) simpler to deploy than the MPLS solution. MPLS deployment is likely to require software / firmware upgrades in the transit routers. If I understand the MPLS itself, and the MPLS solution correctly, it also requires that all routers between the AS edge routers are MPLS enabled before MPLS can be used. I'd suspect the majority of current AS border routers already contain IP in IP / GRE functionality that just needs to be configured. Transit routers within the AS need no additional configuration at all. (d) If the BGP keep alive timer is set large enough, the tunnel will hide transients in the underlying transit network. Of course, there are some drawbacks. (a) The tunnel header overhead added to the transiting IP packets. This may cause PMTUD to have to discover a new PMTU. (b) A full mesh of tunnels needs to be set up between all the EBGP routers in the AS. While this is simpler than a full IBGP mesh between all AS transit routers, it doesn't scale upwards. At a certain point, other "mesh mitigation" techniques will become more effective. (b) can't really think of any others now, that certainly doesn't mean there aren't any :-) I'm willing to have a go at writing something up if there is enough value in this idea. Thanks, Mark. _______________________________________________ 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 NAA01242 for ; Thu, 12 Aug 2004 13:33:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvJ8y-0004fL-MW; Thu, 12 Aug 2004 13:13:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvJ1s-0002Jm-Ln for idr@megatron.ietf.org; Thu, 12 Aug 2004 13:06:16 -0400 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 NAA15873 for ; Thu, 12 Aug 2004 13:06:13 -0400 (EDT) Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvJ6r-00088D-ID for idr@ietf.org; Thu, 12 Aug 2004 13:11:26 -0400 Received: from roque-bsd.juniper.net (localhost [127.0.0.1]) by roque-bsd.juniper.net (8.12.8p1/8.12.3) with ESMTP id i7CH5hPm084207; Thu, 12 Aug 2004 10:05:43 -0700 (PDT) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i7CH5h87084204; Thu, 12 Aug 2004 10:05:43 -0700 (PDT) From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16667.41831.444848.174439@roque-bsd.juniper.net> Date: Thu, 12 Aug 2004 10:05:43 -0700 To: "Praveen Muley" Subject: [Idr] draft-muley-hares-idr-orf-order-00.txt In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93067EC2FA@zsc3c026.us.nortel.com> References: <0A11633F61BD9F40B43ABCC694004F93067EC2FA@zsc3c026.us.nortel.com> X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit 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 Praveen Muley writes: > Hello Pedros, A simple example for Group ORF can be multiple VRFs > having different set of prefix filters. In that case say extended > community Green for Green VRF and Red extended community for Red VRF > with different prefix filters need to be send to the BGP peer. Praveen, the orf-order draft, as currently specified, does not seem to me to be able to express that problem... i.e. you seem to want to express a set of expressions such as (a && b) || (c && d) || ... it would also be an inneficient way to solve the problem you mention... you do not want to perform a sequential search through the extended community space. But all of these are, imho, quite secondary compared to the question of why would you do this in the first place... I would expect that if you want prefix filters torwards you VRF client that you would want to apply them in the PE-CE routing adjacency... > Today there is difficulty in expressing this, while carrying > multiple ORF entries as relationship between the ORF entries of one > type of ORF to another cannot be expressed ( or rather say its > strict) as same ORF types are clubbed together and hence applying > granular policy is an issue. Grouping helps in solving this. There may be applications that require the ability to combine different filters... but ORF should not become a replacement for a configuration distribution mecanism. imho, ORF should be reserved for situations where there is a clear advantage in performing the filtering outbound *as well as* inbound on a session. I think it is important to define what problems you intend to solve, to demonstrate how you solve the problem and compare with other possible solutions. Pedro. _______________________________________________ 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 XAA24363 for ; Wed, 11 Aug 2004 23:18:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv61I-0002cS-Kz; Wed, 11 Aug 2004 23:12:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv60b-0002Tl-RQ for idr@megatron.ietf.org; Wed, 11 Aug 2004 23:12:06 -0400 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 XAA11250 for ; Wed, 11 Aug 2004 23:12:03 -0400 (EDT) Received: from zsc3s004.nortelnetworks.com ([47.81.138.65]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv65S-0001Um-W8 for idr@ietf.org; Wed, 11 Aug 2004 23:17:08 -0400 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7C3BSB29606; Wed, 11 Aug 2004 20:11:28 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Aug 2004 20:11:28 -0700 Message-ID: <0A11633F61BD9F40B43ABCC694004F93067EC2FA@zsc3c026.us.nortel.com> From: "Praveen Muley" To: "'Susan Hares'" , idr@ietf.org Date: Wed, 11 Aug 2004 20:11:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Subject: [Idr] http://ietfreport.isoc.org/ids/draft-muley-hares-idr-orf-order-00 .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: , Content-Type: multipart/mixed; boundary="===============0717536040==" 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. --===============0717536040== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4801A.0F2CE704" 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_01C4801A.0F2CE704 Content-Type: text/plain Hello Pedros, A simple example for Group ORF can be multiple VRFs having different set of prefix filters. In that case say extended community Green for Green VRF and Red extended community for Red VRF with different prefix filters need to be send to the BGP peer. Today there is difficulty in expressing this, while carrying multiple ORF entries as relationship between the ORF entries of one type of ORF to another cannot be expressed ( or rather say its strict) as same ORF types are clubbed together and hence applying granular policy is an issue. Grouping helps in solving this. Regards, Praveen ------_=_NextPart_001_01C4801A.0F2CE704 Content-Type: text/html Content-Transfer-Encoding: quoted-printable http://ietfreport.isoc.org/ids/draft-muley-hares-idr-orf-order-00= .txt

Hello Pedros,
          A = simple example for Group ORF can be multiple VRFs having different set = of prefix filters. In that case say extended community Green for Green = VRF and Red extended community for Red VRF with different prefix = filters need to be send to the BGP peer.

          &nb= sp;           &nb= sp;           &nb= sp;  Today there is difficulty in expressing this, while carrying = multiple ORF entries as relationship between the ORF entries of one = type of ORF to another cannot be expressed ( or rather say its strict) = as same ORF types are clubbed together and hence applying granular = policy is an issue. Grouping helps in solving this. 

          &nb= sp;           &nb= sp; 
Regards,
Praveen
          &nb= sp;           &nb= sp;     

------_=_NextPart_001_01C4801A.0F2CE704-- --===============0717536040== 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 --===============0717536040==-- 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 SAA28214 for ; Thu, 5 Aug 2004 18:31:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsqXH-00023T-9f; Thu, 05 Aug 2004 18:16:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsqVA-0000mF-Eg for idr@megatron.ietf.org; Thu, 05 Aug 2004 18:14:21 -0400 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 SAA20701 for ; Thu, 5 Aug 2004 18:14:17 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsqYi-0006LX-IX for idr@ietf.org; Thu, 05 Aug 2004 18:18:02 -0400 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 i75MDj911985; Thu, 5 Aug 2004 15:13:45 -0700 (PDT) (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 i75MDee89497; Thu, 5 Aug 2004 15:13:40 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200408052213.i75MDee89497@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <79508.1091744020.1@juniper.net> Date: Thu, 05 Aug 2004 15:13:40 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: enke@redback.com, skh@nexthop.com Subject: [Idr] draft-chen-bgp-prefix-orf-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 Folks, There is a consensus to accept draft-chen-bgp-prefix-orf-07.txt as an IDR WG document. I'd like to ask the authors to resubmit it as draft-ietf-idr-bgp-prefix-orf-00.txt. 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 QAA19116 for ; Mon, 2 Aug 2004 16:39:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrjRr-0005DS-0V; Mon, 02 Aug 2004 16:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrjIY-0000nB-J3 for idr@megatron.ietf.org; Mon, 02 Aug 2004 16:20:42 -0400 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 QAA01806 for ; Mon, 2 Aug 2004 16:20:40 -0400 (EDT) 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 1BrjLT-0003kV-Ek for idr@ietf.org; Mon, 02 Aug 2004 16:23:44 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 21CD02D481B for ; Mon, 2 Aug 2004 16:20:10 -0400 (EDT) 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 24933-03-69 for ; Mon, 2 Aug 2004 16:20:09 -0400 (EDT) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id F14372D4814 for ; Mon, 2 Aug 2004 16:20:09 -0400 (EDT) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 2 Aug 2004 16:20:09 -0400 Message-ID: Thread-Topic: Feedback on the FSM and Dynamic capbility revision Thread-Index: AcR4zfMthK73qK9qQuK2i97tkINn+A== From: "Susan Hares" To: X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Idr] Feedback on the FSM and Dynamic capbility revision 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 QAA19116 Enke: The FSM was limited to the base specification. I believe that the addition of the Dynamic Capability as an addition to the base specification needs an addition to the FSM. I would suggest that text be added to the draft to indicate the FSM additions. Sue Hares _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr